Comment by ekidd | Hacker News Reader

Comment by ekidd | Hacker News Reader

Parent Full thread

> 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/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.

Nice 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! :-)

It'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.

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

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<T> 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

> at least you get a segfault

If the platform has an MMU, if you've properly set up your page table mappings, etc. We are talking about writing an OS here!

Not to mention all the UB around null pointers that can cause miscompilation. Well, not technically miscompilation, but stuff like https://news.ycombinator.com/item?id=15324414

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

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

Not a safe subset anyone would want to use at least. You could just not use pointers in your code and you'd have memory safety.

Your code, or any of the code it calls; iterator invalidation, for example, wouldn't force you to use pointers directly, but can still cause memory unsafety.

thankfully C++ has references.

C++ references aren't exactly safe either.

    std::vector<int> 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);

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 experience.

> 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'.

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.

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.

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.

There's unsafe hidden under an API that you know where you're using, and unsafe in every single line in your software. Just like there's changing state encapsulated in object methods, and changing state by assigning to global variables.

Theoretically it's just all the same, but in practice having reduced interfaces does wonders to reduce the complexity and being able to reason about what brings problems, and what doesn't.

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.

Reply on news.ycombinator.com