- l4-hackers - example.com Site

Compatibility of microkernel systems with legacy OSes; was L4Re with GCC 9; Repositories and Roadmaps
by Andrew Warkentin 30 Jan '20

30 Jan '20

On 1/28/20, Martin Decky <martin.decky(a)huawei.com> wrote: > > FYI: The microkernel-based OS Huawei is working on internally has Linux > compatibility (both from the syscall API and from the drivers point of view) > as one of its goals. > Is it natively Unix-like, or is the Linux compatibility layer some kind of containerized "penalty box" that doesn't really integrate into the system? Also, since you're not developing it publicly , that may limit its ability to compete with Linux, which of course has a completely open development model without copyright assignment. In addition, from one article I read, it sounded like even though it is going to be open source eventually, it was designed with the assumption that it would be running on tivoized devices with locked bootloaders, with no way for the user to get full control. > > GNU Hurd obviously also tries to be GNU/Linux compatible (not on the syscall > level, but on the glibc level). Many other microkernel-based systems (e.g. > Genode, just to name one) maintain their own adaptation layers for hosting > Linux device drivers. > >From what I understand, Hurd doesn't implement a lot of Linux-kernel-specific APIs. On 1/28/20, Paul Boddie <paul(a)boddie.org.uk> wrote: > > I actually think that most people agree with you on this, at least when > confronted with the notion for the first time. But I don't think such > considerations should overrule every other consideration: it reminds me of > people in the English-speaking world (particularly in my country of origin) > > who say that if they could be bothered to learn a foreign language, it would > > be "something like Spanish that a lot of people speak", justifying the > choice > in terms of all the millions of individual speakers with whom they could be > > having hypothetical conversations that, naturally, they wouldn't end up > having > anyway. > For my purposes, I would much rather have an OS that runs Linux programs natively rather than having to port every single application I want to run. > > Your project being this one: > > https://gitlab.com/uxrt > > Is there a summary of it anywhere? > This is the closest thing to a summary that I have at the moment: https://gitlab.com/uxrt/uxrt-toplevel/blob/master/architecture_notes > > I wonder whether people don't already rely on things like L4Linux for such > functionality. However, I don't personally think that having boxed-up driver > > frameworks is particularly elegant or plays to the strengths of > microkernel- > based paradigms. In L4Re, I found myself staring down bits of imported Linux > > kernel code and wondering whether things might not have been easier - and > most > certainly clearer - had something been developed independently. > Yes, it's true that it's maybe not the most elegant way to run drivers, but I think it's a worthwhile trade-off for broad hardware support. As far as UX/RT is concerned it's not really that big a sacrifice because it will have relatively little vertical modularization anyway (e.g. instead of separate disk filesystem, partition driver, and disk device driver processes, all three will be incorporated into a single "disk server" process, much as on QNX; this should improve performance over most other microkernel OSes while not really sacrificing much as far as security or error recovery). > > Of course, the real solution is to have a library of functionality that a > variety of systems could use. Then, we wouldn't need to pick over the > remains > of some other project. Being familiar with this industry over a couple of > decades, however, I am fully aware that people exhibit rather strong > tendencies to insist that such cooperation is not possible, usually because > of > something super-special that they insist that only they are doing. > I'd be willing to cooperate on such libraries as long as they don't place unnecessary burdens on client code.

3 9

Hardware-aided Trusted Computing devroom at FOSDEM
by Vasily A. Sartakov 12 Dec '19

12 Dec '19

Hello I would like to invite your to participate in a new devroom: Hardware-aided Trusted Computing. The devroom is devoted to open source projects on top of modern TEEs like Intel SGX, AMD SEV/SVE, Arm TrustZone. You can find the schedule here: https://fosdem.org/2020/schedule/track/hardware_aided_trusted_computing/ I hope this will be interesting for the community. See you at FOSDEM. -- Dr.-Eng. V. A. Sartakov

1 0

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

CfP: FOSDEM 2020 - Microkernels and Component-based OS devroom
by Julian Stecklina 04 Oct '19

04 Oct '19

