Hacker News Reader

Comment by alexfromapex | Hacker News Reader

Preventing bugs like this is where Rust would shine in the kernel

Rust would help with bugs like the initial memory unsafety. Half the blog post is about resilience even in the face of memory unsafety though, especially since the entire point is that there only has to be one bug, in any legacy subsystem, to exploit the entire kernel. Using Rust doesn't magically add any of those defense-in-depth mitigations and pessimistic sanity checks.

Resilience is impossible in C-family languages, given undefined behaviour. Any defence-in-depth checks you add can only be triggered once you're already in an undefined state, so the compiler will helpfully strip them out (this has already happened in Linux and is the reason they build with -fno-delete-null-pointer-checks, but C compilers have very little appetite for broadening that kind of thing).

That seems like a weird way to do it. Wouldn't it be better to have compile errors if the compiler figures out that it can remove a null check?

The "inconvenient truth" with Undefined Behaviour is that it provides essential wiggle room for the compiler to implement some optimizations that wouldn't be possible with a stricter specification. Of course the downside is that sometimes the compiler goes too far and removes critical code (which AFAIK is still a hot discussion topic how much compilers should be allowed to exploit UB for optimizations).

Because that was the only way for C to catch up with stuff that was being done in languages like PL.8.

So compiler optimizers get to take advantage of UB for that last mile optimization, which in a language like C always expect the developer to be a ISO C expert, and when they aren't or are too tired trying to meet project deadlines, surprises happen.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

It's not "essential". On realistic code it's single-digit percentages at most. But it's essential for winning compiler benchmarks, so you'll never get C compilers to stop doing it.

You would have a huge number of false positives, because if you're doing a bunch of null checking defensively you're going to be doing it redundantly a lot.

Right, but if the compiler has proved that you don't need those null checks then you can simply remove them. If you think you do need them then it's a sign you've screwed up somewhere and should fix it!

The problem is that it's not that simple. A NULL check might only become redundant after various rounds of inlining and optimizing, and the same NULL check could be redundant in one usage and necessary in the other. It's also very likely that changes to other parts of the code will make a previously 'redundant' NULL check now necessary, and obviously you're unlikely to get a warning in that direction.

> Right, but if the compiler has proved that you don't need those null checks then you can simply remove them.

This can be the case now, but then later someone adds new code that you did need that null check.

> If you think you do need them then it's a sign you've screwed up somewhere and should fix it!

Hm, so instead of

> Wouldn't it be better to have compile errors if the compiler figures out that it can remove a null check?

you wanted the opposite: warn when a null check is there and was actually required :).

Not sure if this is a working solution either. Maybe if it was behind a macro, JUST_CHECKING_IF_NULL(x)..

Yeah sounds like the best solution is explicit checks that the compiler understands - REDUNDANT_NULL_CHECK(...), REQUIRED_NULL_CHECK(...).

I mean obviously the solution is to use a sane language but you know...

Did you read the last part of the article? It explicitly says that Rust (or some other kind of languages guarantees) would absolutely remove the need for more complex runtime measures. Additionally, such checks stop the exploit chain early before it’s able to pick up steam.

It speculates that Rust would help. That is very far from demonstrating that Rust would actually help.

Rust would certainly not help in this instance, because nobody is writing pty handling code in Rust. I.e., using Rust in place B does not help with bugs in place A. Any expectation that Linux would get more secure if some new code were Rust is optimistic to the point of fantasy.

The best possible outcome of allowing Rust in kernel code is that the kernel would not become even more insecure as a result of the added Rust code. That would be good, by itself, even if not what we really want. But whether even that would be achieved in practice is still to be demonstrated.

The best possible outcome of allowing Rust in kernel code is being able to guarantee type safety, memory safety and perfect concurrency where it's applied. Those 3 pain points are where C fails right now, and it's part of the reason why scheduling on Linux feels 'worse' than Windows or even MacOS at times.

I.e., exactly what I just said, but longer.

I think the point is that as Rust is able to tackle more parts of the kernel, existing code can start to be rewritten in it.

But it might remove another hole in the swiss cheese security model, which can be worth it.

Do we know what the performance impact of adding all these checks is?

Huge. Only checking array bounds on every access degrades performance considerably.

