On Fri, Aug 9, 2024 at 3:33 AM Peter Chubb via Devel <devel@sel4.systems> wrote: > > This kind of thing is doable, or rather will be doable, by swapping out > modules. Although the _architecture_ is static, not all the modules > need to be runnable at any one time. In LionsOS one will be able to > instantiate template PDs that can run a range of different payloads > loaded at run-time, to allow a degree of dynamism. > > We have a student working on the hotplug problem at the moment. But > it's unclear, in the general case, what should happen when something > appears in, or disappears from, the system. Utimately it's going to > be up to the system designer to design something that works for each > system. > > For example, if you remove a storage device (SDHC card, or USB stick). > Your alternatives are: > -- discard all in-flight requests for the device, unmount any > filesystems etc. > -- Mark the device as 'gone'; but if there are any in-flight requests, > or if any new requests get queued, ask the GUI to pop up something > asking for reinsertion of the device (like AmigaDOS did) > -- something else I haven't thought of... > > In whatever case, you need system policy to decide what to do, and > code to implement it. > > I expect the handheld device _will_ eventually be a target for a > LionsOS system, but there's a fair bit of work to do. > > In the near term, there will have to be more device drivers and > virtualisers in the sDDF; more higher-level components in LionsOS > itself; and the template PDs that are currently being worked on here > by an undergraduate student. >
Even with this limited form of dynamism it's still going to be rather limiting. I'd think it would be limited to be more or less like a software secure enclave type of thing, or a fixed set of VMs for different security levels. Applications are still likely going to be run in Linux VMs with all of the issues of Linux. Running Linux VMs and a relatively closed set of secure applications isn't going to magically fix all of Linux's issues. IMO a better approach for general-purpose OSes is to forgo verification and go with something more akin to QNX architecturally (of course, with a centralized security model rather than QNX's security model that requires origin servers to verify permissions). Even a non-verified QNX-like system is going to be far more secure, stable, and extensible than just about any kind of Linux system. _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