[Resent due to wrong Reply-To: header] FOSDEM 2020 - Microkernels and Component-based OS devroom CALL FOR PARTICIPATION The developers of several free and open-source microkernel-based operating systems will meet at FOSDEM 2020 [1] in Brussels, Belgium and will share a developer room. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-, unikernel-, and component-based operating systems. Possible topics include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * used languages and tools * enabling support for hardware (architectures, device drivers) * enabling support for programming languages * maintenance and testing * security and robustness * trends and challenges * use cases, experiences, lessons learned and demos The deadline for your proposal is on December 1, 2019. Please use the Pentabarf [2] system to submit your proposals. You do not need to create a new account if you already have one. Make sure to include the following in your proposal: * title of your talk (will be printed in the FOSDEM booklet) * your full name (will be printed in the FOSDEM booklet) * a short abstract (one or two paragraphs) * duration of your talk (at least 25 and no longer than 55 min) The official devroom schedule (along with the accepted talks) will be announced on December 15 on the devroom's mailing list [3] and the speakers will be notified via e-mail. The schedule will also be published on the FOSDEM website. You are invited to send any other suggestions for what you want to see or do at the devroom to the list. We will also use this list to organize the traditional devroom dinner that will happen on the first day of FOSDEM. About the devroom Since the first Microkernel devroom at FOSDEM 2012, this devroom has been part of each following FOSDEM. The focus gradually widened to include component-based operating systems. By now it has become a somewhat institutionalized tradition for the community to meet there; to this date over a dozen projects have participated in one way or another. Each of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. Social events It also has become a habit that the microkernel projects dine together somewhere in Brussels. The year 2020 will not be any different, so there is going to be a dinner on Saturday night. We try place a reservation, so we will inform you about the exact location and time later. Consult the FOSDEM web and other projects for additional social events such as the famous FOSDEM-organized Friday Beer Event and the FOSDEM-arranged free sightseeing tours for spouses. About FOSDEM FOSDEM is a two-day event organised by volunteers to promote the widespread use of free and open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as the best such conference in Europe. FOSDEM covers a wide spectrum of free and open source software projects, and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) with network/internet connectivity and projectors where teams can meet and showcase their projects. Devrooms are a place for teams to discuss, hack and publicly present latest directions, lightning talks, news and discussions. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. Every year, FOSDEM hosts more than 5000 developers at the ULB Solbosch campus. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. No registration necessary. Important dates recap * 2019-12-01: Deadline for submissions * 2019-12-15: Schedule published and speakers notified of acceptance * 2020-02-01: Devroom Dinner (details to be announced) * 2020-02-01/2020-02-02: The devroom takes places (check the schedule) Links [1] https://fosdem.org/ [2] https://penta.fosdem.org/submission/FOSDEM20 [3] https://lists.fosdem.org/listinfo/microkernel-devroom

1 0

CfP: FOSDEM 2020 - Microkernels and Component-based OS devroom
by Julian Stecklina 04 Oct '19

04 Oct '19