But I am waiting for the Rust-OS to complete -- if one is under construction now. We can check how that stands when released.

> Huge. Only checking array bounds on every access degrades performance considerably.

Citation needed, since all evidence points to the contrary.

Could you please point us to a Rust application (there are hundreds of thousands at this point) that gets noticeably faster when disabling bound checks?

In servo, a whole web browser written in Rust, the cost of doing this was negligible, to the point that it was barely measurable (1-3%, noise levels for such a big app).

Same for Firefox which has a substantial amount of Rust.

Go ahead and give Fuchsia a try. You can enable bound checks for a substantial part of Android's user space and not really notice it.

Same for Redox, or any operating system kernel written in Rust.

You have many large applications to choose from, so please, just point us to 1 for which this is the case.

---

Compared with other mitigations already in the kernel, that can cost you up to 50% perf, and that people seem to be ok with, bound checking all the array accesses seems like a no brainer, given that ~70% of CVE are caused by memory issues.

When most people think about bound checking all array accesses, they think, for some "i can only think inside the box" reason, that this happens on hardware, for every memory access.

But that is not how Rust works. Rust adds bound checks "in Rust", and the Rust compiler and LLVM are really good at removing duplicates, hoisting many bound checks out of a loop into a single bound check at the beginning of the loop, etc.

People also think that this is an all or nothing approach, but Rust allows you to manually access without bound checks and do the hoisting manually. So if you find a function in which this makes a big difference, you can just fix the performance issue there manually.

For the optimisation, the compiler will even reason that e.g. iterating over the vector necessarily involves knowing the size of the vector and stopping before the end, so it doesn't need to add the bounds check at all because that's redundant. This is easier in Rust because the compiler knows nobody else can be mutating this vector while you're iterating over it - that's forbidden in the language.

So, in general, the idiomatic Rust "twiddle all these doodads" compiles to the same machine code as the idiomatic C++ for that problem, even though Rust bounds checked it and C++ didn't care. Lots of Rust checks are like this, they compile away to nothing, so long as what you did is necessarily correct. The Option<NonZeroU64> stuff a few days ago is another example. Same machine code as a C++ long integer using zero as a signal value, but with type safety.

Same applies when using C++ with bounds checking enabled, but the FUD regarding bounds checking is deep.

What happens about mutation in the C++ case though? Maybe I should just try it in Godbolt instead of bothering people on HN.

What mutation?

Naturally this only kind of works when everyone on the team goes safety first.

Doing some C style coding will just bork it, similarly to any unsafe block or FFI call in other better suited languages.

But in the subject of making juice with lemons, is way better than plain C.

Right, so long as there isn't mutation, we're golden, which is why the machine code is the same.

This is, after all, why Godbolt was first invented as I suspect you know (Matt Godbolt wondered if C++ iterators really do produce the same machine code as a hand-rolled C-style for loop, and rather than just trust an expert he built the earliest Compiler Explorer to show that yes, with real C++ code you get the same machine code, any time spent hand-rolling such loops is time wasted)

Yeah, but since there are domains where C++ is unavoidable, this is the best we can do.

By the way, this should be a nice update about the state of affairs on Android (I am yet to watch it).

"Improving Memory Safety in Android 12 Using MTE"

https://devsummit.arm.com/en/sessions/57

I don't understand what you mean by "domains where C++ is unavoidable" in this context. C++ is a choice, presumably usually a reasonable choice, but a choice, so if they wanted to people could avoid it.

Memory tagging (which is what MTE is about) reminds me of ASLR and password entropy requirements. They're slightly raising the bar which is not something I have much time for. I prefer to put the effort in to solve problems permanently so I can worry about something else instead. Whether that's a practical opportunity here is unclear though, and I think Rust is a big part of finding out.

I did once have a bizarre situation where removing a bounds check that always succeeded degraded performance by over 30%.

The bounds check wasn't being elided either. I checked and it was there in the assembly, so I figured that the function is so hot that an unchecked access might help things. Apparently not. The only thing I can think of is that the reduction in code-size for that function had an unintended effect elsewhere, either for the optimizer or that it resulted in a hot bit of code crossing a cache line?

Or the always succeeding check helped CPU's branch predictor substantially.

