Rust in the Linux kernel (Google security blog)

smrtptr.get() is a thing. As long as that is callable and not banned via static analysis, you lose the lifetime "encapsulation" the smart pointers are supposed to provide. Unfortunately, `std::optional<T&>` is busted in C++ and is supposed to either be spelled `std::optional<std::reference_wrapper<T>>` or T*. Guess which one everyone is going to use?

OK. This looks as if it should work. Not exactly what I call beautiful code. Probably unavoidable if one wants to stay compatible with old code.

> > What is with the reverse problem, the object goes out of scope while the pointer is still there. How is this handled?
> This shouldn't happen. Your smart pointer should encapsulate the ownership.

How does this work if the object is on the stack? Or is this not allowed to use pointers to objects on the stack?

Or if I have a composite object, how can I create a smart pointer to a sub-object, e.g. to pass it in a function call? Probably this can be done with reference counted pointers, but reference counting has a runtime overhead. In rust one can simply create a pointer to a sub-object and use it. Of course this is only allowed if it is clear by scope that the object always outlives the pointer to the sub-object. And this works without any runtime overhead. The compiler will verify at runtime that the lifetimes work out (or throw an error).

No, you take a reference. Raw pointers always have `nullptr` which is a valid value. References do not (unless one has already performed UB).

> For example, let's consider the code below (when exceptions aren't used): (snipped)

`new` never returns `nullptr`. It throws an exception. Freestanding might change that, but that's not standard (yet).

> That was my point when I have said that:
> > Rust memory safety is no longer guaranteed when the code calls an unsafe function. Which is pretty much every kernel API right now.

The thing is that *all* of the C++ code is unsafe and needs auditing. Rust needs auditing at the boundaries of unsafe blocks. A *much* more doable task. unsafe blocks are not "I get to do whatever I want". They are "I am doing something I know is safe, but I cannot convince the compiler of that". One can still get it wrong, but, again, the review burden is *way* lower.

What are the core C++ language constructs for memory safe code?

> Kernel implementation is free to implement its own templates here.
> > What is with the reverse problem, the object goes out of scope while the pointer is still there.
> > How does this work if the object is on the stack? Or is this not allowed to use pointers to objects on the stack?
> Smart pointers manage dynamically allocated objects, like the ones allocated by kmalloc() or malloc() or operator new(),
> not the ones with automatic storage duration (that's the ones that are created on stack and destroyed when they go out of scope).

Then how is one supposed to use pointers to objects on the stack? This is no problem at all in rust. The compiler will check that the pointer does not outlife the stackframe.

> > I have a composite object, how can I create a smart pointer to a sub-object, e.g. to pass it in a function call?
> If the function never stores the pointer for use after it has returned then it should just accept a raw pointer.

How can a function that accepts a raw pointer be sure that the pointer points to valid data? This is inherently unsafe design.

> Otherwise, smart pointers are tied to the memory allocation / deallocation calls - if the composite object is deallocated as one object that it should be managed by one smart pointer.
> If it consists of multiple allocations for subobjects then it might make sense to manage them separately.

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.

> > How is one supposed to create a smart pointer without relating to unsafe code?
> I totally disagree that code should not have any raw pointers.
> Smart pointers & co. are just tools for writing better and safer code.
> They do not need to be used where there is close to zero possibility of making a mistake (they have a cost, too).
> For example, let's consider the code below (when exceptions aren't used):
> > Foo *foo = new Foo;
> > if (!foo)
> > return false;
> > foo->action(bar);
> > delete foo;

So this code is memory safe because you verified it to be memory safe. This is not the idea of memory safe languages. 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. And usually programmers are overconfident in producing correct code. So you will end up with programmers using unsafe raw pointers and memory safety violations. And these programmers will say, this code is obviously safe. There is no need for smart pointers, just like you just did with this example code. If you leave it up to the programmers whether they use the safety features, then bugs are inevitable.

> I don't see a point of introducing a wrapper for "foo" here - even when the compiler is smart enough to optimize it out it is still a compile time cost.

And a compile time cost is fine. This compile time cost is just checking that the programmer did not make a mistake. And this check should be there because programmers (like all humans) are fallible.

> > Are there any implicit checks that throw a compile time error if I initialize a smart pointer with a possibly invalid pointer?
> How do you define a "possibly invalid pointer"?