FOSDEM 2020 - Microkernels and Component-based OS devroom CALL FOR PARTICIPATION The developers of several free and open-source microkernel-based operating systems will meet at FOSDEM 2020 [1] in Brussels, Belgium and will share a developer room. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-, unikernel-, and component-based operating systems. Possible topics include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * used languages and tools * enabling support for hardware (architectures, device drivers) * enabling support for programming languages * maintenance and testing * security and robustness * trends and challenges * use cases, experiences, lessons learned and demos The deadline for your proposal is on December 1, 2019. Please use the Pentabarf [2] system to submit your proposals. You do not need to create a new account if you already have one. Make sure to include the following in your proposal: * title of your talk (will be printed in the FOSDEM booklet) * your full name (will be printed in the FOSDEM booklet) * a short abstract (one or two paragraphs) * duration of your talk (at least 25 and no longer than 55 min) The official devroom schedule (along with the accepted talks) will be announced on December 15 on the devroom's mailing list [3] and the speakers will be notified via e-mail. The schedule will also be published on the FOSDEM website. You are invited to send any other suggestions for what you want to see or do at the devroom to the list. We will also use this list to organize the traditional devroom dinner that will happen on the first day of FOSDEM. About the devroom Since the first Microkernel devroom at FOSDEM 2012, this devroom has been part of each following FOSDEM. The focus gradually widened to include component-based operating systems. By now it has become a somewhat institutionalized tradition for the community to meet there; to this date over a dozen projects have participated in one way or another. Each of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. Social events It also has become a habit that the microkernel projects dine together somewhere in Brussels. The year 2020 will not be any different, so there is going to be a dinner on Saturday night. We try place a reservation, so we will inform you about the exact location and time later. Consult the FOSDEM web and other projects for additional social events such as the famous FOSDEM-organized Friday Beer Event and the FOSDEM-arranged free sightseeing tours for spouses. About FOSDEM FOSDEM is a two-day event organised by volunteers to promote the widespread use of free and open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as the best such conference in Europe. FOSDEM covers a wide spectrum of free and open source software projects, and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) with network/internet connectivity and projectors where teams can meet and showcase their projects. Devrooms are a place for teams to discuss, hack and publicly present latest directions, lightning talks, news and discussions. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. Every year, FOSDEM hosts more than 5000 developers at the ULB Solbosch campus. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. No registration necessary. Important dates recap * 2019-12-01: Deadline for submissions * 2019-12-15: Schedule published and speakers notified of acceptance * 2020-02-01: Devroom Dinner (details to be announced) * 2020-02-01/2020-02-02: The devroom takes places (check the schedule) Links [1] https://fosdem.org/ [2] https://penta.fosdem.org/submission/FOSDEM20 [3] https://lists.fosdem.org/listinfo/microkernel-devroom

1 0

Fiasco.OC-UX on MIPS?
by Paul Boddie 30 Sep '19

30 Sep '19

Hello again, Having been using the MIPS-based CI20 single-board computer a bit more recently, I wondered if it might be possible to get the user mode Fiasco kernel working on MIPS. As I understand it, the UX variant of Fiasco only works on IA32 (x86, 32-bit), and although MIPS isn't particularly popular, it would at least be useful to me. However, having looked at the code, it seems like quite a bit of work to unpick the IA32-related aspects from the UX-specific code. There appears to be a fair amount of descriptor table usage, for instance, and despite reading the thesis about it [1], I don't feel I have a decent-enough overview of what would really need doing to port the UX variant to another architecture. So far, I've reviewed the MIPS code which employs a Proc abstraction and has a number of functions in the Mips namespace which could be replaced to maintain a "virtual" processor in the user mode kernel. It seems that the existing UX variant employs an Emulation abstraction for things like the processor status, and perhaps the Proc abstraction could take over these responsibilities. Quite how many privileged CPU registers would need maintaining probably depends on how much other code would still be using them. This brings me to an awkward difference between IA32 and MIPS: that of the page fault handling and memory management. MIPS has no inherent notion of page table structures that are held by the CPU and consulted by it when addressing errors occur. Instead, an exception handler is invoked to populate various privileged registers and to perform privileged instructions. However, it seems to me that Fiasco needs to maintain a page directory, anyway, and that the user mode kernel is not likely to be attempting the actual memory management operations, either. Consequently, it is tempting to think that the existing UX code might also be usable on MIPS. This would actually involve replacing a dedicated page directory implementation that appears to be present for MIPS with the one that other architectures appear to use. One detail that might need preserving is the code path dealing with TLB lookups (as a consequence of addressing errors), but it may be the case that page faults are dealt with more directly when signals arrive - perhaps what the UX code does now - and that the TLB exception vectors will remain unused. When considering some of these issues, I did wonder about the role of certain architecture-specific aspects of the MIPS implementation. The existing UX code seems to deal with "vectors" and seems rather connected to interrupt descriptor tables (or their emulation). On MIPS, exception vectors are typically resident in kernel memory and have specific addresses. It seems to me that the handling of exceptions (caused by signals) would direct execution via these vectors and thus preserve the existing exception.S implementation, albeit relocated to user memory. I guess the alternative would involve rewriting such things and using emulated processor features directly instead of trapping and handling privileged instructions. (I did also wonder to what extent the assembly language could also be migrated to C++ even for the native MIPS implementation.) That brings me to a discussion about the purpose of the user mode kernel variant. As I understand it, one of the aims is to preserve architecture- specific code so as to give that code some possible testing and general exercise: it might actually help in the development of the kernel more generally. Is this a reasonable understanding? Initially, I thought that UX would actually be architecture-neutral (in terms of mechanisms; obviously the code would be native), but it appears that a stated aim is to be able to run existing binaries unchanged. Would an architecture-neutral UX variant make any sense? I suppose I could go on and on, here, but as far as I can tell there are quite a few things that would need deciding in order to have a realistic chance of ever getting this working, amongst others that I will have forgotten or not considered... * Redefining the memory layout for kernel and task processes (so as to work within the host system constraints) * Separating generic and native functionality for various central abstractions * Replacing the memory management with a mechanism similar to that employed by the existing UX code * Defining a usable interrupt and exception paradigm (here, I am tempted to introduce a second-level controller for user mode interrupts) * Determining which modules are required and how the code should be built (largely using the existing UX configurations) * Testing and integrating the host system functionality required for the user mode kernel to function (process tracing, signal handling, system call invocations using the trampoline, thread management) On this last point, I investigated the trampoline mechanism on a MIPS Linux system, and it does seem viable. There are a few tricks to getting system calls working (that can be learned from glibc and the kernel itself), although the trick employed to cancel them may not work. Also, the paper [1] describes the need to acquire signal context information by deploying a signal handler and having processes capture context data on the kernel's behalf. This may not be necessary on MIPS since the interesting details - those that seem to be posted on the stack when IA32 exceptions occur - are available via the registers exposed by ptrace on MIPS. Indeed, I learned that ptrace is something of a fickle friend, not necessarily providing the same level of support on all systems. And thus, I wondered if there is still much sustained interest in the user mode approach or if people regard other technologies to be more practical and/or interesting. If you have read this far, maybe you might be able to share your thoughts on the topic. It has been frustrating trying to get a good overview of the code - I'm not sure the preprocessor really helps, to be honest - and while I would like to be able to get the user mode kernel working on another architecture, I would rather like to know if it is really worth my while. Getting a better understanding is therefore the first step in finding out. Paul [1] http://os.inf.tu-dresden.de/papers_ps/steinberg-beleg.pdf

