- l4-hackers - example.com Site

Issue Rebooting Guest OS in UVMM: Invalid Capability Invoke
by yy18513676366 11 Jun '25

11 Jun '25

Hello, I am currently conducting research using the L4Re system, and I am working on implementing a mechanism to reboot a Guest OS managed by UVMM. In my setup, I run two Linux instances under UVMM. My goal is to reboot one of them without affecting the other. To achieve this, I terminate the target instance by sending a signal using L4Re::Parent::signal, and then I restart it using a Ned script to launch a new instance of the same program. When restarting, I reuse the capability that was created during the first launch of the UVMM instance. However, during execution, the restarted program encounters an "invalid capability invoke" error. Upon investigation, I suspect this happens because l4_task_unmap was called during the restart process, which likely removed kernel objects associated with the original capability. As a result, the reused cap_index no longer refers to a valid object. Based on this, I would appreciate your insights on the following questions: Under what conditions are kernel objects deleted in L4Re? In this rebooting workflow, how can we ensure that capabilities remain valid or that their associated kernel objects are not prematurely unmapped or deleted? If UVMM crashes during operation, how can we design a mechanism to ensure system-wide stability and security? Thank you in advance for your valuable feedback! Best regards, stephen.yang

2 1

L4Re: MIPS syncICache seems to be broken
by Paul Boddie 09 Jun '25

09 Jun '25

Hello, I have been trying to get L4Re working on another MIPS-based SoC and found myself struggling to get the kernel to boot. Initially, I wondered about various exotic concurrency issues, particularly since the SoC has two cores (each with two threads, apparently), but I started to suspect that our old nemesis, cache management, was to blame. Anyway, to save you the long story, I had a closer look at the syncICache routine that resides in the bootstrap package/module: pkg/bootstrap/server/src/ARCH-mips/crt0.S It turns out that syncICache is ineffective due to an erroneous loop continuation test. Here's the offending code: 10: synci 0($a0) addu $a0, $a0, $v0 sltu $v1, $a0, $a1 bne $v1, $0, 10b nop Here, $a0 is the region start and $a1 is the region size, with $v0 being the cache line size. The above code is equivalent to the following: address = start; do { synci 0(address) address += linesize; } while (address < size); The address should, of course, be compared to start + size. So, cache entries may not be flushed, particularly later in regions and at higher addresses, omitting coverage even of the early kernel regions, making kernel execution very unpredictable and unreliable. Perhaps the larger caches make this fault more obvious on this particular SoC. In the startup routine in the bootstrap package/module... pkg/bootstrap/server/src/startup.cc ...there is a declaration for syncICache, along with code to flush the caches, introduced purely for MIPS. To test my suspicions, I wrote a C++ version of the routine with inline assembly language for the machine instructions, fixing the loop continuation test. This seemed to allow the kernel to boot and the system to start up as I originally expected. Would you like me to contribute this fix? I think that unless inline assembly is problematic for some toolchain choices, it might be clearer to maintain this code in C++ rather than entirely in assembly language, thus avoiding such faults in the first place. This problem may have been around since the introduction of MIPS support into L4Re, appearing first in r70 of the public Subversion repository from back in May 2016. Paul

2 2

Can't tcp into VM?
by Richard Clark 05 Jun '25

05 Jun '25

Hey Adam! I’ve gotten the lwip stack working, and two vms running, and the ramdisks expanded a little, and some test processes statically built so I can run them… and the results suggest a firewall in the way, but I don’t see a way to enable the port I want… So lwip stack native to l4re, ipaddr 192.168.1.100, Vm1 at 192.168.1.2 Vm2 at 192.168.1.3 The vms can ping eachother. The vms can ping the lwip stack. Vm1 can establish a tcp connection TO the lwip stack. (and send packets!) Lwip cannot establish a tcp connection TO vm1. I would have tweaked the firewall, but I don’t see one, or any firewall utilities, in your default ramdisks. Suggestions? How would I enable port 5000 from 192.168.1.100 (lwip) to be allowed into vm1? Worst case, I guess I could just start all the connections from the vm, but still, it would be nice to know why it isn’t being allowed. I think this is the last little piece I am missing, and then I can run demos for our customer! 😊 Thanks! Richard

