3 ms·

> Rust in no_std mode isn't much different than C This isn't really true; you still have memory safety, and generics and a sane stdlib.

zaarn 8y ago
Memory safety flies out the window when you write a kernel and the stdlib isn't available in no_std mode. You only get a very limited subset in the core lib. Memory safety in kernels is hard because you might have to do things like switch stack or even address space and the rust compiler handles such actions rather poorly. Whether or not writing to the rsp register will crash the kernel or successfully pivot the stack is guesswork at best and only works reliably if you code it entirely in inline assembly.
- pjmlp 8y ago
  Memory safety in kernels is also welcomed and is very present in mainframe OSes and high integrity systems where human lives are at stake. Yes, there are a couple of areas where unsafety is required, there isn't any other way. However 100% of the kernel source code doesn't need to be unsafe.
  - zaarn 8y ago
    There is two types of memory safety that you talk about there, I think. One is the memory safety that the rust compiler wants to hold and the other is the memory safety you program into a system. Those can be entirely different with incompatible guarantees, depending on the mission statement of the software. Some things a kernel must do are unsafe for the rust compiler. Dereferencing a null pointer, for example, is basically a crash in most operating system's userland. In kernel space a null pointer may be valid memory that points to real data you need to use. Setting the page tables is unsafe as well; it's almost impossible to guarantee that the following instructions can run in a static manner. You have to validate the page tables you're about to load at runtime and even then the result could be a process crashing.
- MrBuddyCasino 8y ago
  Look at the embedded Rust stuff like RTFM - they find clever ways to build safe abstractions over unsafe primitives. If you can get 95% memory safe device drivers, thats already a huge win.
  - zaarn 8y ago
    Correct and in my own project I want to achieve 100% memory safety for non-primitive drivers (Disks, GPU, Ethernet, USB Devices) and 100% memory safety for any non-privileged code of primitive drivers (ie, PCIe bus, SATA, USB, etc.). Any privileged code can then be written with those 95% and that's the only weak point left.

zaarn 8y ago

Memory safety flies out the window when you write a kernel and the stdlib isn't available in no_std mode. You only get a very limited subset in the core lib. Memory safety in kernels is hard because you might have to do things like switch stack or even address space and the rust compiler handles such actions rather poorly. Whether or not writing to the rsp register will crash the kernel or successfully pivot the stack is guesswork at best and only works reliably if you code it entirely in inline assembly.

pjmlp 8y ago
Memory safety in kernels is also welcomed and is very present in mainframe OSes and high integrity systems where human lives are at stake. Yes, there are a couple of areas where unsafety is required, there isn't any other way. However 100% of the kernel source code doesn't need to be unsafe.
- zaarn 8y ago
  There is two types of memory safety that you talk about there, I think. One is the memory safety that the rust compiler wants to hold and the other is the memory safety you program into a system. Those can be entirely different with incompatible guarantees, depending on the mission statement of the software. Some things a kernel must do are unsafe for the rust compiler. Dereferencing a null pointer, for example, is basically a crash in most operating system's userland. In kernel space a null pointer may be valid memory that points to real data you need to use. Setting the page tables is unsafe as well; it's almost impossible to guarantee that the following instructions can run in a static manner. You have to validate the page tables you're about to load at runtime and even then the result could be a process crashing.
MrBuddyCasino 8y ago
Look at the embedded Rust stuff like RTFM - they find clever ways to build safe abstractions over unsafe primitives. If you can get 95% memory safe device drivers, thats already a huge win.
- zaarn 8y ago
  Correct and in my own project I want to achieve 100% memory safety for non-primitive drivers (Disks, GPU, Ethernet, USB Devices) and 100% memory safety for any non-privileged code of primitive drivers (ie, PCIe bus, SATA, USB, etc.). Any privileged code can then be written with those 95% and that's the only weak point left.