10 ms·
Chrome OS KVM - A component written in Rust
- mtgx 9y agoThe 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 unsafe code/poor initial security architecture decisions.
- cyber1 9y agoYou 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/ https://github.com/redox-os/!
- 0xFFC 9y agoWhat is the connection between Google and Redox? I didn’t understand you to be honest.
- cyber1 9y agoI 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!
- mtgx 9y agoI think he meant that if one guy developed Redox in his spare time, surely it wouldn't be too hard for a Google team to "simply" rewrite Fuchsia in Rust.
- Ygg2 9y agoThey 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.
- cyber1 9y agoAccording to memory management, yes but you have a lot of benefit from the strong type-safe system, ecosystem, testing and etc.
- ekidd 9y ago> 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/ 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/emk/toyos-rs/blob/fdc5fb8cc8152a63d1b6c85cd357737e6b1aebb5/crates/cpuio/src/lib.rs#L43-L75 https://github.com/emk/toyos-rs/blob/fdc5fb8cc8152a63d1b6c85... In this example, only I/O port creation is an unsafe API, because you need to specify a memory address to read and write. But once the port is created (pointed at an appropriate address!), it's perfectly safe to use. So, yes, kernel-space Rust will use "unsafe" far more often than regular Rust code. But you can still make at least 80% of your code safe, and maybe much more. And the remaining "unsafe" APIs act as a useful warning to pay attention to what you're doing. Plus, Rust is a really nice language to write kernel code in, anyway.
- angrygoat 9y agoNice to have the dangerous bits annotated – in a C/C++/... kernel, everything is "unsafe". "Given enough eyeballs, all bugs are shallow" - but it helps when the eyeballs are focussed! :-)
- staticassertion 9y agoIt's hard to emphasize the auditability enough. With auditing a C/C++ codebase, in my experience, you rely a lot on intuition. "Well, there's parsing done here, so I'll focus my efforts" or "Historically we've had a lot of CVEs from this part of code so I'll start there". I'm not a professional RE so my experience is limited, but when I went looking for vulns that's how I went about it, and I think that's generally the case. With rust there's significantly less guesswork. That parser doesn't use unsafe? OK, let's start elsewhere. That seemingly innocent code uses unsafe? Great, check that out. You can grep for vulnerabilities, basically.
- pjmlp 9y agoThe TCP/IP stack and file system driver are written in Go.
- kristianp 9y agoSee https://github.com/fuchsia-mirror?language=go https://github.com/fuchsia-mirror?language=go
- dikaiosune 9y agoI'm normally quite happy to advocate for Rust everywhere, but one of the benefits of the microkernel architecture is that you have a very small trusted computing base for your system. Yes, Rust could help, but there are lots of techniques for building highly reliable C/C++ codebases, and one of the main reasons they don't get used more in large codebases is that they don't scale super well. But, in a microkernel it's much easier to apply those methods. See for example the sel4 microkernel, which is small enough to have a well-verified model for a bunch of different hardware. Uh, this is rambling a bit. My point is that building zircon as a microkernel makes it much easier to write correct code, Rust or not. And that maybe the overhead of a rewrite wouldn't be as beneficial for the microkernel as it would be for other parts of the operating system.
- colemickens 9y agoThis is virtually the same reply that every single "rust would help with safety" comment gets every time without fail. And despite those tools, mistakes occur in the most critical of codebases. In fact just early today a patch to LKML was being mocked because some pointer manipulation in C was clearly buggy and uncaught due to the lack of safety and sophistication of the type system.
- dikaiosune 9y agoI don't think this is quite the template reply (and if you check my HN comment history, I think you might see that I'm quite familiar with receiving the template replies!), what I meant to say is that it'd be much higher leverage to rewrite other parts of Fuchsia in Rust than to rewrite Zircon.
- colemickens 9y agoSorry, I didn't mean to put words in your mouth or anything. I am quite curious which parts you think would better benefit from a rewrite in a safer language if you might elaborate. Thanks!
- 9y ago
- indy 9y agoIs Rust an officially sanctioned language at Google?
- MrBuddyCasino 9y agoSince Rust is one of the most energy efficient languages and also safe, it sounds like a good fit for Google. I always wondered if they would pick it up.
- Santosh83 9y agoCan you expand upon what makes Rust more energy efficient than C or C++? What are the language properties that enable Rust code to be more energy optimised?
- vntok 9y agoIt's not even ranked first. Rust comes a good second to third behind C & C++ on most if not all tests listed on https://sites.google.com/view/energy-efficiency-languages/results https://sites.google.com/view/energy-efficiency-languages/re...
- RodericDay 9y ago"one of the most energy efficient" + "safe"
- icebraining 9y agoIn the normalized global results, at the bottom, Rust is above C++, and closer to C than C++ is to it.
- tmzt 9y agoThis is more a reflection of where the compiler is at, not the language. As a compiled, strongly-typed language without a GC, there is no theoretical reason why Rust could not be faster than C++. As the use of MIR and HIR (two intermediate languages used within the compiler) increases more optimizations taking advantage of the memory model could be added. In the current state, much of that work is left to LLVM which is designed more around the C/C++ memory model and only some of the ownership and aliasing information can be represented in that form. I am not arguing that Rust is faster now, only that it can be without fundamentally changing the language.
- jhoechtl 9y agoIsn'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/+/6f366b54604e4012b43822d5dc2afe7d1616287d/net_util/src/lib.rs#55 https://chromium.googlesource.com/chromiumos/platform/crosvm...
- petertodd 9y agoThat'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 carefully it's written.
- zaxcellent 9y agoAuthor 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 https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
- staticassertion 9y agoI'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.
- bluetech 9y agoThe line above has this: // This is safe since we check the return value. let sock = unsafe { libc::socket(libc::AF_INET, libc::SOCK_DGRAM, 0) }; if sock < 0 { return Err(Error::CreateSocket(IoError::last_os_error())); } I think in this case it would be better to put the return value check within the unsafe block, this way the unsafety does not "leak out" of the block, so to speak, so it is easier to audit. Of course in such a trivial case it does not matter much.
- O_H_E 9y agoWhether you want Rust to go or, Go to rust
- wybiral 9y agoI 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.
- XorNot 9y agoGo 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).
- tmzt 9y agoChannels 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.
- infogulch 9y agoI'm not entirely convinced that async annotations can't be completely elided. I think that any call stack that touches a sync/async API could have the decision of which to use bubbled up to a top level function via generics.
- zaxcellent 9y agoThere is a somewhat expanded README that has yet to be reviewed and checked in here: https://chromium.googlesource.com/chromiumos/platform/crosvm/+/837b59f2d97b005ef84ac36efa97530c1bbf2a79/README.md https://chromium.googlesource.com/chromiumos/platform/crosvm...
- deleted 9y ago[deleted]
- mato 9y agoSolo5/ukvm unikernel monitor co-author here: I've been thinking about rewriting ukvm in Rust off and on for some time now, your work provides a proof point that it can be done. I'll be following it with interest. Aside: I really like what the ChromeOS team has done over the years to advance the state of OS security for consumers, keep up the good work!
- inondle 9y agoIs this a new component for Chrome OS? Would this be a replacement for a project like Crouton or is something like this already being leveraged by that project?
- dward 9y agoCrouton is just a chroot to some linux distro. It doesn't use any sort of virtualization.
- sangnoir 9y agoHow does this square with rumors from a few days ago that the Pixelbook will be able to run virtualized Windows (or Linux)? I do not understand the implication of "No actual hardware is emulated." If the Pixelbook can run Window or Linux in a VM, then its price slides a little closer towards justifiable.
- mcpherrinm 9y agoAt least what exists today appears to me aimed at running Linux (or other KVM-aware guests, maybe BSD). I have only briefly read the code. This may be used as part of running Android apps on ChromeOS in more secure sandboxes, but the Wayland integration suggests to me this might be for running traditional Linux desktop applications on ChromeOS. I think there's a good chance we'll find out something at the rumored upcoming Pixelbook launch.
- jacksmith21006 9y agoThis is huge for chromeOS. Hope we learn more next week from Google on the 4th.