Devel

devel@sel4.systems

9 participants
1390 discussions

seL4 docker support for Apple Silicon
by Gerwin Klein 15 May '24

15 May '24

The seL4 development docker containers at https://github.com/seL4/seL4-CAmkES-L4v-dockerfiles now provide multi-architecture images for x86 and arm64. That means development on Apple Silicon (M1/2/3) with docker for seL4 should now work properly (including qemu) and should also be much faster than before. Intel machines should work as before. You should not need to do anything special or different to before, Docker should be pulling the correct kind of container for your architecture. This is brand new (as of today), so please check it out and report any issues you find. If you haven’t used the containers before, have a look at the README in the repository above. If you have been using them and want to make sure that the new versions are picked up: cd seL4-CAmkES-L4v-dockerfiles/ git checkout master git pull make pull_camkes_image user Enjoy! Gerwin

1 0

Re: Announcing release v0.2 of Neptune OS: a Windows NT personality for the seL4 microkernel
by Hugo V.C. 14 May '24

14 May '24

Are we talking about the same ReactOS ... ? As far I can see here: https://reactos.org/forum/ they have an active community. Try to post there. You also have this LinkedIn resource: https://www.linkedin.com/company/reactos-foundation/ Let me know if you have any problem contacting them and I'll try to help you. seL4 + ReactOS looks like a killer combination for the industry, they need to know about your work. Best, El lun, 13 may 2024 a las 15:07, Dr. Chang Liu, PhD. (<cl91tp(a)gmail.com>) escribió: > Dear Hugo, > > Thank you very much for your interest. I did try to find the ReactOS > mailing list to post this announcement in but it seems that their mailing > list has long been dead since late 2022, so I'm not sure where the main > communication channel of ReactOS development is. Perhaps you could point me > to the right place. > > Best regards, > > On Mon, May 13, 2024, 12:50 AM Hugo V.C. <skydivebcn(a)gmail.com> wrote: > >> Hats off. >> I'll test it and give my feedback. I'm very interested in your project, >> IMHO is one of the most interesting ones I have seen in years. >> >> BTW: are you in contact with ReactOS guys? Maybe would make sense to join >> efforts with them...? >> >> El dom, 12 may 2024 a las 17:40, Dr. Chang Liu, PhD. (<cl91tp(a)gmail.com>) >> escribió: >> >>> Dear seL4 community, >>> >>> I'm announcing the release of v0.2 of Neptune OS, an operating system >>> that >>> I have been developing that aims to create a Windows NT personality on >>> top >>> of the seL4 microkernel, by implementing the upper layer of the Windows >>> kernel called the NT Executive, as well as Windows kernel drivers, as >>> userspace processes under seL4. For those that remember the release of >>> v0.1 >>> two years ago and have been wondering, yes, the project is still alive. I >>> have been a bit busy with postdoc work (academia is hard!!) last year but >>> finally got a bit of free time lately to get enough work done that I >>> think >>> is interesting enough to warrant a v0.2 release. The project can be found >>> on github (https://github.com/cl91/NeptuneOS). >>> >>> The biggest feature of the v0.2 release is a (I hope) reasonably complete >>> file system stack supporting read-ahead and write-back caching, that >>> includes a FAT12/16/32 file system driver and a floppy controller driver, >>> both of which are ported over from ReactOS (but running in userspace >>> instead of kernel space). I'll explain the technical points below but you >>> can watch a short video (https://www.youtube.com/watch?v=o3FLRnkh0ic) >>> that >>> demonstrates the basic file system commands, including cd, dir, copy, >>> move, >>> del, md, and mount/umount. >>> >>> Arguably the biggest challenge for a userspace file system stack is >>> minimizing the performance penalties of the additional context switches. >>> There are radical solutions to this problem along the lines of Unikernels >>> that require linking the FS code with the applications. These solutions >>> are >>> not very practical for everyday desktop or server OSes. On traditional >>> OSes >>> there is FUSE on Linux/Unix which is often regarded as having inferior >>> performance compared to equivalent kernel-mode drivers. To some extent >>> this >>> problem is inevitable, as context switches are always more expensive than >>> function calls, no matter how much you optimize the former. However, that >>> doesn't mean we can't optimize our OS design so that the performance >>> penalties of running file systems in userspace are small enough that the >>> benefit of userspace file systems outweighs their performance cons. >>> >>> The key to this performance goal I believe is an efficient cache design. >>> Indeed, for FUSE it is possible to tune the cache parameters to >>> drastically >>> increase its performance (see [1] and the citation therein). On Neptune >>> OS >>> we cache aggressively: not only do we cache the underlying block device >>> pages, we also maintain the relationship between file regions and their >>> underlying disk regions. In other words, the primary role of the file >>> system driver is to translate an offset of a file object into an offset >>> of >>> the underlying storage device, and this relationship is cached since they >>> are not expected to change, at least for currently open files. >>> Furthermore, >>> we cache file attributes as well as the file hierarchy itself, so that >>> if a >>> process opened a file and the file system driver returned a valid handle, >>> we do not need to query the FS driver again (at least not before the >>> first >>> process closes the handle) when another process opens the same file with >>> the same attributes (because we know it exists and know about its >>> attributes). Of course, we need to be careful when things get >>> closed/deleted/moved, etc, so we need a mechanism to synchronize >>> information with the file system driver process. This is done by sending >>> messages using the seL4 IPC. >>> >>> What is amazing is the fact that despite these changes to the inner >>> workings of the NT cache manager, not to mention the fact that all >>> drivers >>> are now running in userspace, the Windows kernel driver API remains >>> largely >>> unchanged, so that it is indeed possible to port the relevant ReactOS >>> drivers to our architecture without doing too much work (I believe I >>> spent >>> three to four man-weeks worth of work porting the FAT file system >>> itself). >>> The vast majority of work is in fact removing code rather than writing >>> new >>> code, because of the simplifications of locking and other synchronization >>> issues that simply disappear when drivers run in userspace. For those who >>> are interested in knowing more about our architecture and are perhaps >>> interested in porting drivers from ReactOS, I am in the process of >>> writing >>> a book (found under the docs of the github repo) called "Neptune OS >>> Developer Guide" that explains all these things. Note this is very much a >>> work-in-progress. >>> >>> In addition to the cache manager work, in order for the file system stack >>> to function, several other system components must be implemented, most >>> notably DMA and Win32 SEH (structured exception handling). Our DMA >>> architecture supports both PCI bus mastering and the weird ISA DMA that >>> must go through the ISA DMA controller. The latter requires managing the >>> so-called "map registers" that must be shared across different ISA >>> devices. >>> Again we find that the Windows kernel API can be adapted to a seL4-based >>> userspace driver model almost straightforwardly. This is perhaps not so >>> surprising, because NT was allegedly originally designed as a microkernel >>> OS (this is inevitably an urban legend, but early NT design documents >>> refer >>> to the code beneath the NT Executive as the "microkernel", so there is >>> reason to believe). >>> >>> To summarize, what I hope is that with the design outlined above, we can >>> in >>> fact have a practical, reasonably performant userspace file system stack >>> without resorting to radical departures from traditional desktop/server >>> computing paradigms. Of course, it's ridiculous to talk about performance >>> for floppy disk controllers, so the primary goal of the next release is >>> to >>> port the ATA/AHCI hard disk drivers from ReactOS to Neptune OS, in order >>> to >>> produce a valid benchmark against equivalent kernel mode designs. Anyway, >>> if you read so far, I hope you find the work interesting (I personally >>> do!). If you have any comments, or even better if you ran the code and >>> found bugs/issues, please do open an issue in the github repo. Thank you! >>> >>> [1] >>> >>> https://medium.com/@xiaolongjiang/linux-fuse-file-system-performance-learni… >>> >>> --- >>> Dr. Chang Liu, PhD. >>> github.com/cl91/NeptuneOS >>> _______________________________________________ >>> Devel mailing list -- devel(a)sel4.systems >>> To unsubscribe send an email to devel-leave(a)sel4.systems >>> >>

