l4-hackers November 2019

l4-hackers@os.inf.tu-dresden.de

4 participants
4 discussions

Filesystem Architectures with L4Re and L4-Based Systems
by Paul Boddie 02 Dec '19

02 Dec '19

Hello, As this list can attest, I previously spent a bit of time diving into the way dynamic linking is supported by L4Re to get shared mode programs working. This turned out to have a relatively simple fix related to symbols employed by GCC- generated code. But during this exercise, I gained some familiarity with the way libraries are loaded, and this appears to involve the virtual filesystem support, with the loader perusing the filesystem to access libraries, and with these being provided as modules by the "rom" filesystem. Since then, I've spent some time looking at how files are provided by filesystems and accessed by code that uses the conventional C or POSIX library interfaces. It raises a few questions about why things are done in a particular way in L4Re, and which approaches are in use for other L4-based systems, especially those that seek to provide general-purpose, multi-user solutions. What I think I now understand about the virtual filesystem support in L4Re is as follows. The virtual filesystem itself is a "client-side" construct, meaning that it resides within any given program. That programs have their own view of a filesystem is not too different from what the documentation about systems like the Hurd describes and advocates, and I suppose it is a tempting approach because it gives each program the flexibility to be customised in this regard. However, it seems that beyond the internal "mount tree" representation, configuration of the namespace hierarchy is largely done using the L4Re namespace concept, with namespaces acting as directories, and non-namespace objects within the hierarchy interpreted as particular file types. Apart from the interpretation of namespaces as directories, it seems that for the most part, dataspaces are employed to be interpreted as file objects. I will admit that I didn't really look very hard at how different systems provide file access before now, but what surprised me slightly was the apparent lack of delegation in L4Re. As far as I can tell, on systems based on kernels like Linux, the open library function will employ a system call to delegate the matter of finding the file and obtaining a way of accessing it to the familiar monolithic-kernel-plus-filesystems arrangement. On more "exotic" systems (than Linux) like Minix 3 or the Hurd, it appears that delegation to a virtual filesystem server [1] or servers [2] occurs to mediate access to specific files. Some systems like Inferno and Plan 9 employ protocols [3] to formalise the client-server relationship. I had almost expected to find similar things in L4Re, but I could only confirm their absence after reviewing the various VFS abstractions. One thing I wonder about is whether the current L4Re approach is able to satisfactorily deal with filesystem content that needs to serve different user entities, with content having different permission and ownership rights. It seems that the filesystem logic has to be available as a library within a program, which is not necessarily a problem. But to avoid filesystem content being completely exposed to the discretion of user programs (reminiscent of the problems with early Network File System implementations), the library would need to call out to other entities, which doesn't appear to be done with the current L4Re abstractions. One could implement support for, say, the ext3 filesystem in a library, operating on a dataspace provided at some kind of mountpoint in a directory (with the directory being provided by a namespace, of course) but it would be like giving a user program access to a block device in a traditional Unix-like system. Are there any articles about the design of L4Re that might explain the motivations here? And are there any accessible-but-detailed articles about other microkernel-based systems and the way in which they structure their filesystem architectures? I looked around on the TU-Dresden site for materials, but I didn't immediately find anything obviously relevant. Paul [1] https://wiki.minix3.org/doku.php?id=developersguide:vfsinternals [2] https://www.gnu.org/software/hurd/hurd-talk.html#pat [3] http://doc.cat-v.org/inferno/4th_edition/styx

1 1

Alignment checking on ARM
by Al Grant 26 Nov '19

26 Nov '19

