- l4-hackers - example.com Site

L4Re uvmm guest OS
by Radu Aron 22 Aug '23

22 Aug '23

Hi, Is it possible to have a Windows guest OS running on top of L4Re? If so, could you provide some insight into how that could work? It seems like uvmm doesn't allow booting from an ISO image, or am I missing something?

2 1

ARM TrustZone with UVMM
by Michael Willig 11 Jun '23

11 Jun '23

Hi all, I would like to try Fiasco/L4Re for a Mixed-Critical Xilinx UltraScale+ FPGA-MPSoC (the hardware accelerators on the FPGA should be virtualized/isolated for mixed-critical applications) Is there somewhere an example (or at least starting point) of an ARM Trustzone configuration of a Normal World VM and Secure World VM (with UVMM/Fiasco as hypervisor that also takes care of the ARM Trustzone configuration)? Best regards Micha

2 1

L4Re: Allocating pinned memory and obtaining its physical address
by Paul Boddie 24 May '23

24 May '23

Hello, Sorry to be lazy and not dig too deeply into the documentation and code, but once upon a time it was possible to use the l4re_ma functions to allocate pinned memory. Then, one would use the dataspace protocol to obtain the physical address of the memory via the capability involved in memory allocation. This exercise would be sufficient to get into a position to initialise peripherals in a system-on-a-chip, setting registers with the physical memory addresses they would need for things like DMA. The initialisation of things like framebuffers would rely on this procedure. I see that the "phys" operation in the dataspace protocol was discarded some time ago, and now there is a "DMA space" abstraction instead: https://l4re.org/doc/group__api__l4re__c__dma.html Are there any examples of how I might obtain a physical address associated with a block of memory using this new API? Thanks in advance for any guidance that might be offered! Paul

3 5

L4Re: Boot module copying and the MIPS Creator CI20
by Paul Boddie 21 May '23

21 May '23

Hello, As part of reviewing my earlier efforts getting L4Re running on various MIPS- based devices, I have been trying to get the bootstrap module to start the kernel on the MIPS Creator CI20, and here I encounter a strange problem. The bootstrap code appears to copy the different modules in the payload around in memory, and for the kernel, it finds the different sections at 0x2f4000 in physical memory (accessed via 0x802f4000), copying them into locations relative to the indicated module base address (for example, 0x1100000 or 0x2000000). From their new locations, each section of the kernel is then copied to its desired final address. So, the section of the kernel providing its entry point can be found at 0x2f4000 + 0xa411c, this being copied to base + 0xa411c, before finally being copied to 0x800d3000. However, the contents of memory at the final location (0x800d3000) are not correct, nor are they at the "staging" location of base + 0xa411c, even though they do correspond to the expected contents of the kernel binary at their original location. What I expect to see at the entry point is... 40806000 mtc0 zero,c0_status 000000c0 ehb What I see instead is... ffffffff bea3ffdf Apart from at the original location in the payload (0x2f4000 + 0xa411c). As far as I can tell, the second word is nonsense, and it is usually followed by more ffffffff words. So, it is as if copying failed for this particular section. Oddly, this only seems to affect the section of the kernel providing the entry point, and all other sections appear to be copied correctly from their original locations. One factor might be that this section is the last one that is copied. Does this seem like recognisable behaviour of some kind of misconfiguration? For the most part, I am just rebasing my old patches on the current L4Re and Fiasco versions, so I didn't expect a problem at this level. Regards, Paul

3 12

building x86-32
by Lieutenant_Beaver＠web.de 11 Mar '23

11 Mar '23

3 3

GI Operating-Systems + Fault Tolerance Meeting
by Horst Schirmeier 26 Jan '23

26 Jan '23