4 11

Unable to create Goos FB in UEFI mode
by Adi Lima 09 Sep '19

09 Sep '19

Hi, I've been trying to make this one work, but in vain, so far... Either using qemu or in real hardware, all failed when booting from UEFI. >From qemu's stdio I know that the boot has been completed successfuly, but it seems like fb-drv was unable to support current default mode from EFI Framebuffer boot (or it is trying to switch to some other mode, and failed?). I was using standard ex_fb_spectrum_cc, with x86-fb.io, x86-fb.cfg and x86-legacy.devs, all loaded by grub2 as Multiboot2 and Module2 Everything was fine if booted using BIOS, but I haven't try on UEFI mode with CSM. Can you give me a hint of what to try next, please? Thanks in advance :-) -- FX. J. Adi Lima Trivision Studio

2 1

Full virtualization on Raspberry PI 4
by clim atisefr 29 Aug '19

29 Aug '19

Hi, I know the Raspberry PI 3 does not support the full virtualization and only para-virtualization is supported. It seems that the Raspberry PI 4 with the Broadcom 2711 (Quad-core Cortex-A72 ARM v8 64-bit SoC @ 1.5 GHz) may support it. Is there any development to support this platform with L4RE ? or any hint to start it ? Thanks, Chris

2 1

Porting Pistachio to Cell
by Tyson Key 22 Aug '19

22 Aug '19