I'm building L4 on ARM using GCC 7.4.0 on Cortex-A15. ARCH-arm/head.cc enables alignment checking (sets SCTLR.A=1), but we then see an alignment check fault in init_kip_f.cc. With the default compiler options, the GCC cross tools will assume alignment checking is _not_ enabled and will generate code that may use unaligned access. We can override this by compiling with -mno-unaligned-access. But it would be good to know what is intended. If the intention is to be able to run "mainstream" open-source code in userspace, i.e. build code using the standard Linux ABI, we ought to allow that, and not enable alignment checks in SCTLR. Some code will not be fixed by compiling -mno-unaligned-access (because it casts arbitrary unaligned pointers to word-sized types etc.) So my question is, what is the intention? (1) fault unaligned access in kernel and userspace (2) fault unaligned access in kernel but allow in userspace (3) allow unaligned access in kernel and userspace I'm assuming it can't be (3) as the bootstrap code explicitly enables alignment checking. (2) would be a good compromise, it would enable alignment checks which would pick up some possible faults in the kernel, but it would improve portability of ordinary open-source packages in userspace. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

2 1

Kernel Helpers segmentation fault
by Sateesh K 14 Nov '19

14 Nov '19

Hi, My setup is as follows: l4linux 4.19.0-l4 Fiasco.OC Raspberry Pi 3 Model B I am running a helloworld.go program which is causing the following stack trace. (gdb) bt full #0 0xffff0f60 in ?? () No symbol table info available. #1 0x0001143c in kernelCAS64 () at /usr/local/go/src/sync/atomic/asm_linux_arm.s:112 No locals. #2 0x0001103c in sync/atomic.loadUint64 (addr=0x10442080, val=48) at /usr/local/go/src/sync/atomic/64bit_arm.go:10 No locals. #3 0x00071f44 in internal/poll.(*fdMutex).rwlock (mu=0x10442080, read=false, ~r1=160) at /usr/local/go/src/internal/poll/fd_mutex.go:130 mutexBit.lo = 4 mutexMask.hi = 2147481600 mutexMask.lo = 0 mutexSema = 0x1044208c mutexWait.hi = 2048 mutexWait.lo = 0 #4 0x00072314 in internal/poll.(*FD).writeLock (fd=0x10442080, ~r0=...) at /usr/local/go/src/internal/poll/fd_mutex.go:237 No locals. #5 0x00072a94 in internal/poll.(*FD).Write (fd=0x10442080, p=..., ~r1=0, ~r2=...) at /usr/local/go/src/internal/poll/fd_unix.go:243 n = -1212420096 nn = 118 --Type <RET> for more, q to quit, c to continue without paging--c #6 0x00073958 in os.(*File).write (b=..., err=..., f=0x1040c0f0, n=2729821 44) at /usr/local/go/src/os/file_unix.go:243 No locals. #7 0x00072ffc in os.(*File).Write (b=..., err=..., f=0x1040c0f0, n=0) at /usr/local/go/src/os/file.go:144 err.data = 0x12c0e8 <fmt.ppFree> "" err.itab = 0x8b7a8 <fmt.Fprintln+20> "\004" ~r2.data = 0x10456014 "" ~r2.itab = 0x0 #8 0x0008b7fc in fmt.Fprintln (a=..., err=..., n=233960, w=...) at /usr/local/go/src/fmt/print.go:255 p = 0x10456080 #9 0x0008b888 in fmt.Println (a=..., err=..., n=0) at /usr/local/go/src/fmt/print.go:264 No locals. #10 0x000916c0 in main.main () at /home/pi/hello.go:6 No locals. On further analysis, I find that segmentation fault is at __kuser_cmpxchg64. I have enabled CONFIG_KUSER_HELPERS=y when building the linux kernel. Any hint please on how to proceed. Best Regards, Sateesh Kalidas

3 3

http://os.inf.tu-dresden.de/pipermail/l4-hackers/2019/008421.html
by Sateesh K 04 Nov '19

04 Nov '19

Hi, I am trying to bring up Raspberry Pi 3 B peripherals (specifically SD card) onto the linux which is onto of Fiasco.OC. I have read the following thread which is close to what I am doing. http://os.inf.tu-dresden.de/pipermail/l4-hackers/2019/008421.html. I have a question, how to get a .dtb file. Please help. Best Regards, Sateesh Kalidas LinkedIn : http://linkedin.com/in/sateeshkalidas <https://www.linkedin.com/in/sateeshkalidas> Twitter: https://twitter.com/sats34

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers November 2019