Rust in the Linux kernel (Google security blog)

> > How can a function that accepts a raw pointer be sure that the pointer points to valid data? This is inherently unsafe design.
> It's the caller responsibility to not provide any invalid pointers to the function.
Of course it is. And it should be the the compilers responsibility to check this. However, this si impossible with raw pointers. It is not even clear from the function signature whether a null pointer is correct or not. In some functions this is fine and has a semantics, in others it is not. This is what I mean by inherently unsafe, the compiler cannot check correctness. Every such function call would need a documentation why it is safe to do.

> > No, I am talking about a big object managed by one pointer, but now I want to pass a pointer to a subobject to some function.
> > In rust, I can just take a pointer to the subobject, as long as the lifetime of the pointer to the subobject is contained in the lifetime of the whole object.
> It depends what do you specifically mean by a subobject.
> If it's like a class field then normally one does not provide a direct pointer to the field to an unrelated code but implements a specific interface and provides it instead.

So, one is not supposed to use getters for fields of an object?

> > How complex should code be such that you think that one should actually verify correctness?
> > People will disagree about the complexity that can be checked by humans.
> There is no "scientifically-correct" answer to that question, since it's mostly an individual opinion.
> One can simply identify obviously-correct code (like in my example) and treat any disagreement over this as an evidence that the code is not obviously-correct.

And rust has a pretty clear opinion on this. A dereference of a raw pointer is never obviously correct. This rather hard judgement can of course not work in C++. According to rust standards almost every line in C++ is not obviously correct.

> > Then you will only have a few lines that have to be verified by humans.
> "A few lines" of unsafe code in an OS kernel?
> Even the current C code in Linux kernel is not standard-complaint and that's already a rather low bar...
> And this is done for a reason (performance).

Of course, in the kernel it will be a few lines more. Still it would be way way less than with C or C++-code. Most of the Kernel can be written in safe rust. It are mostly the low level primitives that would need unsafe code. Calling these primitives can be safe code. Today all of the Kernel code is unsafe code.