Hi, In a wave of projects, over the years, I've been working on trying to rescue the Pistachio GitHub repository from bitrot, and build it with modern tools (I have one project that builds, and runs on x86, with an ancient version of GRUB, and another, that's a complete basket case, since KickStart is broken, but that's another matter), and saw, with some interest, ports to various Open Firmware-enabled platforms, and wondered if anyone had any guides to building, and running a PowerPC 64-bit userland, and boot infrastructure? There was an old guide to building with PSIM, and PPC32, on the KIT Website, but it seems incomplete, and it doesn't seem obvious, as to how one would build a bootable disk image, or how to prepare the compiled userland to run on hardware. Since the site is pretty dated, and the code has changed, since then, is that information even relevant? I've got access to a FreeBSD 12 PPC64 build environment, under QEMU's PSeries Xenial machine emulator, and I'm in the process of trying to set up a direct development environment, on a PlayStation 3 system, so access to PowerPC toolchains isn't a problem. Eventually, I'm planning on seeing if I can use the existing code, and parts of FreeBSD's PlayStation 3 port, to implement a basic, first-draft port to run on Sony's CellOS/BEAT ABI-based hypervisor, or in GameOS mode, with PetitBoot. Thanks in advance, for any assistance, Tyson Key.

1 0

New L4Re component released: virtio-net
by Jakub Jermar 29 Jul '19

29 Jul '19

Dear L4 hackers, last week we released virtio-net on GitHub[0]. Together with the previously released L4Re components, virtio-net can be used to interconnect two VMs with a virtual network. We also wrote a little tutorial which illustrates that[1]. Happy hacking, Jakub [0] https://github.com/kernkonzept/virtio-net [1] https://github.com/kernkonzept/manifest/wiki/MultipleVMs -- Kernkonzept GmbH at Dresden, Germany, HRB 31129, CEO Dr.-Ing. Michael Hohmuth

1 0

kernel error
by ssrmurthy saka 04 Jul '19

04 Jul '19

Hi team, I am using "4.13.0-36-generic" kernel and i exported cross compiler of version "gcc-linaro-7.4.1-2019.02-i686_arm-linux-gnueabihf". when i try to compile new odule i am facing below error. can you please help on this. make -C /lib/modules/4.13.0-36-generic/build/ M=/home/tessolve/c modules make[1]: Entering directory '/usr/src/linux-headers-4.13.0-36-generic' CC [M] /home/tessolve/c/vm.o In file included from ./include/asm-generic/int-ll64.h:10:0, from ./arch/arm/include/uapi/asm/types.h:4, from ./include/uapi/linux/types.h:4, from ./include/linux/compiler.h:231, from ./include/linux/init.h:4, from /home/tessolve/c/vm.c:1: ./include/uapi/asm-generic/int-ll64.h:11:10: fatal error: asm/bitsperlong.h: No such file or directory #include <asm/bitsperlong.h> ^~~~~~~~~~~~~~~~~~~ compilation terminated. scripts/Makefile.build:315: recipe for target '/home/tessolve/c/vm.o' failed make[2]: *** [/home/tessolve/c/vm.o] Error 1 Makefile:1550: recipe for target '_module_/home/tessolve/c' failed make[1]: *** [_module_/home/tessolve/c] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-4.13.0-36-generic' Makefile:4: recipe for target 'all' failed make: *** [all] Error 2 Thanks, murthy

1 0

Want to run L4Re on Raspberry PI.
by Lei Zhou 28 Jun '19

28 Jun '19

HI, I'm looking for the information and procedure how to compile and deploy L4Re on Raspberry PI. Any feedbacks would be greatly appreciated! Thanks, Lei

5 26

Enable L4Linux network access on Raspberry Pi-b.
by Lei Zhou 24 Jun '19

24 Jun '19

