Live data from Hacker News

Chrome OS KVM - A component written in Rust

chromium.googlesource.com

11–20 of 109 posts

Re: Chrome OS KVM - A component written in Rust

#11
post #4
post #2

The Fuchsia OS microkernel should be rewritten in Rust, too, especially if it's going to take another 5 years before we even see it in a commercial product. If Google wants to make a modern new OS that will help it avoid many of the existing security problems it needs to keep fixing with Android/Chrome OS right now, then it should do it right and avoid collecting a lot of "security debt" down the road because of unsa…

They should rewrite Go in Rust! That way we can avoid all this Go vs Rust discussions ;) Problem with your idea, is that low level kernel will use a lot of unsafe Rust, which will lose lot of benefits.

I would recommend looking at RedoxOS[1] (a kernel+userspace written in Rust) to see what a fairly reasonably featured operating system written in Rust looks like. "Using a lot of unsafe Rust" doesn't actually lose the benefits of Rust -- in fact annotating some code as unsafe is one of the benefits of Rust (you can much more easily tell where certain classes of bugs must originate from).

[1]: https://www.redox-os.org/

Re: Chrome OS KVM - A component written in Rust

#12
post #8
post #4

Earlier quoted context omitted.

They should rewrite Go in Rust! That way we can avoid all this Go vs Rust discussions ;) Problem with your idea, is that low level kernel will use a lot of unsafe Rust, which will lose lot of benefits.

> Problem with your idea, is that low level kernel will use a lot of unsafe Rust, which will lose lot of benefits. I've actually worked on a toy kernel in Rust (using the excellent tutorial at https://os.phil-opp.com/ ), and it turns out that, yes, you obviously need to use unsafe code to talk to the actual hardware. But in most cases, you can encapsulate the low-level hardware inside a safe API: https://github.com/e…

>But in most cases, you can encapsulate the low-level hardware inside a safe API

I'm probably missing something obvious. But isn't that true for most languages?

Re: Chrome OS KVM - A component written in Rust

#13
post #8

Earlier quoted context omitted.

> Problem with your idea, is that low level kernel will use a lot of unsafe Rust, which will lose lot of benefits. I've actually worked on a toy kernel in Rust (using the excellent tutorial at https://os.phil-opp.com/ ), and it turns out that, yes, you obviously need to use unsafe code to talk to the actual hardware. But in most cases, you can encapsulate the low-level hardware inside a safe API: https://github.com/e…

>But in most cases, you can encapsulate the low-level hardware inside a safe API I'm probably missing something obvious. But isn't that true for most languages?

Not really. I mean let's say you program in C, how will you enforce some pointer is never null? In Rust you can say &Object and that reference is never null (modulo any unsafe shenanigans).

Re: Chrome OS KVM - A component written in Rust

#14
post #13

Earlier quoted context omitted.

>But in most cases, you can encapsulate the low-level hardware inside a safe API I'm probably missing something obvious. But isn't that true for most languages?

Not really. I mean let's say you program in C, how will you enforce some pointer is never null? In Rust you can say &Object and that reference is never null (modulo any unsafe shenanigans).

Check it when you use it?

Re: Chrome OS KVM - A component written in Rust

#15
post #8

Earlier quoted context omitted.

> Problem with your idea, is that low level kernel will use a lot of unsafe Rust, which will lose lot of benefits. I've actually worked on a toy kernel in Rust (using the excellent tutorial at https://os.phil-opp.com/ ), and it turns out that, yes, you obviously need to use unsafe code to talk to the actual hardware. But in most cases, you can encapsulate the low-level hardware inside a safe API: https://github.com/e…

>But in most cases, you can encapsulate the low-level hardware inside a safe API I'm probably missing something obvious. But isn't that true for most languages?

In C and C++ you have to treat everything as unsafe, because you have neither a GC nor a compiler to help tell you when you have accidentally violated some memory management invariant that some API was depending on. Rust's type system gives you the tools to define those safe APIs and have them checked by the compiler, even if you need to do some unsafe shenanigans under the hood.

Re: Chrome OS KVM - A component written in Rust

#16
post #13

Earlier quoted context omitted.

>But in most cases, you can encapsulate the low-level hardware inside a safe API I'm probably missing something obvious. But isn't that true for most languages?

Not really. I mean let's say you program in C, how will you enforce some pointer is never null? In Rust you can say &Object and that reference is never null (modulo any unsafe shenanigans).

thankfully C++ has references.

Re: Chrome OS KVM - A component written in Rust

#17
post #13

Earlier quoted context omitted.

>But in most cases, you can encapsulate the low-level hardware inside a safe API I'm probably missing something obvious. But isn't that true for most languages?

Not really. I mean let's say you program in C, how will you enforce some pointer is never null? In Rust you can say &Object and that reference is never null (modulo any unsafe shenanigans).

Null is not really the most pertinent example in this context - at least you get a segfault. What is more important is that in C or C++ (even C++17), it is trivially easy to produce buffer overruns, use after frees, dangling pointers, invalidated iterators, data races etc. That is the unsafety that we are talking about here. Opt-in nullability via Option is nice to have though.

Re: Chrome OS KVM - A component written in Rust

#18
post #14
post #13

Earlier quoted context omitted.

Not really. I mean let's say you program in C, how will you enforce some pointer is never null? In Rust you can say &Object and that reference is never null (modulo any unsafe shenanigans).

Check it when you use it?

Experience tells us that this idea doesn't work so well in practice without a compiler yelling if you don't do it.

Re: Chrome OS KVM - A component written in Rust

#19
post #17
post #13

Earlier quoted context omitted.

Not really. I mean let's say you program in C, how will you enforce some pointer is never null? In Rust you can say &Object and that reference is never null (modulo any unsafe shenanigans).

Null is not really the most pertinent example in this context - at least you get a segfault. What is more important is that in C or C++ (even C++17), it is trivially easy to produce buffer overruns, use after frees, dangling pointers, invalidated iterators, data races etc. That is the unsafety that we are talking about here. Opt-in nullability via Option is nice to have though.

Yeah, I went with familiarity/simplicity in that example.

My point was similar C/C++ don't have a safe subset.

Post reply on HN