November 2023 - Devel - lists.sel4.systems

seL4 summit 2024: survey about location
by Birgit Brecknell 29 Nov '23

29 Nov '23

Dear seL4 friends, With the great success of the seL4 summit 2023 behind us, we are now looking at the seL4 summit 2024! This should happen around Sep/Oct 2024. We have started investigating options for the location, and we would like your feedback. We would greatly appreciate it if you could fill in this very short survey to tell us your opinion between Abu Dhabi and Sydney: https://forms.gle/LQKSHVrqLGNqV2Ld8 Please do so by Nov 22nd 2023. Feel free to forward to anyone you believe may want to attend the summit next year. Many thanks! June & Birg --- Birgit Brecknell Project Coordinator, seL4 Foundation birgit(a)sel4.systems<mailto:birgit@sel4.systems> birgit.brecknell(a)unsw.edu.au<mailto:birgit.brecknell@unsw.edu.au> Mon 9am-5pm Wed 2pm-5pm Fri 9am-5pm

2 3

How to avoid priority inversion in seL4
by chenpingyuan＠xiaomi.com 29 Nov '23

29 Nov '23

Hello experts, I'm reading the code of seL4 kernel, but I got confused how seL4 could help to avoid priority inversion. seL4 itself doesn't change the priority of TCB at the kernel level, does it mean that seL4 leaves the user level to handle priority inversion? Regards Neil.

2 2

A few questions regarding seL4
by Benjamin J. Kelly 29 Nov '23

29 Nov '23

To Whom It May Concern, My name is Ben Kelly. Myself and my partner James Briscoe - CC'd on this email - are in the beginning stages of starting a company that will host websites and web services for clients requiring high security on hardware that we control from the firmware up. We haven't decided which OS we want to use yet. Our initial goal is a customizable OS that contains only the minimum services to host a web server and nothing else. We will be evaluating the seL4 Microkernel. We're also intrigued by the possibilities of enhanced application performance and security that can be had from a unikernel approach. Is there anything that would forbid using the seL4 MicroKernel acting as a 'hypervisor/scheduler' for highly isolated and performant unikernel applications? If not, seL4 and Unikernel technology could potentially deliver the maximum amount of performance and security possible for hardware running seL4-compatible CPUs. In the following video Boyd Multerer, https://youtu.be/YG5BaoB24eA?si=TcxHq51Q5HLC0m1_ was asked the question if seL4 would "make sense on servers." Boyd replied that "I think it would but it's not something that we are targeting ... yet." He also said that "Yeah, I do think seL4 would be perfect at the bottom of the server once the multi-core thing gets figured out. But we don't need to solve that right away." Do you think seL4 is mature enough for our purpose? If we were to invest our time doing a deep dive into understanding seL4 do you know of any companies that are willing to pay for our acquired knowledge? Very Respectfully, Benjamin J. Kelly President Windsor Lake Computing LLC http://windsorlake.llc/ Sent with [Proton Mail](https://proton.me/) secure email.

3 5

Reminder seL4 developer hangout
by Birgit Brecknell 26 Nov '23

26 Nov '23

Hi all A friendly reminder that the seL4 developer hangout is on again this week: * Sydney: Wed, Nov 29, 8am For your time zone, please see the calendar: https://sel4.systems/contact/ Zoom link: https://unsw.zoom.us/j/82640784431 cheers Birg --- Birgit Brecknell Project Coordinator, seL4 Foundation birgit(a)sel4.systems<mailto:birgit@sel4.systems> birgit.brecknell(a)unsw.edu.au<mailto:birgit.brecknell@unsw.edu.au> Mon 9am-5pm Wed 2pm-5pm Fri 9am-5pm

1 0

How to run seL4 on FVP?
by Hesham Almatary 22 Nov '23

22 Nov '23

Hello, I can build sel4test for FVP, how do I run it there? I couldn't find any documentation on that, would be great if someone could drop a command line and any required dependencies. Regards, Hesham

3 4