2 2

Real time application
by agaku03＠gmail.com 28 May '25

28 May '25

Hello I am trying to load real time applications on the L4re hypervisor. I would like to make sure that each application has a set ram space and a specific core. I have followed some examples that are proposed but I cannot segregate the various applications correctly. Is it possible to have an example of how I have to configure or what I have to do to achieve this?

2 8

fail to build package with l4re snapshot
by Tianhao Wang 22 May '25

22 May '25

hi, I'm trying to build a new package following the instructions from the snapshot page [1]. However it fails (error message below). steps: 1. download / extract the l4re-snapshot-25.03.0 snapshot 2. make setup (for the ia32 target) && make the hello world qemu example works correctly 3. add a new package, following instructions from "Adding your own code" [1] (of course the path placeholders are modified) /tmp/myfirstpkg/Makefile ``` PKGDIR ?= . L4DIR ?= PATH/TO/SNAPSHOT/src/l4 TARGET = myfirstprogram SRC_C = main.c include $(L4DIR)/mk/prog.mk ``` /tmp/myfirstpkg/main.c ``` #include <stdio.h> int main(void) { printf("Hello!\n"); return 0; } ``` 4. and try to build it $ cd myfirstpkg $ make O=/PATH/TO/SNAPSHOT/obj/l4/x86 error output: [myfirstpkg] ... Building Dependencies path/to/src/l4/mk/binary.inc:396: *** /tmp/myfirstpkg/Makefile: 'stdlibs compiler-rt' in REQUIRES_LIBS in Makefile but not in Control file requires. Stop. make: *** [path/to/src/l4/mk/binary.inc:195: path/to/obj/l4/x86/ext-pkg/tmp/myfirstpkg/OBJ-x86_gen-std-l4f] Error 2 I attempted to add file `Control` to the package root conataining the following but it doesn't work. requires: stdlibs compiler-rt Am I doing anything wrong in adding a new package? Sorry for the newbie question, I'm learning L4RE :) cheers, wth [1] https://os.inf.tu-dresden.de/download/snapshots/ -- wth 220F 6A50 7BEF 8C33 3B4A 4404 99DE B3B4 1583 4AEF

3 8

lwip/virtio-net examples?
by Richard Clark 19 May '25

19 May '25

Hi there! I've gotten two linux vms to come up and automatically set their IPv4 address and login for me. (l4vio_net_p2p) They can ping each other just fine. Now I would like to get them to talk to my l4Re-native server. I see an lwip library, and I see that it has a virtio backend that appears to connect lwip to the virtual network. What I can't seem to find is an example that uses it? I have one vm at 192.168.1.2, and the one at 192.168.1.3. I would like to assign my lwip virtio-net interface to 192.168.1.100, and of course have them all talk TCP and UDP to each other. I can handle lwip and sockets, I just have no clue how to get it configured and initialized under l4re. Any examples and/or helpful hints? .cfg files? modules.list? Code? Github link? Thank you for your time! Richard _______________________________________________ l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de

2 2

Re: l4-hackers Digest, Vol 246, Issue 9
by Torsten Wierschin 19 May '25

19 May '25

