Live data from Hacker News

Chrome OS KVM - A component written in Rust

chromium.googlesource.com

41–50 of 109 posts

Re: Chrome OS KVM - A component written in Rust

#41
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.

It would be kind of cool to see a `go gen`-syntax based Go + generics implemented in Rust. Another thing that has been attempted is a stdlib for Rust that uses syscalls into the kernel much like Go's.

Re: Chrome OS KVM - A component written in Rust

#42
post #27
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…

So you could do the same in C/C++, if you use unsafe it's unsafe that it's. I can't believe people arguing over unsafe used in a safe way.

The responsibility of proving safety can belong to the compiler or it could belong to the programmer. The compiler can do a very good job, but there are edge cases where your code can become convoluted and things aren't expressed easily. The programmer can do a good job of expressing things, but is usually not able to prove safety of large blocks.

unsafe blocks are just a compromise where the programmer only has to prove safety of small blocks of code which aren't easily expressed in the type system.

Re: Chrome OS KVM - A component written in Rust

#43
post #38
post #3

Earlier quoted context omitted.

You absolutely right! You can imagine what Google can do with his resources when even one programmer writes his own OS, file system, etc on Rust - https://github.com/redox-os/ !

What is the connection between Google and Redox? I didn’t understand you to be honest.

I try to say when you use a good programming language with a really cool compiler which can prevent a lot of errors you can be very efficient and don't lose most of time in debugger!

Re: Chrome OS KVM - A component written in Rust

#44
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.

> at least you get a segfault.

If there were a list "falsehoods software engineers believe about memory safety" this should be there.

https://cansecwest.com/slides07/Vector-Rewrite-Attack.pdf

Re: Chrome OS KVM - A component written in Rust

#45
post #33
post #26

Earlier quoted context omitted.

I see a place for both of them in my toolbox. Go still makes network code and certain models of concurrency stupidly simple. Rust is more of a replacement for C/C++ for me.

Go confirmed for me what I suspected: which is that I hate hate hate the futures style of async programming. I'm on the lookout for channels and green-threads in Rust (so I can basically write borrow-checked Go-style code in Rust).

Channels are there but you have to use an API for them. Green threads were removed a few years ago, though there are implementations of co-routines, etc. as crates.

Rust is getting an unstable form of async and await as macros/syntax extensions, and there are RFCs discussing adding them to the language in some form. This would still be a wrapper for futures, but a more ergonomic way of using them.

Re: Chrome OS KVM - A component written in Rust

#46
post #16
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).

thankfully C++ has references.

C++ references aren't exactly safe either.

    std::vector x;
    x.push_back(4);
    int& val = x.back();
    x.push_back(5); // ahh, val may be garbage now.
or

    Foo f;
    Foo& fRef = f;
    Foo g = std::move(f);

Re: Chrome OS KVM - A component written in Rust

#47
post #7

Is Rust an officially sanctioned language at Google?

Author here: Rust is not officially sanctioned at Google, but there are pockets of folks using it here. The trick with using Rust in this component was convincing my coworkers that no other language was right for job, which I believe to be the case in this instance.

That being said, there was a ton of work getting Rust to play nice within the Chrome OS build environment. The Rust folks have been super helpful in answering my questions though.

Re: Chrome OS KVM - A component written in Rust

#48

Isn't stuff like that exactly counteracting Rusts raison d'etre? > // This is safe; nothing else will use or hold onto the raw sock fd. > Ok(unsafe { net::UdpSocket::from_raw_fd(sock) }) https://chromium.googlesource.com/chromiumos/platform/crosvm...

That's low-level code implementing a wrapper around the underlying libc socket API; there's no alternative to unsafe blocks there as it wraps a legacy API written in C. The "this is safe" comment is just a (very verbose) explanation as to why the wrapper code is doing the correct thing. Notably, there's another similar comment just above it. In fact, looking through the file if anything I'm quite impressed at how car…

Author here: one of the policies we tried to stick to when writing unsafe code was to document each case. It can be tedious but it encourages having less unsafe code and makes the author really think about if this unsafe code is really meeting the same guarantees as safe Rust according to https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

Re: Chrome OS KVM - A component written in Rust

#49

Earlier quoted context omitted.

That's low-level code implementing a wrapper around the underlying libc socket API; there's no alternative to unsafe blocks there as it wraps a legacy API written in C. The "this is safe" comment is just a (very verbose) explanation as to why the wrapper code is doing the correct thing. Notably, there's another similar comment just above it. In fact, looking through the file if anything I'm quite impressed at how car…

Author here: one of the policies we tried to stick to when writing unsafe code was to document each case. It can be tedious but it encourages having less unsafe code and makes the author really think about if this unsafe code is really meeting the same guarantees as safe Rust according to https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

I've also found this to be a really good approach to unsafe. Declare why something is actually safe and you may realize it isn't. It also helps when writing tests to assert safety - you have a comment explaining exactly the invariants you need to test.

Re: Chrome OS KVM - A component written in Rust

#50

Isn't stuff like that exactly counteracting Rusts raison d'etre? > // This is safe; nothing else will use or hold onto the raw sock fd. > Ok(unsafe { net::UdpSocket::from_raw_fd(sock) }) https://chromium.googlesource.com/chromiumos/platform/crosvm...

I take the exact opposite view: The goal of Rust is to give you tools to manager you unsafe code. Writing Rust code that avoids `unsafe` is counteracting its raison d'etre.
Post reply on HN