Use C-parser on seL4 based application
by r2ji＠uwaterloo.ca 20 Nov '23

20 Nov '23

Hi, I have been trying to reuse the seL4 verification framework to verify a toy example I built on seL4, and I am currently stuck on the c-parser step. I am trying to use c-parser to parse the example I built, then conduct refinement verification. The toy example is a normal c project, which includes `sel4.h`. From this thread: https://lists.sel4.systems/hyperkitty/list/devel@sel4.systems/thread/3QYNFY… I learned that I am supposed to do $ ./isabelle/bin/isabelle jedit -d . -l CParser toy.thy And the toy.thy file is supposed to begin with `install_C_file("toy.c")`. However, since toy.c includes sel4.h, I am not sure how to preprocess it before I put it into toy.thy. I know the standalone c-parser can have a -I flag to include in all the dependency directories, but it cannot open an interactive window. (From my understanding, the standalone c-parser seems to be only a checking tool) I also know that when sel4 is parsed into HOL, it is preprocessed into a single c file `kernel_all.c_pp`, which is later parsed. I am not sure if the preprocessor tool can be reused for other applications as well. My question is summarized as: 1. Is there a way to add an include directory in interactive CParser? 2. If not, can I reuse the preprocessing approach for sel4 to preprocess my application to a singleton file that can be parsed by c-parser? Any help will be appreciated! Thanks, Ru

2 2

Conclusions regarding speculation
by Demi Marie Obenour 18 Nov '23

18 Nov '23

I talked with a Xen developer and came to these conclusions: - Speculative taint tracking provides complete protection against speculative attacks. This is sufficient to prevent leakage of cryptographic key material, even in fully dynamic systems. Furthermore, it is compatible with fast context switches between protection domains. - Full time partitioning eliminates all timing channels, but it is possible only in fully static systems, which severely limits its applicability. - Time protection without time partitioning does _not_ fully prevent Spectre v1 attacks, and still imposes a large penalty on protection domain switches. Additionally, I am almost certain that: - On properly designed hardware, both time protection and speculative taint tracking can be enabled and disabled by systems software. - Time protection and speculative taint tracking are not mutually exclusive. A cloud provider might use time partitioning to partition different customers from each other, while guest OSs use speculative taint tracking to protect different processes from each other. In short, time protection is excellent, but it is not a sufficient mechanism for general-purpose computing. Speculative taint tracking is a different mechanism that is applicable to many more workloads, and which provides complete protection against speculative attacks. Both mechanisms can be used together depending on system security policy. -- Sincerely, Demi Marie Obenour (she/her/hers)

6 18

CfP: Microkernel and Component-based OS Devroom at FOSDEM 2024
by Martin Decky 15 Nov '23

15 Nov '23