Hi Adam & Hackers, Has anybody enabled network access for L4linux Raspberry pi3? I read through all the history on related topics and understand the process to get it working. I summarized the steps as below and major problem for me is how to convert device tree for L4linux and compose corresponding rpi_deices.io configuration. Please see my specific question inlined in those steps. Thanks in advance for your feedback. 1. configure and Compile l4linux to support flattened device tree support. Also enables CONFIG_USB_LAN78XX=y && CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC95XX=y CONFIG_L4_SERVER = y CONFIG_USE_OF = y 2. Adapt https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2… into ./l4linux/arch/l4/boot/dts/simple.dts [Lei's question]: I understand why bcm2710-rpi-3-b.dts cannot be used directly because some of the reg_address physical address doesn't apply and might fail to be mapped. How can I pick network access specific device nodes and its dependancies(power or clock etc) and how to change those illegal reg_address? 3. Create an rpi3_devices.io for L4Re with the devices and their resources and assign the desired devices to a vbus. [Lei's question]: Should I define all device nodes one-2-one mapping from step 2's device tree? 4. Update your ned script and modules.list -- vim:set ft=lua: local L4 = require("L4"); loader = L4.default_loader; -- Start io vbus_l4linux = loader:new_channel(); --vbus_input = loader:new_channel(); --vbus_fbdrv = loader:new_channel(); loader:start( { caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0); icu = L4.Env.icu; -- input = vbus_input:svr(); l4linux = vbus_l4linux:svr(); -- fbdrv = vbus_fbdrv:svr(); }, log = {"IO", "y"}, l4re_dbg = L4.Dbg.Warn, }, "rom/io -vvv rom/rpi_devices.io"); -- Start L4linux loader:start( { caps = { -- fb = mag_svc:create(L4.Proto.Goos, "g=640x480"); vbus = vbus_l4linux; }, log = L4.Env.log:m("rws"), l4re_dbg = L4.Dbg.Warn, }, "rom/vmlinuz mem=64M console=ttyLv0 l4x_rd=rom/ramdisk- l4x_dtb=rom/rpi3b-simple.dtb" .. L4.Info.arch() .. ".rd " .. "root=1:0 ramdisk_size=4000 init=/bin/sh earlyprintk=1 "); 5. Build final bootstrap_l4linux.uimage for Raspberry. Thanks very much! Lei Zhou

2 2

How to enable Guest Linux VM on Raspberry PI3?
by Lei Zhou 17 Jun '19

17 Jun '19

After I brought up L4Re and Fiasco on Raspberry PI3, would like to enable guest Linux VM on top of it. I'm looking at the link https://github.com/kernkonzept/manifest/wiki/LinuxVM and hoping I can do the same thing on Raspberry PI3. The link seems using hardware-assisted virtualization option uvmm based for guest VM. There seems also L4Linux Paravirtualization option. Which option should I use for me to enable guest LInux VM on Raspberry PI3? In addition, when I followed the link to try on QEMU first, encounter some "vbus" capability issue. I followed the guidance exactly as the link says. However, when I started the command to spawning the Linux VM as: $make E=uvmm-basic qemu It failed with following log: ============================================ MOE: virtual user address space [0-7fffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [41100000-411974b8] [C:107000] uvmm BOOTFS: [41198000-411c4e58] [C:109000] l4re BOOTFS: [411c5000-41246770] [C:10b000] ned BOOTFS: [41247000-412475c4] [C:10d000] virt-arm_virt.dtb BOOTFS: [41248000-41430200] [C:10f000] ramdisk-armv8.cpio.gz BOOTFS: [41431000-41431242] [C:111000] uvmm-basic.ned BOOTFS: [41432000-42618a00] [C:113000] Image.gz MOE: cmdline: moe rom/uvmm-basic.ned MOE: Starting: rom/ned rom/uvmm-basic.ned MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/uvmm-basic.ned' VMM[vmbus]: 'vbus' capability not found. Hardware access not possible for VM. VMM[main]: Hello out there. VMM: FATAL: ERROR: ARM GIC virtualization does not work without passing the virtual GICC via the vbus VMM[vm]: Device creation for virtual device virtio_uart@20000 failed. Disabling device. VMM[]: virtio_net(a)10000.l4vmm,virtiocap: capability net is invalid. VMM[vm]: Device creation for virtual device virtio_net@10000 failed. Disabling device. VMM: FATAL: ERROR: ARM GIC virtualization does not work without passing the virtual GICC via the vbus VMM[vm]: Device creation for virtual device interrupt-controller failed. Disabling device. VMM: FATAL: Parsing timer interrupt: Argument out of range qemu-system-aarch64: terminating on signal 2 Makefile:6: recipe for target 'do-all-make-goals' failed make: *** [do-all-make-goals] Interrupt ========================================================================= Any feedbacks are greatly appreciated! Lei Zhou

3 9

L4Re, BUILD_ARCH, cross-building for ARM on MIPS
by Paul Boddie 11 Jun '19

11 Jun '19