Hi there! In my opinion, the problem discussed here can be solved quite well using yocto or buildroot or something else. If I ever find the time, I'd be happy to publish my yocto build environment for l4re. But maybe someone else will be faster? I'd like to thank you for the many very valuable tips posted here. Torsten Am Do., 15. Mai 2025 um 00:34 Uhr schrieb <l4-hackers-request(a)os.inf.tu-dresden.de>: > > Send l4-hackers mailing list submissions to > l4-hackers(a)os.inf.tu-dresden.de > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > l4-hackers-request(a)os.inf.tu-dresden.de > > You can reach the person managing the list at > l4-hackers-owner(a)os.inf.tu-dresden.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of l4-hackers digest..." > > Today's Topics: > > 1. Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > (Marcus Hähnel) > 2. Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > (Paul Boddie) > 3. RE: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > (Richard Clark) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 14 May 2025 16:52:48 +0200 > From: Marcus Hähnel <support(a)kernkonzept.com> > Subject: Re: Configuration, component and repository versioning (was > Re: Upgrade issues. VM won't start.) > To: Paul Boddie <paul(a)boddie.org.uk>, l4-hackers(a)os.inf.tu-dresden.de > Message-ID: > <c648158693b4e8f556b4d371f74e7751dce80e40.camel(a)kernkonzept.com> > Content-Type: text/plain; charset="UTF-8" > > On Mon, 2025-05-12 at 22:37 +0200, Paul Boddie wrote: > > On Monday, 12 May 2025 15:09:52 CEST Marcus Hähnel wrote: > > > > > > On Mon, 2025-05-05 at 11:25 +0000, Richard Clark wrote: > > > > > > > But that brings me to a bigger question. > > > > How do I fetch only Long-Term-Support or Fully-Tested-and-Blessed > > > > versions? Github is woefully lacking in proper version support. > > > > I can't send random untested code to my customers. > > > > > > All code we push to Github went through our internal QA process, running > > > compile checks for all our supported architectures as well as an extensive > > > test suite on different platforms and configurations. So from that point of > > > view I would say you can consider all code pushed to Github as > > > “Fully-Tested-and-Blessed”. > > > > I don't have a strong opinion about quality assurance for people wanting to > > provide solutions for paying customers, but I have personally wondered how I > > might successfully and conveniently reproduce repository configurations when > > creating new L4Re development environments. > > > > For example, if I decide to work on support for a new board, I might want to > > replicate the L4Re configuration I have been using for another board. Starting > > from scratch, it was possible to use the ham tool, but despite it apparently > > maintaining version details for the different repositories, it wasn't > > particularly clear how one might preserve or export that metadata for further > > use. > > > > I now see that there is another tool involved: > > > > https://l4re.org/getting_started/bob.html > > > > Although that doesn't seem to replace the ham tool: > > > > https://l4re.org/getting_started/make.html > > > > Naturally, one might say that this is the point at which anyone serious-enough > > about using L4Re would get in touch with Kernkonzept and start talking > > business, but such a lack of clarity tends to suggest that either there aren't > > particularly adequate solutions for such fundamental needs or that any > > adequate solutions that may exist aren't for people merely investigating or > > evaluating the technology. > > > > Again, it isn't my concern if there's a business decision involved that > > everybody feels comfortable with, and if there's a steady stream of interested > > customers that seems to justify such a decision, but I could easily see > > potential users going elsewhere if the answer to simple questions is "talk to > > us". Even in reasonably large organisations, hitting an approval barrier that > > "talk to us" or "register your interest" represents can be a strong > > disincentive, especially if other solutions exist. > > > > I accept that my opinion isn't important, however, since my own activities are > > confined to my own interests and driven by a general belief that L4Re > > represents a reasonable foundation for certain kinds of systems. That there > > isn't exactly much of a public community around L4Re could also be regarded as > > a disincentive for potential adopters, which is unfortunate. > > > > Paul > > Hi Paul, > > thank you very much for your thoughtful message — it's really appreciated. > > First of all: your opinion absolutely matters. The input from users like you, who engage deeply and share candid feedback, > helps us make L4Re better. While we are aware that L4Re is still quite niche and the community small, we want to support it > as best we can and would love to see it grow. > > I think you're raising a different, but equally important, point compared to what Richard was asking. My original response > focused on the idea of providing a fully tested release for a specific combination of software configuration and hardware, > which is understandably difficult for us to maintain as part of the open-source offering given our limited resources. > > Your concern — about being able to reproduce a known working state of your development environment — is much more > fundamental. You're right: this should be straightforward, and if it's not, then it's something we want to improve. Ease of > use and accessibility are important to us, and sometimes we’re just too close to the system to see where friction arises — > so thank you again for pointing this out. > > To clarify one key point: we don’t deliberately withhold features or usability improvements from the open-source version of > L4Re to push people into commercial contact. That’s not our business philosophy. In fact, that would go directly against > our goal of getting L4Re into more hands and making it easier to work with. > > Some of the convenience features — like release tagging — do exist in our customer repositories, but it’s more of a > workflow habit than a conscious decision to exclude them from GitHub. No one had brought up the need for that kind of > reproducibility in the open repo so far — and now that you have, let’s fix it. > > Would something like weekly tags on GitHub help you? For example, a tag like `l4re-2025-05-14` that you could use with `ham > checkout` to reproduce that specific state? > > Also, ham already supports pinned revisions in the manifest (`revision` attribute in `project` tags), so you can share a > complete and reproducible state that way as well. But I agree that this could be made more convenient. > > One possible improvement could be a `ham create-pinned-manifest` sub-command that generates such a manifest from your > current state. That’s not trivial — it would require resolving different remotes and checking that all commits are actually > reachable in one of the remotes — but it’s definitely doable. If you're interested, feel free to open a proposal or even an > issue on the ham GitHub repository — we’d love to hear your thoughts or collaborate on a solution. > > Would any of these ideas help in your workflow? Do you have something else in mind? We're always happy to improve L4Re > together with the people who use it. > > Best regards, > > - Marcus Hähnel > Principal Engineering Lead > > > -- > +++ Register now for our workshop “Get to know L4Re in 3 days” on October 28–30. Learn to design and deploy secure system > architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++ > > --- > > Kernkonzept GmbH > Sitz: Dresden > HRB 31129 > Geschäftsführer: Dr.-Ing. Michael Hohmuth > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 14 May 2025 22:01:08 +0200 > From: Paul Boddie <paul(a)boddie.org.uk> > Subject: Re: Configuration, component and repository versioning (was > Re: Upgrade issues. VM won't start.) > To: l4-hackers(a)os.inf.tu-dresden.de, Marcus Hähnel > <support(a)kernkonzept.com> > Message-ID: <2728648.BddDVKsqQX@jason> > Content-Type: text/plain; charset="UTF-8" > > On Wednesday, 14 May 2025 16:52:48 CEST Marcus Hähnel wrote: > > > > thank you very much for your thoughtful message — it's really appreciated. > > Thank you for taking the time to respond! I didn't really expect such a > comprehensive reply, so it is much appreciated. > > > First of all: your opinion absolutely matters. The input from users like > > you, who engage deeply and share candid feedback, helps us make L4Re > > better. While we are aware that L4Re is still quite niche and the community > > small, we want to support it as best we can and would love to see it grow. > > It is reassuring to hear that you take feedback into consideration, even from > those of us who are not directly contributing to your work or, indeed, your > business. > > > I think you're raising a different, but equally important, point compared to > > what Richard was asking. My original response focused on the idea of > > providing a fully tested release for a specific combination of software > > configuration and hardware, which is understandably difficult for us to > > maintain as part of the open-source offering given our limited resources. > > I completely agree that if someone is in need of something that requires an > investment of time and resources, then they should either invest their own > time and resources, which is effectively what I have done over the last few > years, or they should be prepared to compensate others for that work. Nobody > should be required to do something for someone else for nothing - there is > already too much of that happening in the open source world - not that any > such request was made, I should add. > > Productive access to specific hardware configurations has always been a > challenge for software environment developers, and the collaboration required > to deliver robust support for a given hardware platform can be difficult to > coordinate. Even with today's hardware, mostly inexpensive from a historical > perspective, there is still a substantial cost in developing the corresponding > software support. > > > Your concern — about being able to reproduce a known working state of your > > development environment — is much more fundamental. You're right: this > > should be straightforward, and if it's not, then it's something we want to > > improve. Ease of use and accessibility are important to us, and sometimes > > we’re just too close to the system to see where friction arises — so thank > > you again for pointing this out. > > > > To clarify one key point: we don’t deliberately withhold features or > > usability improvements from the open-source version of L4Re to push people > > into commercial contact. That’s not our business philosophy. In fact, that > > would go directly against our goal of getting L4Re into more hands and > > making it easier to work with. > > I think it is fine to encourage people to make contact and to discuss > opportunities, and I don't seriously believe that people are being herded in > the direction of commercial support, but any kind of obstacle or hurdle in the > independent evaluation of a technology can be dissuasive. Some evaluators are > more likely to move on and look at other things than to cultivate some kind of > dialogue. > > This doesn't only happen in a commercial context. On plenty of occasions in > academia, I saw researchers encouraging others to get in touch, in order to > work around deficiencies in the way they had communicated or published their > work. I also saw the long-term effects of this, where people could not account > for what they had published after only a few years, with this emerging when I > was actually making contact with them to try and distribute their originally > published data. > > Empowering other people as much as possible or practicable may eventually > return such favours. When I return to my own work after a substantial period > of time, it is almost as if I am just another person taking a look at it, too. > > > Some of the convenience features — like release tagging — do exist in our > > customer repositories, but it’s more of a workflow habit than a conscious > > decision to exclude them from GitHub. No one had brought up the need for > > that kind of reproducibility in the open repo so far — and now that you > > have, let’s fix it. > > I can understand that it can be easy to overlook. How many times has one seen > missing tags in public repositories because Git makes it easy to forget to > push them? I also understand that publicly tagging releases can make mistakes > difficult to rectify, but I suppose this is just another hazard of release > management, and eventually we all get used to making "patch" releases. > > > Would something like weekly tags on GitHub help you? For example, a tag like > > `l4re-2025-05-14` that you could use with `ham checkout` to reproduce that > > specific state? > > It might, but I think the challenge is then applying such tags to a large > number of repositories. Naturally, one can write scripts to synchronise all > those repositories, but isn't that what ham is supposed to achieve? > > Richard also mentioned various other packages that ham doesn't cover, and > having been working with the software for a long time now, there are still > various packages that I have needed to retrieve from the Subversion repository > for L4Re because they were never migrated to GitHub. I can understand that > those packages are no longer a focus, and I have even eliminated some of them > from my own environment, but they might still be used by the L4Re > demonstrations. > > > Also, ham already supports pinned revisions in the manifest (`revision` > > attribute in `project` tags), so you can share a complete and reproducible > > state that way as well. But I agree that this could be made more > > convenient. > > Unfortunately, I never discovered this, but I assumed that you must have a way > to capture the state of repositories in order to reproduce releases required > by customers. > > > One possible improvement could be a `ham create-pinned-manifest` sub-command > > that generates such a manifest from your current state. That’s not trivial > > — it would require resolving different remotes and checking that all > > commits are actually reachable in one of the remotes — but it’s definitely > > doable. If you're interested, feel free to open a proposal or even an issue > > on the ham GitHub repository — we’d love to hear your thoughts or > > collaborate on a solution. > > It is something I could consider working on, but it would be joining a long > list of other tasks. > > > Would any of these ideas help in your workflow? Do you have something else > > in mind? We're always happy to improve L4Re together with the people who > > use it. > > I think they would be helpful. Previously, with Subversion, one could request > a given release and get a versioned distribution of the software. The > disadvantages were the poor performance of Subversion and the awkwardness of > managing independent changes, as we all know. But that simplicity was also > very useful. > > Thanks once again for following up and giving my concerns your consideration! > > Paul > > > > ------------------------------ > > Message: 3 > Date: Wed, 14 May 2025 16:04:06 +0000 > From: Richard Clark <richard.clark(a)Coheretechnology.us> > Subject: RE: Configuration, component and repository versioning (was > Re: Upgrade issues. VM won't start.) > To: Marcus Hähnel <support(a)kernkonzept.com>, Paul Boddie > <paul(a)boddie.org.uk>, "l4-hackers(a)os.inf.tu-dresden.de" > <l4-hackers(a)os.inf.tu-dresden.de> > Message-ID: <PH1P110MB17256A3F2418A9467AC57D79FC91A(a)PH1P110MB1725.NAM > P110.PROD.OUTLOOK.COM> > Content-Type: text/plain; charset="utf-8" > > Marcus, > > I, for one, rather than having to learn yet-another-tool that doesn't quite do what I want, would rather that > you have a fully-blessed-and-tested release all rolled up in a tar (or zip) file for download. You could even have > a git repo just for the tar files. One caveat, being that it must contain ALL the repos and possible little pieces > that could possibly go with it. One thing I hate about git is sub-repos that get lost or are not pulled down and > cause severe headaches trying to match versions. Like lwip, or virtio_switch, or any of the other couple dozen > packages that don't get pulled down with the new ham build process. I'd like to be able to go to one place, > use a command I already know, and get a fully functional, fully populated, "blessed" version. You do have your > old downloads site with a tgz file, but even that doesn't contain all the packages any more. This is the frustrating part. > I need a way to get a snapshot of everything that could possibly go together in a release whether I need it or not, because > some day I will need it and then the version I need will no longer be available. So, not a "demo" or "example" > version, but a full-source-everything-including-the-kitchen-sink version. > > > Thank you for considering our opinions! > > > Richard > > > -----Original Message----- > From: Marcus Hähnel <support(a)kernkonzept.com> > Sent: Wednesday, May 14, 2025 10:53 AM > To: Paul Boddie <paul(a)boddie.org.uk>; l4-hackers(a)os.inf.tu-dresden.de > Subject: Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > > On Mon, 2025-05-12 at 22:37 +0200, Paul Boddie wrote: > > On Monday, 12 May 2025 15:09:52 CEST Marcus Hähnel wrote: > > > > > > On Mon, 2025-05-05 at 11:25 +0000, Richard Clark wrote: > > > > > > > But that brings me to a bigger question. > > > > How do I fetch only Long-Term-Support or Fully-Tested-and-Blessed > > > > versions? Github is woefully lacking in proper version support. > > > > I can't send random untested code to my customers. > > > > > > All code we push to Github went through our internal QA process, > > > running compile checks for all our supported architectures as well > > > as an extensive test suite on different platforms and > > > configurations. So from that point of view I would say you can > > > consider all code pushed to Github as “Fully-Tested-and-Blessed”. > > > > I don't have a strong opinion about quality assurance for people > > wanting to provide solutions for paying customers, but I have > > personally wondered how I might successfully and conveniently > > reproduce repository configurations when creating new L4Re development environments. > > > > For example, if I decide to work on support for a new board, I might > > want to replicate the L4Re configuration I have been using for another > > board. Starting from scratch, it was possible to use the ham tool, but > > despite it apparently maintaining version details for the different > > repositories, it wasn't particularly clear how one might preserve or > > export that metadata for further use. > > > > I now see that there is another tool involved: > > > > https://l4re.org/getting_started/bob.html > > > > Although that doesn't seem to replace the ham tool: > > > > https://l4re.org/getting_started/make.html > > > > Naturally, one might say that this is the point at which anyone > > serious-enough about using L4Re would get in touch with Kernkonzept > > and start talking business, but such a lack of clarity tends to > > suggest that either there aren't particularly adequate solutions for > > such fundamental needs or that any adequate solutions that may exist > > aren't for people merely investigating or evaluating the technology. > > > > Again, it isn't my concern if there's a business decision involved > > that everybody feels comfortable with, and if there's a steady stream > > of interested customers that seems to justify such a decision, but I > > could easily see potential users going elsewhere if the answer to > > simple questions is "talk to us". Even in reasonably large > > organisations, hitting an approval barrier that "talk to us" or > > "register your interest" represents can be a strong disincentive, especially if other solutions exist. > > > > I accept that my opinion isn't important, however, since my own > > activities are confined to my own interests and driven by a general > > belief that L4Re represents a reasonable foundation for certain kinds > > of systems. That there isn't exactly much of a public community around > > L4Re could also be regarded as a disincentive for potential adopters, which is unfortunate. > > > > Paul > > Hi Paul, > > thank you very much for your thoughtful message — it's really appreciated. > > First of all: your opinion absolutely matters. The input from users like you, who engage deeply and share candid feedback, helps us make L4Re better. While we are aware that L4Re is still quite niche and the community small, we want to support it as best we can and would love to see it grow. > > I think you're raising a different, but equally important, point compared to what Richard was asking. My original response focused on the idea of providing a fully tested release for a specific combination of software configuration and hardware, which is understandably difficult for us to maintain as part of the open-source offering given our limited resources. > > Your concern — about being able to reproduce a known working state of your development environment — is much more fundamental. You're right: this should be straightforward, and if it's not, then it's something we want to improve. Ease of use and accessibility are important to us, and sometimes we’re just too close to the system to see where friction arises — so thank you again for pointing this out. > > To clarify one key point: we don’t deliberately withhold features or usability improvements from the open-source version of L4Re to push people into commercial contact. That’s not our business philosophy. In fact, that would go directly against our goal of getting L4Re into more hands and making it easier to work with. > > Some of the convenience features — like release tagging — do exist in our customer repositories, but it’s more of a workflow habit than a conscious decision to exclude them from GitHub. No one had brought up the need for that kind of reproducibility in the open repo so far — and now that you have, let’s fix it. > > Would something like weekly tags on GitHub help you? For example, a tag like `l4re-2025-05-14` that you could use with `ham checkout` to reproduce that specific state? > > Also, ham already supports pinned revisions in the manifest (`revision` attribute in `project` tags), so you can share a complete and reproducible state that way as well. But I agree that this could be made more convenient. > > One possible improvement could be a `ham create-pinned-manifest` sub-command that generates such a manifest from your current state. That’s not trivial — it would require resolving different remotes and checking that all commits are actually reachable in one of the remotes — but it’s definitely doable. If you're interested, feel free to open a proposal or even an issue on the ham GitHub repository — we’d love to hear your thoughts or collaborate on a solution. > > Would any of these ideas help in your workflow? Do you have something else in mind? We're always happy to improve L4Re together with the people who use it. > > Best regards, > > - Marcus Hähnel > Principal Engineering Lead > > > -- > +++ Register now for our workshop “Get to know L4Re in 3 days” on > +++ October 28–30. Learn to design and deploy secure system > architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++ > > --- > > Kernkonzept GmbH > Sitz: Dresden > HRB 31129 > Geschäftsführer: Dr.-Ing. Michael Hohmuth > > > > > _______________________________________________ > l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de > To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de > > > ------------------------------ > > End of l4-hackers Digest, Vol 246, Issue 9 > ******************************************