Microkernel and Component-based OS Devroom at FOSDEM 2024 CALL FOR PARTICIPATION On-line version of this CfP: http://fosdem.microkernel.info/ The developers and users of several free and open source microkernel-based, unikernel-based and component-based operating systems will meet as part of FOSDEM 2024 [1] and will share a developer room. The devroom is currently looking for content in the form of talks and other activities related to microkernel-based, unikernel-based, component-based operating systems and similar areas. Possible topics of the devroom include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * languages, tools and toolchains used * enabling support for hardware (architectures, device drivers) and programming languages * development processes, debugging * maintenance, testing and release engineering * safety, security and robustness * trends and challenges * research and open questions * community and governance * use cases, experiences and status updates * best practices and lessons learned * demos The devroom has been scheduled to Saturday February 3rd 2024 in the afternoon (Central European Time). This is a call for your participation. We kindly ask you to submit your proposals no later than on December 10th 2023 (End of Day, Anywhere on Earth). Please use the pretalx [2] web site to submit your proposals. Note that this is a new submission system and the user accounts from the previous submission system (pentabarf) have not been transferred. Make sure to select the Microkernel and Component-based OS as the track when submitting your proposal and include at least the following information: * title of your proposal * short abstract (one or two paragraphs) * duration (at least 15 minutes and no longer than 40 minutes) * your full name * your short bio You can specify your preferred time slot of your proposal and any other relevant information. The communication language of the devroom is English. Please note that the devroom has been allocated only a half of a day this year. Therefore the final decision on the duration of the talks will be made by the devroom organizers based on the number of accepted proposals. The official devroom schedule (along with the accepted talks) will be announced on December 15th 2023 on the devroom's mailing list [3] and the speakers will be notified via e-mail. The schedule will be published on the FOSDEM web site, too. About the Devroom Since the first Microkernel OS Devroom at FOSDEM 2012 [4], this devroom has been a part of each following FOSDEM (with slight variations of the name). The focus gradually widened to include component-based, unikernel-based and other operating systems. By now, it has become a somewhat institutionalized tradition for the open source operating systems community, a kind of "extended family meeting" and it is one of the places where microkernel and unikernel enthusiasts meet regularly. To this date, over two dozen projects have participated in one way or another. Many 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. As every previous year, the devroom will offer the "stage" both to established community members and to newcomers. We like to select the talks in an inclusive manner, while staying true to the main technical topics (system-level software, broadly speaking) and creating a balanced and unbiased schedule. We would like to keep the quality bar of the devroom same as in the previous years. Presenting at FOSDEM implies that the recordings of the talks will be published under Creative Commons license by FOSDEM. By submitting a proposal, the speaker agrees to have the talk made available publicly indefinitely. For organizational purposes, we also need contact information of the speakers of accepted talks. Microkernel Dinner It has also become a habit that the devroom participants dine together somewhere in Brussels. The year 2024 will not be any different, so there is going to be a dinner on Saturday night. We will inform you about the exact arrangements later. About FOSDEM FOSDEM [5] is a two-day conference organized by volunteers to promote the widespread use of free and open source software. FOSDEM is widely recognized as one of the largest and best such events worldwide. FOSDEM covers a wide spectrum of free and open source software and hardware projects and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) 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 proposals. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. In recent years, FOSDEM has been hosting more than 8000 developers annually at the ULB Solbosch Campus in Brussels, Belgium. The participation in FOSDEM is totally free, although the organizers gratefully accept donations and sponsorship. No registration is necessary. Attendees are expected to follow the [6]FOSDEM's code of conduct. Important Dates Recap * 2023-12-10: Deadline for proposal submission * 2023-12-15: Schedule published and speakers notified of acceptance * 2024-02-03: Devroom taking place Contact For any comments, questions and suggestions, please do not hesitate to use the devroom's mailing list [3] to contact the devroom organizers. The primary organizers of the devroom in 2024 are: * Martin Decky * Razvan Deaconescu References [1] https://fosdem.org/2024/ [2] https://pretalx.fosdem.org/fosdem-2024/cfp [3] https://lists.fosdem.org/listinfo/microkernel-devroom [4] https://archive.fosdem.org/2012/schedule/track/microkernel_os_devroom.html [5] https://fosdem.org/ [6] https://fosdem.org/2024/practical/conduct/

1 0

Re: Conclusions regarding speculation
by G. Branden Robinson 14 Nov '23

14 Nov '23

