l4-hackers March 2019

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

5 participants
5 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

L4Linux with L4Re and Fiasco.OC-UX
by Paul Boddie 04 Apr '19

04 Apr '19

Hello, I have been looking at trying out L4Linux in UX mode as a first step towards its use on "native" Fiasco, and I seem to be experiencing a problem with launching the Linux kernel itself. I have followed the instructions from these pages: https://l4linux.org/download.shtml https://l4linux.org/build.shtml https://l4linux.org/use.shtml Specifically, I have an existing build of UX that has been used for some time to develop software. I have updated it to revision 83 and have checked out the l4linux_requirements, which appear to be some packages (rtc and shmc) I already have. I then performed a build once again: make O=mybuild The L4Linux repository has also been checked out and updated to revision 83. The code has been configured and built using the following invocations: make O=mybuild x86_32-ux_defconfig make O=mybuild menuconfig # to set the L4Re build directory make O=mybuild Here, the mybuild directory is distinct from the L4Re mybuild directory. For the initial RAM filesystem, I downloaded the ramdisk-x86.rd file, and I run the system as follows: make O=mybuild ux E=L4Linux-basic After the usual familiar start-up messages, I see this output specific to the configuration being launched: ---- Ned: loading file: 'rom/l4lx.cfg' libio: Warning: Query of 'vbus' failed! PH 0 offs=00001000 flags=r-x PH-type=0x1 virt=00100000 evirt=0053f000 phys=00100000 ephys=0053f000 f_sz=0043f000 memsz=0043f000 PH 1 offs=00440000 flags=rw- PH-type=0x1 virt=0053f000 evirt=00a58000 phys=0053f000 ephys=00a58000 f_sz=0006ce9f memsz=00519000 PH 2 offs=00371ee0 flags=--- PH-type=0x4 virt=00470ee0 evirt=00470f1c phys=00470ee0 ephys=00470f1c f_sz=0000003c memsz=0000003c Starting binary at 0x100000, argc=6 argv=0xafff4f84 *argv=0xb1007ff4 argv0=rom/vmlinuz External resolver is at 0xa8000bd0 L4Re: rom/vmlinuz: Unhandled exception: PC=0x46980b PFA=97d47fe0 LdrFlgs=0 ---- In order to try and identify the problem, I used the following command: addr2line -e ~/L4/L4Linux/l4linux/mybuild/vmlinux 0x46980b This seems to indicate that the point of failure is at line 2727 in arch/l4/kernel/main.c which is the start of this function: int __ref L4_CV main(int argc, char **argv) So, I wonder what the problem might be that leads to a crash as the main function is being invoked. Have I missed anything obvious? All of this is being done in a Debian unstable chroot on x86. Paul

2 2

Raspberry Pi 3B and L4Linux
by Dejan Cotra 27 Mar '19

27 Mar '19

Hi all, Im trying to run L4Linux on Raspberry Pi 3B. So far I was able to build Fiasco kernel and L4Re for Raspberry Pi 3B. I used aarch64-linux-gnu-gcc toolchain. Also I was able to create Uboot image for hello config, which I successfully run on both qemu and Raspberry Pi 3B. So now Im trying to build L4Linux. First question would be does L4Linux supparm64 architecture? If yes, any hints for configuration? If it does not support arm64 architecture does this also mean that I have to build Fiasco kernel and L4Re for 32bit arm architecture. Thanks in advance, Dejan

2 1

Invalidating mapped flexpages in pagers
by Paul Boddie 19 Mar '19

19 Mar '19

Hello, I have been trying to implement a pager in L4Re where the pager employs a memory region of limited size to satisfy map requests for a dataspace occupying a larger virtual memory region. Upon receiving a map request, the pager identifies the dimensions of the flexpage to be sent to the task experiencing the page fault, and it populates the flexpage's memory with the appropriate data. What this accomplishes so far is that when page faults occur in a task accessing the dataspace, mappings from virtual memory addresses are established in the task referring to the memory region populated by the pager. The task can read from page to page and keep getting new data. However, as each new map request comes in, I want to be able to invalidate the mappings previously made by the pager. Otherwise, I get many pages in the task's address space referring to the same memory, which is obviously not what I intend. Is it possible to send a flexpage from the pager in such a way that the mappings previously established by Fiasco.OC for the memory region are invalidated? Or have I missed some other mechanism for achieving what I am attempting? The L4Re documentation isn't helping me so much here, and I can't seem to find examples of this kind of thing in the source distribution. Thanks for any help anyone can give! Paul

2 5

Huawei R&D lab in Dresden
by Martin Decky 07 Mar '19

07 Mar '19

[Apology for this job ad. Please ignore if you are not interested in job offers.] Dear all, Huawei is starting a new R&D lab in Dresden. The lab shall focus on microkernel OS design and development, with a well-balanced mix between innovative research (including, but not limited to, topics such as HW/SW co-design, heterogeneous computing, data-centric computing, etc.) and prototype development (including, but not limited to, design and implementation of key operating system services for Huawei's microkernel OS, safety and security certification, formal verification, etc.). We offer prospective job candidates the possibility to impact billions of Huawei devices, collaborate on real-world scenarios for the microkernel multiserver OS design (in the automotive, IoT, telco, industrial and other domains) and even influence future HW design (HiSilicon, one of the major semiconductor companies, is a fully owned subsidiary of Huawei). We are also supporting mutually beneficial collaboration with academia (e.g. ETH Zurich, TU Dresden) and microkernel-related companies. If you are interested in discussing the details of the senior engineer, software architect and researcher roles we offer, please do not hesitate to contact me. We will be also more than happy to talk to you at the upcoming Fachgruppe Betriebssysteme Frühjahrstreffen 2019 in Erlangen next week [1] and at EuroSys 2019 in Dresden in about three weeks [2]. [1] https://www.betriebssysteme.org/aktivitaeten/treffen/2019-erlangen/ [2] https://www.eurosys2019.org/ Best regards Martin Decky Senior Research Engineer Huawei Technologies German Research Center

1 0

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 March 2019