Any pointer where the compiler cannot verify at compile time that it points to valid data. Such accesses should be avoided if possible. Otherwise they have to be clearly tagged.

> If raw pointers are disallowed then how do you access, for example, MMIO registers at constant memory address?
> Pointers to these by definition aren't given out by an allocation function.

This is one of the few things where a raw pointer will be necessary. Accesses to this pointers should get a safe abstraction. Then you will only have a few lines that have to be verified by humans.

> After all, we are talking about reducing the number of (accidental) bugs here, not combating actively malicious behavior.

In rust, the goals are much more than that. You want to directly see where the critical code is that can possibly invalidate your memory safety assumptions. All such code has to be flagged. And should be extensively documented.

> > These are safe to use as long as the underlying C-code has no bugs.
> > Of course, if there a bugs in the C-code then all bets are off, regardless of which language calls into the code.
> That was my point when I have said that:
> > Rust memory safety is no longer guaranteed when the code calls an unsafe function. Which is pretty much every kernel API right now.

You probably did not get the point, why a memory safe language is introduced to the kernel. Of course, the kernel will not be magically memory safe if 0.1% of the code is rust. The point is that the new code, i.e., the code written in rust, cannot introduce any new memory safety bugs. The wrappers to call C-code are very small. These are safe functions that do an unsafe call. The meaning is: the person who implemented the wrapper has verified the wrapper to be correct. These functions are usually just a few lines. The rust code using the wrappers can then be implemented in safe rust, i.e., without using the unsafe keyword. Thus all this code cannot on its own introduce memory safety violations. This is very different with C++, where there are no checks at all that the code is memory safe. In C++ you just have some aids that make it a bit less likely that the programmer does an error. In safe rust this is verified.

> And due to, for example, the above thing about register access, you'll eventually end up calling some unsafe function.

Yes, eventually. The function doing the actual register access will usually have just a few lines. All you have to do to ensure memory safety is verify the correctness of these few lines. It does not matter at all what happens outside of this function that does the actual access and provides a safe interface to the outside world.

> > The tagging (with unsafe keyword) is enforced by the compiler. If you do not tag, this is a compile time error.
> So the compiler enforcement is kind of all-or-nothing: either the function is untagged and it is 100% safe or the function is tagged and it is unsafe.
> It would be better if it actually checked more specific requirements for the input or output parameters (something sparse and other checkers currently do).

What usually is done is to create a function doing a safe abstraction. All requirements of this function are checked. Inside the function there will be an unsafe keyword, which wraps the part of the code the compiler cannot verify to be correct. These code has to be manually verified. And of course you are free to also use checkers for this. All accesses to the safe interface are verified by the compiler to be memory safe.

> > Dereferencing a standard C pointer obviously has to count as unsafe code.
> As I wrote above, you will never escape the necessity of having raw pointers and using them where they are cleanly unnecessary has some costs.

There are only very few places where raw pointers are needed. In the kernel, there might be a few more than in normal user space code. And just using raw pointers everywhere in the code because you would loose a fraction of second in compile time cannot be the answer. If this would be an excuse for using raw pointers, then we will always have memory safety bugs because most programmers do not see where the code gets to complex to be manually verified.

> > What the article says is that additionally to the tagging, there has to be extensive documentation specifying exactly when and why the interface is safe to use.
> > This is just good rust practice.
> That's great!
> It would definitely be a good C++ practice, too, to do so.

Yes, but totally infeasible. Your little example would already need documentation why it is safe to dereference a raw pointer. And if you would allow small portions of unsafe code without documentation, then people will start doing larger portions of unsafe code without documentation. Where is the border?

And I definitely do not buy your argument at all, that just because somewhere inside the code you need a small section of unsafe code, all the code is unsafe. There is a clear benefit that only these small sections need to be verified. In C or C++ it is totally impossible to verify the memory safety of the code. All code is possibly unsafe and therefore all code needs to be verified. There is no means to actually see where problems could be. In rust you will end up with just a tiny fraction of the code tagged as unsafe. You can easily find these with grep.

struct Wrapper{ Wrapped *obj;}
Wrapper* make_wrapped(Wrapped *some);

And there's always the issue of what kind of a pointer one should use inside the Wrapper object.