2 3

Re: Linux console?
by Adam Lackorzynski 16 Apr '25

16 Apr '25

Hi Richard, your dts has the 'l4vmm,vcon_cap = "uart";' enabled (not commented out), thus the 8250 UART emulation in uvmm looks for a "uart" capability which is not there and thus disables the virtual UART. Removing that line or commenting it out will make this work I believe as the standard capability will be used then. Adam On Mon Apr 14, 2025 at 11:57:32 +0000, Richard Clark wrote: > Adam, > > Yes the vm-basic.cfg is where I started. > > I am attaching a tgz file with two directories showing the two different outputs that I get when > trying to run hvc0 and ttyS0. Included are the config files, the ramdisk, and the dts as well. > > > Richard > > > -----Original Message----- > From: Adam Lackorzynski <adam(a)l4re.org> > Sent: Monday, April 14, 2025 12:49 AM > To: Richard Clark <richard.clark(a)Coheretechnology.us>; l4-hackers(a)os.inf.tu-dresden.de > Cc: Bud Wykoff <bud.wykoff(a)Coheretechnology.us> > Subject: Re: Linux console? > > Hi Richard, > > On Fri Apr 11, 2025 at 15:27:18 +0000, Richard Clark wrote: > > L4Re, > > > > I’ve been working with the examples and tweaking them for AMD64 > > (QEMU), and I’ve managed to get linux up and booting, reading the > > ramdisk, and even spawning a login process which kicks off /bin/sh and > > displays a # prompt. And that’s great, but that’s all it does. I can’t > > get any input to it. That’s using the device hvc0. Of course uvmm > > complains that there is no virtual console and warns that it might not > > work, so the software is at least not surprised! 😊 But when I try to > > use the device ttyS0, linux stops printing even before the login > > process tries to run. I don’t get any errors, but also no output. And > > I can’t seem to run the IO server because then linux won’t load at all (something about out-of-memory). > > > > I’m sure I’m missing some little piece of magic somewhere, but I can’t > > find any working examples. None of them have active logins (I had to > > add my own iniittab to the ramdisk). A little help connecting the cons > > service to my linux so I can get a real bash shell? Or running IO and > > connecting through that? > > Did you try to run for example the "VM-basic" entry that is there? That is supposed to be a minimal working example. > Please also provide the output from the system you're getting, that is helping understanding what's going on. > > > Thanks, Adam _______________________________________________ l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de

