Earlier quoted context omitted.
Theres Common Lisp in there! When did that happen?
When they bougth ITA Software.
Ah right. Forgot ITA.
Chrome OS KVM - A component written in Rust
101–109 of 109 posts
Re: Chrome OS KVM - A component written in Rust
#102This is huge for chromeOS. Hope we learn more next week from Google on the 4th.
Re: Chrome OS KVM - A component written in Rust
#103Earlier quoted context omitted.
References can still be null.
In C++, null references are Very Bad, and they trigger undefined behavior: https://stackoverflow.com/questions/4364536/is-null-referenc... I don't think I've ever run into a null reference in the real world. I'm sure it happens, especially if people write "&*some_function_that_might_return_null()". But it shouldn't be a normal thing. There are lots of other issues with C++, but this has never been a major one in my e…
> In C++, null references are Very Bad,
They are!
And while they are not a normal thing, they are a thing and I've run in to them a handful of times in the real world, almost always the result of someone not checking for null before dereferencing a pointer.
Rust does not really have this issue.
Re: Chrome OS KVM - A component written in Rust
#104Earlier quoted context omitted.
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.
Compiler doesn't yell, because it's unnecessary in most cases.
My experience is that huge amount of C code running on my computer had exactly zero issues like this today. It has been working perfectly fine.
I run GNOME which uses a paradigm of checking all inputs to a function on entry via g_return(_val)_if_fail(assertion_expression). It helps the programmer do the right thing when it comes to using APIs that are disallowing NULL input.
Two days ago, the code on my workstation hit one of those "assertions":
Sep 26 23:40:31 core transmission-gt[1084]: g_file_test: assertion 'filename != NULL' failed
No oops in the kernel recently.
Millions of lines of desktop and kernel code, and one failed assertion in two days for using NULL incorrectly in the API.
So unless your standard is absolute perfection, it works fine as is.
Re: Chrome OS KVM - A component written in Rust
#105Earlier quoted context omitted.
The 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 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.
I think it's best to keep unsafe blocks as small as possible. Within an unsafe block there is undefined behavior, so you want to get out of there ASAP. Just my opinion.
Personally I disagree, but mostly because I think the `unsafe` model Rust has is worth much less then people give it credit for.
For one, there is the current problems of documentation - it's not documented what features/invariants the optimizer and language actually require to be true, and the nitty gritty details are very fuzzy, so switching from `unsafe` to `safe` is error prone and you're going to get it wrong. The more you do it, the more likely it is your code will be broken in the future when you find out something you thought was OK isn't actually something the Rust devs like or isn't something they wanted you doing. If you do more of the `unsafe` work in one big `unsafe` block rather then jumping in and out, you're less likely to have issues in the future because there's less points where you have to ensure all the Rust invariants are met.
But the bigger detail for me is that, even if the above problem is fixed, `unsafe` doesn't really denote the areas we would consider the `unsafe` areas anyway, so "getting out of there ASAP" is not always a helpful mindset and can easily be counter-productive and result in you marking things `safe` when they're not actually `safe`. For example, dereferencing a pointer is `unsafe`, but doing pointer-arithmetic is `safe`. So you can easily just wrap the dereference in an `unsafe` block and your technically good to go (You can even wrap it in a pretty interface, like I've seen people do). But all the spots where you do pointer-arithmetic can easily introduce bugs into your `unsafe` code, making it hardly any better than C code that could have the same problem (Half the point of using Rust is to avoid bugs from unchecked pointer-arithmetic!).
My point being, just because your `unsafe` blocks are small doesn't tell you anything about the correctness of them, and it likely means they rely on outside information to be correct. And if that is the case, then that outside code is effectively just as dangerous as your `unsafe` code. This may be obvious to you, and I apologize if it is, but this is an issue/misconception I see a lot. IMO, you should mark anything `unsafe` if using it within the bounds of `safe` Rust could potentially cause `unsafe` code to fail, even if the code itself is completely `safe` code. Only if you have an interface the meets all the invariants that Rust requires should you allow it to be considered `safe`.
Re: Chrome OS KVM - A component written in Rust
#106Earlier quoted context omitted.
In C++, null references are Very Bad, and they trigger undefined behavior: https://stackoverflow.com/questions/4364536/is-null-referenc... I don't think I've ever run into a null reference in the real world. I'm sure it happens, especially if people write "&*some_function_that_might_return_null()". But it shouldn't be a normal thing. There are lots of other issues with C++, but this has never been a major one in my e…
> In C++, null references are Very Bad, They are! And while they are not a normal thing, they are a thing and I've run in to them a handful of times in the real world, almost always the result of someone not checking for null before dereferencing a pointer. Rust does not really have this issue.
Rust also has this issue, unless you fully validate every single pointer coming out of unsafe blocks.
Re: Chrome OS KVM - A component written in Rust
#107Earlier quoted context omitted.
> In C++, null references are Very Bad, They are! And while they are not a normal thing, they are a thing and I've run in to them a handful of times in the real world, almost always the result of someone not checking for null before dereferencing a pointer. Rust does not really have this issue.
Rust also has this issue, unless you fully validate every single pointer coming out of unsafe blocks.
The difference being that all c++ code is 'unsafe' in the rust sense, whereas a typical rust program will have only a small portion of unsafe code (or none), making it easier to fully validate - hence 'doesn't really have this problem'.
Re: Chrome OS KVM - A component written in Rust
#108Earlier quoted context omitted.
Rust also has this issue, unless you fully validate every single pointer coming out of unsafe blocks.
The difference being that all c++ code is 'unsafe' in the rust sense, whereas a typical rust program will have only a small portion of unsafe code (or none), making it easier to fully validate - hence 'doesn't really have this problem'.
I agree, but it depends how seriously unsafe blocks get reviewed.
Because I can assure you, unsafe blocks in enterprise Rust will be reviewed as much as C and C++ code currently are in most Big Corps™.
We do have such problems with native libraries killing Java and .NET processes, with unsafe being the FFI boundary.
Re: Chrome OS KVM - A component written in Rust
#109The 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…
I'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'…
> See for example the sel4 microkernel, which is small enough to have a well-verified model for a bunch of different hardware.
The workflow for seL4 starts with prototyping in Haskell, formalizing everything in Isabelle, and then translating into C. This results in highly unusual C code and much of it would be better serviced with a DSL. I'm guessing that C chosen because it has formally verified semantics and compilers as well as integration with proofing assistants.