That seems like it could be an interesting way to launch Rust applications. Typically (and I'm assuming UKL is no different), unikernels don't have any memory protection between applications and the OS. That's usually a bad thing; however, if your compiler can verify that memory accesses are all in-bounds, then all the hardware memory checks that an MMU would do in a regular OS are just unnecessary overhead. So, with UKL and a Rust application, you could get approximately the same level of safety as before, but without the performance cost of all that runtime memory protection. Entering the kernel can be just a regular function call, context switches are cheap, etc... That could be a huge performance boon for some apps.
In this sort of setup, unsafe Rust is like kernel code -- it effectively has privilege to read/write to any memory.
I'd also feel better if the kernel itself were written in something like Rust.
all unikernel implementations I'm familiar with are single process by nature and thus the protection that you need on a multiple process system such as linux is completely un-necessary, especially since they are always deployed as vms
Well, strictly speaking it's safer to have a system where the application can't write into kernel memory space and the kernel can't (accidentally) write into application space.
You don't have the risk of leaking secrets or malicious interference between applications that are supposed to be isolated if you've only got one app, but I could still see where someone might rather have memory protection than not in a single-user/single-application environment.
In this sort of setup, unsafe Rust is like kernel code -- it effectively has privilege to read/write to any memory.
I'd also feel better if the kernel itself were written in something like Rust.