2 6

L4Re running Chromium?
by Lonnie Cumberland via l4-hackers 14 Apr '25

14 Apr '25

Hi All, Hope that your day is going well. I am experimenting with ultra-lightweight object capabilities-based OS's and have only briefly in the past worked a little with L4Re as I had troubles getting it to run cleanly on my Intel NUC7 (x86_64) hardware due to some type of graphics problem. In any case, I am back to see if I can give it another go and would like to work toward building a type of ultra-lightweight Kiosk type system that might run Chromium web browser in full screen mode without any type of window manager straight from booting up. The project that I have in mind would only use and need a fullscreen web browser, and perhaps capabilities to run containers (docker or podman) perhaps so that I could run a local web server and some other things in the containers. Not sure if L4Re is able to handle all of this, but I wanted to ask, just in case. Thanks and have a great day, Lonnie _______________________________________________ l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de

3 2

Using L4 to run multiple Linux VMs
by Hübner, Andreas 14 Apr '25

14 Apr '25

Hello L4 hackers, I'm currently evaluating whether we can use Fiasco/L4Re for some of our future projects and ran into some problems/questions that you might help me out with. The general idea is to isolate multiple Linux VMs running Debian/Ubuntu (unmodified kernel) on x86/amd64 hardware with L4Re. I already did most of the tutorials on the kernkonzept/manifest github wiki. (https://github.com/kernkonzept/manifest/wiki) There were some issues with the hardware I'm using, since it maps its BIOS to an address that L4 likes to use for page tables. (at least on amd64, x86 did work out of the box) I fixed it by adjusting the base address in the linker script. (Hopefully, this should not have any bad side effects on L4.) First question: In the VM tutorials, I always see the use of kernel image + cpio ramdisk in the startup code. Is this also applicable if I want to use a full-fledged Debian/Ubuntu installation? The guest system should also be able to modify the installation. (i. e. run apt-get upgrade etc.) Second question: The general architecture for the VM scenario seems to be Fiasco/L4 -> uvmm -> Linux VMs. Is it also possible to use L4Linux as Host for the Linux VMs? My assumption would be, that it might be easier to use the Linux VMs from Linux instead of uvmm. (maybe with kvm/libvirt support?) Especially when it comes to passing the hardware to the VMs. Third question: This is a direct follow up from the last point. Passing the HW is the hard part for me. I'm not that familiar with device tree files yet and as far as I know x86/amd64 usually does not use device tree because it can auto-detect via PCI/ACPI. But it looks like uvmm/io does require device tree to pass the HW to the VMs even though L4 itself is detecting it via PCI/ACPI. Maybe I can pass the whole PCI bus, but then I would like to isolate at least some parts. For example VM 1 should only get one port of the network adapter and VM 2 should get another one. (exclusively) And while both VMs should be able to read the RTC, they should not be able to modify it. (or maybe only one of them) I know, it's not really a question, but maybe you can give me some advice on how best to approach this on x86/amd64 hardware. Fourth question: Does Fiasco/L4 support SR-IOV? I checked the code + commits and there seems to be some development in the last year, but not sure how "mature" it is. That's all for now, thanks for reading and I hope the questions are not too embarrassing/annoying. :) Best regards, Andreas Hübner Software Developer Business Fullfillment | Research & Development aconnic group OFFICE: 01157 Dresden, Am Lehmberg 54, GERMANY Phone +49 3722 7351-1010 E-Mail andreas.huebner(a)aconnic.com Web www.aconnic.com Court Munich Registration HRB 292019 Chairman of the Supervisory Board: Dr. Stefan Hagemann Executive Board: Werner Neubauer, Markus Königshofer aconnic AG (Munich), aconnic system Germany GmbH (Hartmannsdorf), aconnic service GmbH (Kornwestheim), aconnic sistemas de telecomunicaciones S.A. de C.V. (Mexico City), aconnic system Switzerland AG (Zurich), aconnic engineering AG (Zurich), aconnic carbonzero GmbH (Starnberg) are direct affiliates of the aconnic group. We refer to our data protection rules at: https://www.aconnic.com/privacy/ _______________________________________________ l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de

2 3