I have used C++ since 1993 with bounds checking enabled, it hardly has ever mattered.

The very few cases where it actually mattered for project delivery acceptance, were proven with a profiler, and fixed on those single cases only.

Most of the time it is just cargo cult taken from C into other languages.

Multics had a better DoD security profile assessment than UNIX, thanks to PL/I being bounds checked by default.

Mac OS used Object Pascal until they decided to switch to C++ around 1992, it also hardly impacted their sales, using a language with bounds checking.

> Huge. Only checking array bounds on every access degrades performance considerably.

I have not found this, at least in application code. There is usually at most a few percent different between v[i] and v.at(i) (the latter checks bounds) with C++ std::vector, for example. So I almost always use .at() these days, and it does catch bugs.

Well, there is the rub. The safe thing to do is more verbose, the unsafe way is in muscle memory. Rust did it the other way around deliberately. But that is easy if you do a new design and don't need to retrofit a safe solution. No snark intended.

That is why one should always enable the compiler switches that turn operator[]() into at(), and then only disable them on case by case scenario, if proven worthwhile to do so.

wouldn't compiling with _GLIBCXX_ASSERTIONS or the corresponding for your compiler of choice be a better solution? It will also catch quite a few more issues (dereferencing null smart pointers, empty optionals, etc.), while being still relatively lightweight.

Thanks, I didn't know (or didn't remember) about this, but it's not clear from the docs that it bounds checks []. I don't find it difficult to use .at(). I'll try the debug mode too, but when I bother writing something in C++ it's usually because I actually care about its speed, so I don't want the overhead to be too bad.

https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros...

Not the OP, that is my approach, keep on the bounds checking settings from VC++ also in release builds.

And before STL was a thing, all the custom types I had were bounds checked by default.

AFAIK RedoxOS has been bootable for a while now. (Though, a very simple new OS)

https://www.redox-os.org/

To be honest, the article makes much more nuanced suggestions to avoid these kind of bugs. I am not sure Rust would even have helped here, since the cause seemed to be a race condition because of an invalid lock being used. It might have been possible to avoid in Rust with an RwLock, but in this case that was also the fix for the original bug (using the correct lock). I have only looked into this bug report semi-thoroughly however, so I might be mistaken.

I was typing a comment about how Rust wouldn't have made a difference for the race condition, but after reading through it again to be sure i'm now on the side that Rust would have errored on the original bug.

  spin_lock_irq(&tty->ctrl_lock);
  put_pid(real_tty->pgrp);
  real_tty->pgrp = get_pid(pgrp);
  spin_unlock_irq(&tty->ctrl_lock);

rustifying this would be

  let mut tty_lock = tty.ctrl_lock();
  put_pid(real_tty);
  real_tty.pgrp = get_pid(pgrp);
  std::mem::drop(tty_lock);

Which would give an error that you are not allowed to mutate real_tty.pgrp.

The problem was that one of two threads locked the wrong lock before accessing a shared resource (when two threads read or write shared memory, both sides must acquire mutexes or it's useless), resulting in a data race.

Rust could prevent this issue by requiring that all non-exclusive accesses to the shared data acquire the mutex (and if you use Mutex<T> which wraps the data, you'll always acquire the right mutex). The & vs. &mut system can model exclusive access ("initialization/destruction functions that have exclusive access to the entire object and can access members without locking"). It doesn't help with RCU vs. refcounted references, or "non-RCU members are exclusively owned by thread performing teardown" or "RCU callback pending, non-RCU members are uninitialized" or "exclusive access to RCU-protected members granted to thread performing teardown, other members are uninitialized". And Rust is worse than C at working with uninitialized memory (Rust not using the same type for initialized vs. uninitialized memory/references is a feature, but uninitialized memory references are too awkward IMO).

I shared this perspective, but luckily my job is awesome and (in a routine 1:1!) Paul told me why it's less straightforward than I thought: https://paulmck.livejournal.com/62436.html

my takeaway was essentially that you get sweet perf wins from semantics that are hard to replicate with a type system that's also making really strong guarantees without making the code SUPER gross.

Seriously, this comment and similar comments is why I'm pretty much convinced that Rust will be booted from the Linux kernel altogether.

If enough people want it, it will happen.

Reply on news.ycombinator.com