1 0

seL4 developer hangout reminder
by Birgit Brecknell 13 May '24

13 May '24

Hi all A friendly reminder that the seL4 developer hangout is on again this week. Tue 14 May, 22:00 UTC. For your local date and time please see https://sel4.systems/contact/. Zoom link: https://unsw.zoom.us/j/82640784431 Birgit Brecknell seL4 Foundation Project Coordinator birgit(a)sel4.systems <mailto:birgit@sel4.systems> bbrcknl(a)gmail.com <mailto:bbrcknl@gmail.com>

1 0

Announcing release v0.2 of Neptune OS: a Windows NT personality for the seL4 microkernel
by Dr. Chang Liu, PhD. 13 May '24

13 May '24

Dear seL4 community, I'm announcing the release of v0.2 of Neptune OS, an operating system that I have been developing that aims to create a Windows NT personality on top of the seL4 microkernel, by implementing the upper layer of the Windows kernel called the NT Executive, as well as Windows kernel drivers, as userspace processes under seL4. For those that remember the release of v0.1 two years ago and have been wondering, yes, the project is still alive. I have been a bit busy with postdoc work (academia is hard!!) last year but finally got a bit of free time lately to get enough work done that I think is interesting enough to warrant a v0.2 release. The project can be found on github (https://github.com/cl91/NeptuneOS). The biggest feature of the v0.2 release is a (I hope) reasonably complete file system stack supporting read-ahead and write-back caching, that includes a FAT12/16/32 file system driver and a floppy controller driver, both of which are ported over from ReactOS (but running in userspace instead of kernel space). I'll explain the technical points below but you can watch a short video (https://www.youtube.com/watch?v=o3FLRnkh0ic) that demonstrates the basic file system commands, including cd, dir, copy, move, del, md, and mount/umount. Arguably the biggest challenge for a userspace file system stack is minimizing the performance penalties of the additional context switches. There are radical solutions to this problem along the lines of Unikernels that require linking the FS code with the applications. These solutions are not very practical for everyday desktop or server OSes. On traditional OSes there is FUSE on Linux/Unix which is often regarded as having inferior performance compared to equivalent kernel-mode drivers. To some extent this problem is inevitable, as context switches are always more expensive than function calls, no matter how much you optimize the former. However, that doesn't mean we can't optimize our OS design so that the performance penalties of running file systems in userspace are small enough that the benefit of userspace file systems outweighs their performance cons. The key to this performance goal I believe is an efficient cache design. Indeed, for FUSE it is possible to tune the cache parameters to drastically increase its performance (see [1] and the citation therein). On Neptune OS we cache aggressively: not only do we cache the underlying block device pages, we also maintain the relationship between file regions and their underlying disk regions. In other words, the primary role of the file system driver is to translate an offset of a file object into an offset of the underlying storage device, and this relationship is cached since they are not expected to change, at least for currently open files. Furthermore, we cache file attributes as well as the file hierarchy itself, so that if a process opened a file and the file system driver returned a valid handle, we do not need to query the FS driver again (at least not before the first process closes the handle) when another process opens the same file with the same attributes (because we know it exists and know about its attributes). Of course, we need to be careful when things get closed/deleted/moved, etc, so we need a mechanism to synchronize information with the file system driver process. This is done by sending messages using the seL4 IPC. What is amazing is the fact that despite these changes to the inner workings of the NT cache manager, not to mention the fact that all drivers are now running in userspace, the Windows kernel driver API remains largely unchanged, so that it is indeed possible to port the relevant ReactOS drivers to our architecture without doing too much work (I believe I spent three to four man-weeks worth of work porting the FAT file system itself). The vast majority of work is in fact removing code rather than writing new code, because of the simplifications of locking and other synchronization issues that simply disappear when drivers run in userspace. For those who are interested in knowing more about our architecture and are perhaps interested in porting drivers from ReactOS, I am in the process of writing a book (found under the docs of the github repo) called "Neptune OS Developer Guide" that explains all these things. Note this is very much a work-in-progress. In addition to the cache manager work, in order for the file system stack to function, several other system components must be implemented, most notably DMA and Win32 SEH (structured exception handling). Our DMA architecture supports both PCI bus mastering and the weird ISA DMA that must go through the ISA DMA controller. The latter requires managing the so-called "map registers" that must be shared across different ISA devices. Again we find that the Windows kernel API can be adapted to a seL4-based userspace driver model almost straightforwardly. This is perhaps not so surprising, because NT was allegedly originally designed as a microkernel OS (this is inevitably an urban legend, but early NT design documents refer to the code beneath the NT Executive as the "microkernel", so there is reason to believe). To summarize, what I hope is that with the design outlined above, we can in fact have a practical, reasonably performant userspace file system stack without resorting to radical departures from traditional desktop/server computing paradigms. Of course, it's ridiculous to talk about performance for floppy disk controllers, so the primary goal of the next release is to port the ATA/AHCI hard disk drivers from ReactOS to Neptune OS, in order to produce a valid benchmark against equivalent kernel mode designs. Anyway, if you read so far, I hope you find the work interesting (I personally do!). If you have any comments, or even better if you ran the code and found bugs/issues, please do open an issue in the github repo. Thank you! [1] https://medium.com/@xiaolongjiang/linux-fuse-file-system-performance-learni… --- Dr. Chang Liu, PhD. github.com/cl91/NeptuneOS

2 1

Loading a large sel4test image on Odroid-C4 Fails
by Linh Pham 11 May '24

11 May '24

Hello, I am running into an issue with booting up an sel4test image on the Odroid-C4. When the calculated memory bound for the sel4test-driver's ELF is around 100MB or larger, I get an asychronous data abort like so: ELF-loader started on CPU: ARM Ltd. Cortex-A55 r1p0 paddr=[c3d2000..e068117] No DTB passed in from boot loader. Looking for DTB in CPIO archive...found at c502760. Loaded DTB from c502760. paddr=[256000..261fff] ELF-loading image 'kernel' to 0 paddr=[0..255fff] vaddr=[8000000000..8000255fff] virt_entry=8000000000 ELF-loading image 'sel4test-driver' to 262000 paddr=[262000..6cd7fff] vaddr=[400000..6e75fff] virt_entry=443090 "Error" handler, esr 0xbe000011 elr: ffffffff1a4996e4 lr : ffffffff1a497654 (reloc) elr: 000000000c3d96e4 lr : 000000000c3d7654 x0 : 0000000001ad7340 x1 : 0000000000000000 x2 : 0000000006a75348 x3 : 000000000c3dfdc0 x4 : 0000000001b494c8 x5 : 000000000c3dca50 x6 : 0000000000262000 x7 : 0000000000000001 x8 : 0000000000000008 x9 : ffffffffffffffff x10: 0000000000000000 x11: 0000000000000002 x12: 00000000f4fef9e0 x13: 0000000000000001 x14: 00000000f4fef9e0 x15: 0000000000000000 x16: 0000000020000000 x17: 0000000000c0c0c0 x18: 00000000f0f3dda0 x19: 000000000c3dfff0 x20: 0000000020000000 x21: 0000000000000002 x22: 00000000f0f769c0 x23: 0000000000000002 x24: 00000000f2ff556c x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 00000000f0f6d380 x29: 000000000c3dfda0 Code: f94017e0 91002000 f90017e0 f94007e0 (f1001c1f) Resetting CPU ... Our sel4test image is large because we're using a static heap. Note that the relevant region from the log output is [262000..6cd7fff], the exception occurs when trying to write into memory in this range. After some investigation, writing to physical address 0x5100000 is what causes the problem. I haven't been able to find any documentation on why this physical address range can't be written to. Is this some sort of device memory region? I was able to eventually boot by changing the ELF loader to load into a much higher memory address (e.g. somewhere around 0x80000000), but I would like to have a clearer idea of the Odroid's memory layout so that I could choose an address range that is definitely safe to load the image into. Thank you, Linh

2 1

seL4 multicore boot failed on arm64
by Leonid Meyerovich 10 May '24

10 May '24

Hello, I run my seL4 application on 4 core ARMv8. Recently I have developed some more application code (I mention it because file system size is increased an I believe it may change boot time) and from time to time I observed that boot process failed (stuck after the following print) calling schedule calling activate thread kernel boot done.. CPU=1 calling schedule calling activate thread kernel boot done.. CPU=2 calling schedule calling activate thread kernel boot done.. CPU=3 Booting all finished, dropped to user space calling schedule calling activate thread kernel boot done.. CPU=0 Some time I see that only 2 CPU have been booted (like CPU1 and CPU3, or CPU2 and CPU3) Last print is the last one in init_kernel() function Thanks you, Leonid

2 3

Building seL4test 12.1.0 fails on Ubuntu 22.04 (WSL2)
by Ben McCart 09 May '24

09 May '24

I have run into the following build error when running ninja to build seL4test (following instructions at: https://docs.sel4.systems/GettingStarted#setting-up-your-machine) Here is what I get for output. Any suggestions on a work-around? (Do I have the wrong version of a python tool or library?) -- [65/263] Generating circular_includes_valid FAILED: kernel/circular_includes_valid /home/dev/seL4test/build-x86/kernel/circular_includes_valid cd /home/dev/seL4test/build-x86/kernel && /home/dev/seL4test/kernel/tools/circular_includes.py --ignore kernel_all_copy.c < kernel_all.i && touch circular_includes_valid Traceback (most recent call last): File "/home/dev/seL4test/kernel/tools/circular_includes.py", line 74, in <module> sys.exit(main(args)) File "/home/dev/seL4test/kernel/tools/circular_includes.py", line 61, in main while file_stack[-1] != header: IndexError: list index out of range [66/263] Invoking muslc build system /home/dev/seL4test/projects/musllibc/src/prng/seed48.c:6:40: warning: argument 1 of type ‘short unsigned int *’ declared as a pointer [-Warray-parameter=] 6 | unsigned short *seed48(unsigned short *s) | ~~~~~~~~~~~~~~~~^ In file included from /home/dev/seL4test/projects/musllibc/src/prng/seed48.c:1: /home/dev/seL4test/projects/musllibc/include/stdlib.h:133:25: note: previously declared as an array ‘short unsigned int[3]’ 133 | unsigned short *seed48 (unsigned short [3]); | ^~~~~~~~~~~~~~~~~~ /home/dev/seL4test/projects/musllibc/src/unistd/getcwd.c: In function ‘getcwd’: cc1: warning: function may return address of local variable [-Wreturn-local-addr] /home/dev/seL4test/projects/musllibc/src/unistd/getcwd.c:9:14: note: declared here 9 | char tmp[PATH_MAX]; | ^~~ ninja: build stopped: subcommand failed.

2 2

seL4 developer hangout reminder
by Birgit Brecknell 29 Apr '24

29 Apr '24

Hi all A friendly reminder that the seL4 developer hangout is on again this week. Wed 1 May, 8:00 UTC. For your local date and time please see https://sel4.systems/contact/. Zoom link: https://unsw.zoom.us/j/82640784431 Birgit Brecknell seL4 Foundation Project Coordinator birgit(a)sel4.systems <mailto:birgit@sel4.systems> bbrcknl(a)gmail.com <mailto:bbrcknl@gmail.com>

1 0

seL4 summit: deadline extension to 29 April 2024
by Birgit Brecknell 22 Apr '24

22 Apr '24

The deadline to submit a presentation to the seL4 summit 2024 [0] has been extended by 1 week. You now have until 29 April 2024 to propose a talk [1], by uploading an abstract of one page or less to the submission portal [2]. Looking forward to receiving your proposals. We want to hear about your cool seL4 work! And spread the word! If you want to hear about specific seL4 work, ping people around you or let us know at summit(a)sel4.systems. [0] https://sel4.systems/Foundation/Summit/2024/ [1] https://sel4.systems/Foundation/Summit/2024/cfp [2] https://sel4.systems/Foundation/Summit/2024/submit Birgit Brecknell seL4 Foundation Project Coordinator birgit(a)sel4.systems <mailto:birgit@sel4.systems> bbrcknl(a)gmail.com <mailto:bbrcknl@gmail.com>

1 0

Question about LionsOS
by Isaac Beckett 20 Apr '24

20 Apr '24

Hello! Looking at the LionsOS website and documentation you posted, it seems like Lions is an operating system built using Microkit out of components/drivers that use the sDDF? Do I have the right shape of things in my head? Also, would sDDF drivers for a static OS like Lions (or other OS built in Microkit, since that’s what’s it’s built for) be potentially portable to other operating systems using the seL4 kernel and sDDF? Like, if I design a non-static operating system that uses sDDF drivers, could I use existing code from Lions or would I face issues with code assuming that the system’s components can’t change at runtime? Thanks, Isaac

11 26

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Devel