On 12/2/20, Kent Mcleod <kent.mcleod72@gmail.com> wrote:
I'm not aware of any purely scientific/technical reason why this wouldn't be accepted. Running a user app in 32-bit mode on a 64-bit operating system as a hardware feature isn't something that seL4 has an opinion about allowing or restricting. It's more an issue about whether it would be high enough in a priority-ordered list to justify the costs of developing and supporting. If someone could demonstrate that this cost is actually pretty low and worked towards a proposal to add it, then it would still be possible.
I would have thought that it would be rejected for similar reasons that a system call origin limit would be, since both running 32-bit code on a 64-bit system and system call interception could already be done with virtualization. Support for 32-bit compatibility mode isn't all that useful to me without a system call origin limit (or some other way to intercept foreign system calls that doesn't depend on hardware extensions that aren't always available) though, since it will mainly be used for running 32-bit Linux programs. On 12/2/20, Indan Zupancic <indan.zupancic@mep-info.com> wrote:
The main problem is that you don't want VM user space to block the whole VM by doing a blocking seL4 call. Currently it does not provide a good way to receive notifications, only to send them. And interaction with IRQ delivery is tricky.
Because of the above limitation it's unclear if it's worth it for our use case, so I haven't actually tried it out yet.
That would basically render it useless for my purposes. I was thinking of an interface that would vector incoming messages to an interrupt. It also has to work on x86 as well. On 12/2/20, Demi M. Obenour <demiobenour@gmail.com> wrote:
That said, a set of userland utilities to run multiple seL4-based systems on the same kernel would could arguably be considered a hypervisor, and I consider it quite practical. There may also be cases where the extra layer of page tables used in a VM are necessary for some reason. The only one I can think of is to prevent physical addresses from being leaked, since obtaining them is a prerequisite to Rowhammer attacks.
I don't really want to add any kind of multi-personality infrastructure to UX/RT beyond VFS-level containerization, since it would complicate the architecture a fair bit. There is already going to be support for hosting device backends since I want the option of virtualizing other systems alongside UX/RT. I also want to be able to run complete UX/RT VMs including their own kernels for testing/development purposes (and possibly running older applications, although UX/RT will generally try to maintain backwards compatibility unless there is a good reason not to). It's very likely that there could be issues that only show up when running as a VM and not as an alternate personality (or issues that only appear when running as an alternate personality), and also the lack of a stable kernel API would make mixing versions much more difficult. I don't really think there would be any serious issues with nesting microkernels in VMs. Nesting instances of the same monolithic kernel is already common with type 2 VMMs, and I would imagine there would be less overhead with nesting lightweight microkernels than there would be with monolithic kernels.