Hello, In attempting to investigate building L4Re/Fiasco.OC for the Raspberry Pi Zero, I encountered an unusual problem: unusual because, I suppose, most people do not try and cross-build on architectures other than x86(-64). When performing the initial L4Re build directory initialisation step... make B=mybuild ...BUILD_ARCH seems to be set to x86 even on other architectures. This then causes CCXX_FLAGS to be populated with x86-dependent settings such as -m32, and the gcc host compilers for MIPS raise errors upon encountering these unrecognised arguments. Here is the offending command in the top-level Makefile (line 376 in my version, r83 in Subversion): GENDEP_OUTPUT=$$X.out $(CC) $(CCXX_FLAGS) -c $$X -o $$X.o Although it seemed like the config step could be performed after ignoring these errors, I did wonder if there might be some undesirable consequences. In the end, I found that the following invocation was needed: make B=mybuild CC=gcc CXX=g++ LD=ld BUILD_ARCH=mips CPU=32r2 CPU_ABI=32 After that, things seem to work as expected. I imagine that there is a "chicken and egg" situation here: the appropriate settings would be obtained from the configuration, but the command being run sets up the configuration. Has anyone else seen this problem before? Paul

2 1

Fwd: l4linux running lmbench
by yangzeng 29 May '19

29 May '19

Dear Developers: I am a newcomer to l4linux, I use the default configuration to run l4linux-mag, now I want to run lmbench on l4linux, how should I put lmbench into l4linux Best Regards

2 1

L4linux startup problem
by yangzeng 20 May '19

20 May '19

Hi L4 hackers, I encountered some problems when running l4linux. I used the default configuration to run l4linux. It is good to use make qemu, but when I use make grub2iso to generate iso, use qemu-system-x86_64 -cdrom l4linux-mag.iso to run. The following error occurred mag | Hello from MAG mag | mapped frame buffer at 0x1200000 mag | ERROR: could not start screen driver for given video mode. mag | Maybe unsupported pixel format... exiting mag | MAG: destroy FB svc Ned[lua]: Warning: Capability 433000 does not support the meta protocol: -2004 lua error: rom/l4lx-gfx.cfg:52: attempt to call a nil value (method 'create'). qemu-system-x86_64: terminating on signal 2 what should i do? thanks

1 0

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

Setting up ssd and hard disk in l4linux
by Xinyue Wu 26 Feb '19

26 Feb '19

Dear Developers, I have been trying to mount ssd and hard disk in l4linux. There are some similiar questions in previous archives, and I have done the following things according to them: - configure 'devs' file and 'io' file, add sata to vbus - enable PCI support - enable vPCI driver - enable AHCI driver But when I ran l4linux in hardware, I still couldn't find sata in pci bus, nor could I found my devices under /dev. Does anyone have some suggestions? Or maybe there are something wrong in my device configuration, please let me know if so. Thanks a lot. x86-legacy.devs ================= local Res = Io.Res local Hw = Io.Hw Io.hw_add_devices(function() SATA = Hw.Device(function() Property.hid = "SATA"; Resource.iop1 = Res.io(0x1f0, 0x1f7); Resource.iop2 = Res.io(0x3f6, 0x3f7); Resource.irq = Res.irq(14); end); end) l4lx-x86.io ==================== local hw = Io.system_bus() Io.add_vbusses { l4linux = Io.Vi.System_bus { -- Add a new virtual PCI root bridge PCI0 = Io.Vi.PCI_bus { pci_sata = wrap(hw:match("SATA")); }; }; } l4lx.cfg ====================== local L4 = require("L4"); loader = L4.default_loader; vbus_l4linux = loader:new_channel(); vbus_input = loader:new_channel(); loader:start( { caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0); icu = L4.Env.icu; l4linux = vbus_l4linux:svr(); }, log = {"IO", "y"}, l4re_dbg = L4.Dbg.Warn, }, "rom/io rom/x86-legacy.devs rom/l4lx-x86.io"); loader:start( { caps = { vbus = vbus_l4linux; }, log = L4.Env.log:m("rws"), }, "rom/vmlinuz mem=1024M console=ttyLv0 earlyprintk=1 l4x_rd=rom/ramdisk-256m.rd root=1:0 ramdisk_size=268435456");

2 1