2 ms·
As someone who was worked with this page and develops a rust kernel, I have to disagree. The two places of unsafe are barely just the minimum. When interactin
by zaarn 9y ago
As someone who was worked with this page and develops a rust kernel, I have to disagree.
The two places of unsafe are barely just the minimum.
When interacting with UEFI you have to include a bunch more unsafe clauses since you'll be FFI'ing to PE-calling convention C code to wrap the UEFI methods. You'll have to allocate memory without being able to malloc which means passing a raw memory block, allocate in C, to rust and tell the frame allocator to use that.
Setting up a syscall is unsafe, you have to use a naked function with internal unsafeness and the entire construct is unsafe because a syscall can easily crash the system if it doesn't return properly.
You will have to dereference null pointers because on kernel level a null pointer is a valid address (my UEFI places a memory region at 0x00 for about 30 pages which is a great starting region) unless you waste a buffer region. But Rust and LLVM don't allow that safely at all.
The very nature of a kernel is unsafe. It has to do very unsafe things in an unsafe way to enable software running in Ring 3 to make safe assumptions about it's environment as long as it gets scheduled.
Of course, Rust is somewhat better than C since it's type system allows one to express things without the entire construct blowing up every 2 minutes unless you're developing a kernel for years.
- steveklabnik 9y ago> The two places of unsafe are barely just the minimum. Yes, this is only one subsystem. Obviously, as you say, there are more than that in a realer kernel. But even larger ones have still shown that the vast majority of their stuff works in safe code. > Setting up a syscall is unsafe Fun detail, this isn't unsafe anymore on x86! You don't need naked functions; you can extern "x86-interrupt" fn some_handler() and LLVM knows how to properly do the codegen! This is kinda emblematic of what I mean: you can do more with safe code than you'd think.
- zaarn 9y ago>Fun detail, this isn't unsafe anymore on x86! On x86, not x86-64, which has the syscall instruction, replacing interrupts for syscalls (technically x86 had sysenter) The syscall instruction requires writing the address of the syscall function into the LSTAR MSR. Additionally, the syscall entry is purely naked, only the EIP and Segments are preserved and in a way that requires the caller to handle it. Sysret is also particularly nasty in being unsafe in various ways, including being buggy on all Intel CPUs. Atleast it's faster than interrupts and you don't technically need the -mno-redzone for it if it's not part of your interrupt handling code.