3 ms·

More like memory safer. A kernel necessarily has a lot of unsafe parts. See: https://github.com/search?q=repo%3Allenotre%2Fmaestro+unsafe&type=code https://gith

by GuB-42 3y ago

More like memory safer. A kernel necessarily has a lot of unsafe parts. See: https://github.com/search?q=repo%3Allenotre%2Fmaestro+unsafe&type=code https://github.com/search?q=repo%3Allenotre%2Fmaestro+unsafe... Rust is not a magic bullet, it just reduces the attack surface by isolating the unsafe parts. Another way to reduce the attack surface would be to use a microkernel architecture, it has a cost though.

arghwhat 3y ago
While I agree, do note that a significant portion of a kernel is internal logic that can be made much safer.
viraptor 3y ago
You're not really illustrating your point well with the link. If you look through the examples, they're mostly trivial and there's no clear way to eliminate them. Some reads/writes will interact with hardware and the software concepts of memory safety will never reach there because hardware does not operate at that level. Check a few of the results. They range from single assembler line (interrupts or special registers), array buffer reads from hardware or special areas, and rare sections that have comments about the purpose of using unsafe in that place. Those results really aren't "look how much unsafe code there is", but rather "look how few, well isolated sections there are that actually need to be marked unsafe". It's really not "a lot" - 86 cases across memory mapping, allocator, task switching, IO, filesystem and object loader is surprisingly few. (Actually even 86 is overestimated because for example inb is unsafe and blocks using it are unsafe so they're double-counted)
insanitybit 3y ago
Practically speaking, even with `unsafe` the exploitability of rust programs is extremely difficult. With modern mitigation techniques it is required that you be able to chain multiple vulnerabilities and primitives together in order to actually reliably exploit software. Bug density from `unsafe` is so low in Rust programs that it's just radically more difficult. My company (not me, Chompie did the work, all credit to her for it) took a known bug, which was super high potential (write arbitrary data to the host's memory), and found it extremely difficult to exploit (we were unable to): https://chompie.rip/Blog+Posts/Attacking+Firecracker+-+AWS'+microVM+Monitor+Written+in+Rust https://chompie.rip/Blog+Posts/Attacking+Firecracker+-+AWS'+... Ultimately there were guard pages where we wanted to write and it would have taken other vulnerabilities to actually get a working POC. Exploitation of Rust programs is just flat out really, really hard.
yencabulator 3y ago
Maestro has a lot of very old school hardware drivers: VGA, PS/2, IDE/ATA. Newer hardware tends to look like just a couple of ringbuffers, and the drivers should need a lot less of these hacks. Here's an NVMe driver in Rust that intends to avoid unsafe fully: https://rust-for-linux.com/nvme-driver https://rust-for-linux.com/nvme-driver

by GuB-42 3y ago

arghwhat 3y ago

While I agree, do note that a significant portion of a kernel is internal logic that can be made much safer.

viraptor 3y ago

You're not really illustrating your point well with the link. If you look through the examples, they're mostly trivial and there's no clear way to eliminate them. Some reads/writes will interact with hardware and the software concepts of memory safety will never reach there because hardware does not operate at that level. Check a few of the results. They range from single assembler line (interrupts or special registers), array buffer reads from hardware or special areas, and rare sections that have comments about the purpose of using unsafe in that place. Those results really aren't "look how much unsafe code there is", but rather "look how few, well isolated sections there are that actually need to be marked unsafe". It's really not "a lot" - 86 cases across memory mapping, allocator, task switching, IO, filesystem and object loader is surprisingly few. (Actually even 86 is overestimated because for example inb is unsafe and blocks using it are unsafe so they're double-counted)

insanitybit 3y ago

Practically speaking, even with `unsafe` the exploitability of rust programs is extremely difficult. With modern mitigation techniques it is required that you be able to chain multiple vulnerabilities and primitives together in order to actually reliably exploit software. Bug density from `unsafe` is so low in Rust programs that it's just radically more difficult. My company (not me, Chompie did the work, all credit to her for it) took a known bug, which was super high potential (write arbitrary data to the host's memory), and found it extremely difficult to exploit (we were unable to): https://chompie.rip/Blog+Posts/Attacking+Firecracker+-+AWS'+microVM+Monitor+Written+in+Rust https://chompie.rip/Blog+Posts/Attacking+Firecracker+-+AWS'+... Ultimately there were guard pages where we wanted to write and it would have taken other vulnerabilities to actually get a working POC. Exploitation of Rust programs is just flat out really, really hard.

yencabulator 3y ago

Maestro has a lot of very old school hardware drivers: VGA, PS/2, IDE/ATA. Newer hardware tends to look like just a couple of ringbuffers, and the drivers should need a lot less of these hacks. Here's an NVMe driver in Rust that intends to avoid unsafe fully: https://rust-for-linux.com/nvme-driver https://rust-for-linux.com/nvme-driver