Hello microkernel hackers from Dresden and afar, the German Society of Informatics (GI) has a Special Interest Group on Operating Systems ("Fachgruppe Betriebssysteme" [1]), with members from both academia and industry. This group meets twice a year to network and to discuss their current work. The upcoming spring meeting, organized together with GI's fault-tolerance SIG ("Fachgruppe Fehlertolerierende Rechensysteme" [2]) will be hosted by TU Dresden on March 06+07 (noon to noon). Please consider attending and/or submitting a talk (details below and on the following website): https://www.betriebssysteme.org/aktivitaeten/treffen/2023-dresden/ Best regards, Horst Schirmeier [1] https://betriebssysteme.org [2] https://fg-fers.gi.de/ === Topic: "Operating Systems and Dependable Systems" === Dependability – the totality of safety, security, availability, reliability, and maintainability – is a fundamental attribute of safety-critical hardware and software systems. In the automotive industry, for example, current trends in autonomous driving present entirely new challenges in marrying fault tolerance and maximum performance while keeping costs low. The answers to these research questions ultimately call for a comprehensive investigation of the interactions between applications, system software, and hardware. In this spirit, the joint spring meeting of the GI's "Operating Systems" (FGBS) and "Fault-Tolerant Computing Systems" (FERS) special interest groups will be focusing on novel approaches to the analysis, design, and evaluation of dependable systems and on the exchange of ideas between the two communities. Areas of interest for submissions include, but are not limited to: - Fault tolerance mechanisms at all layers of the system - Dependability and real-time - Isolation and integration mechanisms in software - Test, analysis, evaluation, and verification - Robust system architectures and HW/SW co-design - Practical and field reports on safety-critical systems and their applications - Models, development processes, and standards Contributions outside the main focus of the event are most welcome as well. Please submit either a one-page abstract (presentation only) or a 2- to 4-page unpublished paper (ACM conference style) in German or English. A program committee consisting of members of the two steering boards will review the submissions and decide on their acceptance. In case of acceptance, papers (2-4 pages) will be published in the digital library of the Gesellschaft für Informatik. We explicitly welcome presentations in English. The talks' language will be indicated in the program to facilitate non-German members' participation in our workshops in the future. The event will also be organized in a hybrid format. -- Prof. Dr.-Ing. Horst Schirmeier Professur für Betriebssysteme Technische Universität Dresden Fakultät Informatik 01062 Dresden Tel.: +49 (351) 463-38321 office: Andreas-Pfitzmann-Bau, R.3102 Nöthnitzer Str. 46, 01187 Dresden (Campus-Navigator: https://tud.link/seh0) https://tud.de/inf/os

1 0

L4Re: uClibc and UTCB/TCR initialisation
by Paul Boddie 01 Oct '22

01 Oct '22

Hello, I have been working through reimplementing the mechanisms involved with launching programs in L4Re, managing to initiate programs apparently successfully under QEMU emulating amd64 and x86, but I have been less successful getting them to work under QEMU emulating a MIPS system (MIPS Malta). My arrangement of threads within tasks should be fairly similar to what L4Re normally employs to host and run programs, and I wrote it up here: "Gradual Explorations of Filesystems, Paging and L4Re" https://blogs.fsfe.org/pboddie/?p=2540 The pictures at the end summarise what has been done. I have a region mapper running in a thread in the same task as the program to be launched. The region mapper handles page faults and interacts with dataspaces on the program's behalf. Faults caused by the region mapper are handled by the initiating task. What I seem to have avoided previously but now experience is that after the region mapper has been started, it is able to service page faults, but after a certain point in the execution of the program of interest, the region mapper itself experiences an exception in the __pthread_cleanup_push_defer function within uClib's pthreads implementation, specifically at this line: buffer->__canceltype = THREAD_GETMEM(self, p_canceltype); Digging into this, I found that self is apparently zero. Since self is obtained from a call to thread_self which in turn obtains the user[0] member of the thread control register structure (providing the thread descriptor address), I can only conclude that either this member has not been initialised or that it has been overwritten by the other thread as it started up. Investigating uClibc startup, I notice that pthread initialisation does indeed involve a traversal of UTCB areas, zeroing user[0] in the supposedly free UTCB blocks. And with the region mapper having failed, the main program will also fail fairly quickly, with an exception typically occurring in the __pthread_initialize_minimal function, coincidentally just after this zeroing has occurred, just before a call to __libc_setup_tls. I have been looking for hints as to how this work is done in L4Re normally. Given that the region mapper and the program being run are normal programs that are executed via their conventional entry points, this resulting in the initialisation of the C library and threading for each payload, it seems that some measures must be in place to prevent this initialisation from causing conflicts in the UTCB area. For instance, I see that in the file... pkg/l4re-core/l4re_kernel/server/src/main.cc ... the __libc_alloc_initial_tls function is redefined to presumably override the weakly referenced version in uClibc, but if this were invoked it would probably cause uClibc to fail during initialisation, at least unless the zero page is going to be used (but it would need allocation somewhere else), so maybe it doesn't override anything after all. In any case, this function would only change some aspects of how __libc_setup_tls would work, so maybe it is a distraction. I did wonder if there was something specific about MIPS that would cause this failure, investigating the user-local register (ULR) used to hold UTCB-related information, but getting the UTCB address via the ULR would appear to work: otherwise, the region mapper would probably not start up. I also wondered about program initialisation issues, since I did experience problems on actual MIPS hardware related to various registers not being set up correctly, but the generated code seems fairly comprehensive in this regard these days (and maybe it was all along but I encountered a confounding phenomenon). Does anyone have any familiarity with how this actually works and might be able to indicate what I am doing wrong? As always, thanks for any help that can be offered! Paul

1 1

Creating tasks and the l4_task_map function
by Paul Boddie 01 Oct '22

01 Oct '22

Hello, I finally got round to experimenting with L4Re again, but in attempting to investigate task creation, I seem to have some difficulties understanding the mechanism by which tasks are typically created and how the l4_task_map function might be used in the process. After looking at lots of different files in the L4Re distribution, my understanding of the basic mechanism is as follows: 1. Some memory is reserved for the UTCB of a new task, perhaps using the l4re_ma_alloc_align function (or equivalent) to obtain a dataspace. 2. A task is created using l4_factory_create_task, indicating the UTCB flexpage, with this being defined as... l4_factory_create_task(l4re_env()->factory, new_task, l4_fpage(utcb_start, utcb_log2size, L4_FPAGE_RW)) 3. A thread is created using l4_factory_create_thread. l4_factory_create_thread(l4re_env()->factory, new_thread) 4. The thread attributes are set using the l4_thread_control API. 5. The l4_thread_ex_regs function is used to set the instruction pointer (program counter) and stack pointer of the thread. 6. The l4_scheduler_run_thread function is used to initiate the thread. The expectation is that the thread will immediately fault because there is no memory mapped at the instruction pointer location. However, it seems to me that it should be possible to use l4_task_map to make a memory region available within the task's address space, although I don't ever see this function used in L4Re for anything. (The C++ API makes it difficult to perform ad-hoc searches for such low-level primitives, in my view, so perhaps I am missing use of the equivalent methods.) Tentatively, I would imagine that something like this might work: l4_task_map(new_task, L4RE_THIS_TASK_CAP, l4_fpage(program_start, program_log2size, L4_FPAGE_RX), task_program_start) Here, the program payload would be loaded into the creating task at program_start, but the new task would be receiving the payload at task_program_start, with the configured instruction pointer location occurring within the receive window (after task_program_start, in other words). There are, of course, many other considerations around creating tasks, which I have noted from looking at the different packages (libloader, l4re_kernel, moe, ned), and I am aware that a few other things need to be done to start a task such as... * Defining capability selectors and mapping appropriate capabilities to the new task. * Creating a stack for the task and populating it with arguments and environment information. * Defining a suitable pager and exception handler, with this usually being provided by the l4re binary, as I understand it. Also, when actually dealing with program loading generally, I realise that the ELF binary needs to be interpreted and the appropriate regions associated with different parts of memory, this typically being handled by the region mapper/ manager in L4Re. And there is also the matter of dynamic library loading. But here, I am just attempting to establish the basic mechanism when a task starts up. Unfortunately, the only discussion I found was this (after some initial discussion about a related topic): http://os.inf.tu-dresden.de/pipermail/l4-hackers/2014/015366.html There are various examples in Subversion (maybe somewhere in the Git repositories, too) that create tasks or threads, but I don't find them particularly helpful, apparently being oriented towards very specific applications. A previous example was referenced in the above thread for the older L4Env system (or maybe an even earlier system): http://os.inf.tu-dresden.de/pipermail/l4-hackers/2000/000384.html As for why I would be wondering about such things - a question inevitably asked in the first thread referenced above - I firstly want to be able to understand the mechanism involved, but I also want to be able to integrate work I have been doing on file paging into task creation. Although I can probably do this by customising the "app model" normally used by the different loaders, it seems that I would need to construct an alternative l4re binary, which is rather cumbersome and perhaps a weakness of the abstractions that are provided, these being rather oriented towards obtaining dataspaces via the namespace API which I don't want to have to support in my filesystem. In any case, I wonder if there are any resources that describe the use of l4_task_map and the details of the program environment within tasks. Paul

4 26

Is there a benchmark for the IPC of L4Re?
by Mincheol Sung 23 Sep '22

23 Sep '22

Hi, I am trying to measure the performance of the IPC of L4Re. I am wondering whether there is a benchmark for the IPC performance. Mincheol

2 1

Build for x86_64 bare-metal machine
by Mincheol Sung 19 Sep '22

19 Sep '22

Hi guys, I am hanging out with L4, but couldn't find instructions/tutorials for building L4Re for an x86_64 bare-metal machine. Can you point me in the right direction? Thanks in advance. Mincheol

2 1