On Mon, Apr 13, 2020, 10:57 PM Demi Obenour
Do you plan to support multikernel configurations and/or virtualization? How do you expect performance and security to compare to Linux?
Multikernel will be supported and will be relatively transparent to user programs (the underlying topology will be visible for applications that want to control affinity). I'm probably not going to bother with Type 2 virtualization as is seen on Genode, CAmkES and L4Re, since there should be little need to run a Linux system virtualized under UX/RT on embedded systems due to the built-in compatibility with both Linux drivers and applications. I am planning to write an seL4-based Type 1 hypervisor to go with UX/RT, mostly for desktops and servers. This will be somewhat similar to Xen, but with disaggregated driver domains (the hypervisor will only run PVH and HVM-type VMs, not processes or PV-type VMs). UX/RT will run as a normal OS within a VM on top of the hypervisor (seeing as seL4 is quite lightweight, nested seL4 kernels should have less overhead than the nested Linux kernels commonly seen with KVM). I can't say for sure about overall performance, but I'm almost certain UX/RT will have much better IPC performance than Linux due to the lightweight IPC model. I would be surprised if overall performance isn't at least comparable to Linux in most situations though. It may even end up being like QNX and SysV back in the 90s with UX/RT outperforming Linux significantly in some cases once it is well optimized, but I can't guarantee that. I am expecting UX/RT to be significantly more secure than Linux. It will run all subsystems except for the kernel and root server as normal processes/libraries with limited privileges. Rust will be used for security-critical code wherever possible. The purely file-oriented architecture will significantly reduce the number of security-critical entry points compared to conventional OSes and will allow all access control rules (other than quotas) to be expressed in the same way. The new security model will be fully integrated rather than being an afterthought with no way to revert to traditional Unix root/non-root security, nor will the setuid/setgid bits have any effect. There will be a mechanism to run particular programs with escalated privileges but it will be more flexible, using roles instead of UIDs (it will also allow limiting the situations in which privilege escalation occurs), and it will store associations of privileges in a central store rather than file attributes.