[re-send 2/2] ----- Forwarded message from "G. Branden Robinson" <g.branden.robinson(a)gmail.com> ----- Date: Mon, 13 Nov 2023 04:03:16 -0600 From: "G. Branden Robinson" <g.branden.robinson(a)gmail.com> To: devel(a)sel4.systems Subject: Re: [seL4] Re: Conclusions regarding speculation Hi Demi, At 2023-11-13T03:39:00-0500, Demi Marie Obenour wrote: > > The difference is QubesOS do not rely on a verified hypervisor while > > the hypothetical system I'm talking about it will have seL4 booting, > > which is a verified piece of code. > > I would love that, but seL4 currently is missing at least five > critical security features on x86: > > 1. Interrupt remapping in the IOMMU. This is the sort of thing that gets solved by putting together a small team of engineers, some very thick manuals from the manufacturer, a contact inside the vendor to address points "accidentally" omitted or erroneously documented, and a not insignificant amount of money. A Simple Matter of Programming, in other words. > 2. Protection against speculative execution attacks the moment the > embargo breaks. > 3. The ability to either choose the appropriate mitigations itself, > or to let userspace choose them. > 4. Properly implemented speculative execution mitigations. These 3 seem to be what you and Gernot are arguing about and I feel unqualified to get into the middle of that. > 5. Microcode update support. This is like (1) except it will never happen with verifiability and reliability because that would either expose, or enable the replacement of, the "secret sauce", by which the profit margin on the chip is protected. And that is why we need fully open cores subject to third-party correctness verification. I've never even seen an argument that you can combine these properties with binary blobs or trade secrets. And as long as that is true we're sure to keep getting trashed by spec ex attacks or the next great innovation in system compromise. > Without all five of these, seL4 is _less_ secure than Xen, which > defeats the entire purpose of using it. As per the discussion in > https://github.com/seL4/seL4/issues/1108 this will not be fixed any > time soon. I may not be completely understanding your argument, but it sounds like you're saying that with Xen/QubesOS you essentially achieve compartmentalization by partitioning one process (in the Unix sense) per processor (in the cores plus shared caches sense). Once you do this, doesn't it start to look a lot like OpenVMS? This would initially be a good way to drive the KVM-switch-in-a-laptop into the market but I think it would run into scaling problems pretty quickly. > That’s why I asked about desktop-class hardware I can actually buy: > the only non-x86 desktop-class hardware I know of are Macs with Apple > silicon and POWER9 machines from Raptor, ...insanely expensive (5 figures USD) last I looked... And Apple won't give up secret sauce of any kind before the extinction of our species. They still curse John Sculley's name. > and seL4 supports neither. > Apple silicon has lots of nonstandard IOMMUs that seL4 would need to > support, and POWER is not supported at all. For the time being, we are simply screwed. We are the cows from which economic rents are milked; this pleases the Street. The only rescue from our plight is Joseph Schumpeter's "creative destruction", opinions of which seem to vary in a consistent way depending on one's temporal distance from an IPO. > (Fun fact: you probably have some formally verified cryptographic code > installed on your system _right now_, since NSS uses fiat-crypto for > some of its cryptographic primitives last I checked.) ! Share a link next time. :) > To be clear: I don’t fault seL4 for focusing on embedded right now. > The reward/effort ratio is vastly more favorable there. That, and I think the larger players in the industry perceive potential risks to the status quo. The promise of lower expenses down the road due to fewer security incidents is a really hard thing to quantify, and much decision making is tied to what can be said in the next quarterly 10-C filing with the SEC. Yes, Heartbleed can give you heartburn big time. But sufficiently large and reliable income streams salve any scald. Quality of implementation is simply not the sort of thing anybody on the financial side of any firm cares about unless it's as dramatic as an airplane falling out of the sky. (I would have said "or life support equipment not being fit for purpose", but that appears not to be the case.[1][2]) > Servers are significantly harder and I suspect desktops and laptops > are the worst-case scenario, because _everything_ is dynamic and > subject to the whim of a human who can and will break any simplifying > assumptions one has made. And this is even before one starts talking > about GPUs and other accelerators, which are a huge attack surface and > yet can be the difference between a system being usable and unusable > for the tasks people expect of it. There is a reason Qubes OS is > going to be supporting GPU acceleration at some point. > > That’s why I am so pessimistic about time protection on desktop: all > of the stuff I have read about it assumes at least some static > partitioning, and in the desktop world, static _anything_ simply > doesn’t exist. I think it's bad, but maybe not quite as bad as you do. I'm going to risk coming off as naïve for a moment. Or saying a bunch of stuff you (or everyone on this list) already knows. Getting back to CS 101 fundamentals, what does a computing system do? A. It computes things (runs instructions). B. It remembers things (has storage). C. It communicates with the world (performs I/O operations). Time division multiplexing is our solution to (A) and (C) when we have more things we want to compute and communicate than we have machine resources for. This is well-studied and reasonably well controlled. We tried cooperative multitasking; it didn't work out because we couldn't solve the halting problem (but mainly because programmers are not infallible). Fine. Limited bandwidth and measurable latencies are so pervasive that we _assume_ unreliability of all I/O (but largely hide it inside network stacks or bus protocols). That leaves (B). So the dynamic system problem boils down to the multiplexing of memory. And I venture that is mainly a problem because when DEC added virtual memory to the PDP-11 and the Berkeley CSRG rewrote the Unix kernel to use it (thus "vmunix"), we all fell into a trap. That trap has a name. Memory overcommit. Your userland application can't overcommit CPU cycles. You'll get preëmpted. You can't overcommit I/O, either; something will throttle you. So we've spent a few decades being fantastically reckless with memory, especially in C and C++. (And, worst of all, JavaScript, according to my htop(1).) Running out of memory was never supposed to be problem in real life; rare enough that, if you were a slouch, you used the return value of malloc/calloc/realloc without thinking, and if you weren't, you just fatal-errored out, proclaiming defeat. I expect that the next generation will start breaking the wretched habit of assuming unbounded memory availability. Here's why. We (desktop users) drastically under-use all these parallel cores in our systems. If we were to partition memory consumption at the application level for large problems, we could more easily apply divide-and-conquer strategies to them. This is not a new insight. "MapReduce" was a buzzword 20+ years ago. As often happens, stuff that got figured out at the "enterprise" level last generation trickles down to the desktop for this one. This time maybe we can do better than J2EE. So, as I see it, the solution to the "insanely dynamic system" problem is to stop being insane. Accept a bound on memory consumption. Stop overcommitting memory, which already causes frustrating problems.[3] Use something like Massif[4] to profile your heap usage. Ask for as much as you will need at process launch, or refactor your memory-hog functions to work within one or more smaller arenas. See what happens. Yes, some stuff that never used to crash will start crashing because its authors didn't bother writing with highly parallel systems in mind, or assumed that memory was infinite. We also used to watch things crash because people treated pointers and ints as equivalent. I'm old enough to remember the DEC Alpha teaching a lot of hard lessons in this area (and also with respect to unaligned memory accesses). We learned. Now, we will slowly learn to stop asking for more than we need, and how to carve up the memory arenas we use. We also may continue our slow migration away from worse-is-better behemoths like C/C++ and Unix kernels. Am I wrong? Could be. Point me to reading material. I try not to talk too much on this list. Tonight I reckon I blew through my quota for the year, and I still had something I wanted to post from the summit... :-| Regards, Branden [1] https://www.fiercebiotech.com/medtech/getinge-life-support-systems-temporar… [2] Take note of the dates mentioned in article [1] and compare it with the five-year share price history of the manufacturer. https://www.google.com/search?q=getinge+share+price If you'd bought in when the first recall started in "late 2020" and held ever since, you would not have lost money. And in fact you could have cashed out with 100+% profit in the second half of 2021. [3] https://lwn.net/Articles/668126/ [4] https://valgrind.org/docs/manual/ms-manual.html ----- End forwarded message -----

