I was looking at LionsOS docs recently, and noted it is meant for static systems with no support for changing hardware at runtime. This is less of a problem for phones and other handhelds given they generally keep the same hardware throughout their service life, but I was concerned about peripheral support. What if I want to be able to connect an external display to a phone or tablet running a LionsOS based userspace? Or I have privacy switches on the device that physically disconnect components such as the modem or camera assembly? Most of the system would be static, and only really changing for things such as loading isolated, untrusted application code (such as a Linux kernel, or something pretending to be a Linux kernel), but it would still have some hardware components that can be disconnected. Though at least in the case of privacy switches they would be the same components every time. What do y’all think? Does this idea of building a mobile phone OS on LionsOS have merit or would it make more sense to use a different framework or build something on seL4 directly?
"Isaac" == Isaac Beckett
writes:
Isaac> I was looking at LionsOS docs recently, and noted it is meant Isaac> for static systems with no support for changing hardware at Isaac> runtime. This is less of a problem for phones and other Isaac> handhelds given they generally keep the same hardware Isaac> throughout their service life, but I was concerned about Isaac> peripheral support. What if I want to be able to connect an Isaac> external display to a phone or tablet running a LionsOS based Isaac> userspace? Or I have privacy switches on the device that Isaac> physically disconnect components such as the modem or camera Isaac> assembly? 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. -- Dr Peter Chubb https://trustworthy.systems/ Trustworthy Systems Group CSE, UNSW Core hours: Mon 8am-3pm; Wed: 8am-5pm; Fri 8am-12pm.
On Fri, Aug 9, 2024 at 3:33 AM Peter Chubb via Devel
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.
Interesting! So in the case of the device I’ve got here with privacy switches, my drivers would detect the removal of the modem and respond by dropping queued packets? Or some other mechanism, depending.
On Aug 9, 2024, at 5:30 AM, Peter Chubb
wrote:
"Isaac" == Isaac Beckett
writes: Isaac> I was looking at LionsOS docs recently, and noted it is meant Isaac> for static systems with no support for changing hardware at Isaac> runtime. This is less of a problem for phones and other Isaac> handhelds given they generally keep the same hardware Isaac> throughout their service life, but I was concerned about Isaac> peripheral support. What if I want to be able to connect an Isaac> external display to a phone or tablet running a LionsOS based Isaac> userspace? Or I have privacy switches on the device that Isaac> physically disconnect components such as the modem or camera Isaac> assembly?
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.
-- Dr Peter Chubb https://trustworthy.systems/ Trustworthy Systems Group CSE, UNSW Core hours: Mon 8am-3pm; Wed: 8am-5pm; Fri 8am-12pm.
participants (3)
-
Andrew Warkentin
-
Isaac Beckett
-
Peter Chubb