1 0

Re: Conclusions regarding speculation
by G. Branden Robinson 14 Nov '23

14 Nov '23

[sending a revised verison of this and one other message; Peter was able to confirm that the earlier ones got lost somewhere between exim and mailman--maybe my GPG signature attachment caused problems, so leaving that off] ----- Forwarded message from "G. Branden Robinson" <g.branden.robinson(a)gmail.com> ----- Date: Mon, 13 Nov 2023 02:51:36 -0600 From: "G. Branden Robinson" <g.branden.robinson(a)gmail.com> To: devel(a)sel4.systems Subject: Re: [seL4] Re: Conclusions regarding speculation At 2023-11-13T08:55:47+0100, Hugo V.C. wrote: > > One might as well just buy multiple laptops and be able to use them > > at the same time. > > *** You can not easily travel with multiple laptops and it is not a > comfortable solution, nor you can sell this idea to anyone. > Instead you can travel with a single laptop with 3 different computing > platforms inside, basically, the user will never know, it will be > transparent. When I was at TS we had a demo system that manifested this sort of partitioning, but I think it furthermore used a windowing system. The project was no longer under development while I was working there--probably it wasn't being actively funded--but the proof of concept seems to have been delivered. It may have had only two tiers, "red" and "black", with the former a data sink only (apart from what your eyeballs could see) and the latter a source and sink. Pretty sure someone else on the list can correct me and say more. (I want to say it was called MDDC? "Multi-Domain Display Controller"?] My other thought is that we're basically talking about putting a KVM ("keyboard/video/mouse", not "kernel virtual machine" :) ) switch inside a chassis with cores, storage, and peripheral ports. That doesn't seem like it should be too hard.[0] The physical dimensions of KVMs seem to be dominated by the sizes of the connectors attached to them. Not an issue inside a chassis. Economically there is a reason to expect this to come to pass as well; with the death of Moore's Law, I submit that we buy multicore CPU packages not because we use them efficiently--I don't, except when running "make -j", and that's a tiny fraction of my interaction time--it is because CPU vendors desire to keep the price point of the minimum configured processor model for consumer machines around USD 100. I guess some kind of commodity market dynamics are thought to set in somewhere below that point, and such dynamics are threatening to the U.S. consumer-facing semiconductor duopoly. (Vertical integration is a classic defense against having to participate in this sort of competition, and is consistent with Apple's in-housing of CPU design and manufacture.) As innovations go, this could be a benign one, and a real improvement if we seize the opportunity on the OS side. (We still need a capability-based OS and, as Hugo points out, a formally verified network stack.) Here's an amusing proof of concept with a mightily retro hardware/software stack. But if a hobbyist can do this in his garage... "Meet the ZedRipper – a 16-core, 83 MHz Z80 powerhouse as portable as it is impractical." http://www.chrisfenton.com/the-zedripper-part-1/ Aside: Just over the past couple of weeks, glibc and other libc implementers have held an open conversation with the Linux man-pages maintainer such that they're seriously trying to get the best available information to C programmers about how to perform the seemingly simple operation of copying strings, and why the silver bullets that have been touted to date, aren't.[1] For decades our industry has labored under the harmful myth that the standard C library, even as it existed in ANSI C89, was perfectly good enough for this, and if you screwed up it was because you're a bad programmer, not because C's infamously weak type system and silly selection of return values in its library[2] laid down a minefield for you to traverse. Rust has caught fire despite all the money Google has thrown at Go,[3] and a few people (not just me, I promise) even remember and point out how Ada got a lot of stuff right 40 years ago that the "close-to-the-metal"/portable-assembly school of hacking keeps getting pwn3d by.[4] gnulib is adding CHERI support as we speak.[5] I don't personally prefer CHERI to using a better language than C/C++ (and ISA than x86) from the ground up, but it is a serious and honest attempt to face the problems with C that code cowboys have waved aside for decades. Could our industry be--at long, long last--tiring of crap security? May it be. By all means put a KVM switch in an 8-package/64-hart RISC-V 64 laptop. I promise not to block the vent. Regards, Branden [0] This is how you know I'm not a hardware guy. [1] https://lore.kernel.org/linux-man/ZU4SDh-Se5gjPny5@debian/T/#mfb5a3fdeb3548… [2] https://www.symas.com/post/the-sad-state-of-c-strings [3] An oft-heard rebuttal to this observation is that Google wasn't/isn't really trying to target the same applications as Rust. That sounds like post hoc sour grapes. It's Google. They put Thompson and Pike on this. They were shooting for the moon. [4] https://lwn.net/Articles/919016/ [5] https://git.savannah.gnu.org/cgit/gnulib.git/log/ ----- End forwarded message -----

1 0