Hacker News Reader

Having third party crates in ring 0 is kind of terrifiying when you think about supply chain attacks...

So few people actually do their development/testing in truly-sandboxed environments that I don't think that there's actually much of a difference in practice between malicious code running in userspace vs malicious running in kernelspace ( https://xkcd.com/1200/ ). Of course, I'd love if sandboxed dev environments became more usable and widespread.

I would never expect them to do that without vendoring the package. Which mitigates that risk.

They don't use cargo.

I expect it to be possible in near future that you develop, say, a web server in Rust in userspace, and with a few changes run it in kernelspace, with improved performance.

We already have eBPF.

io_uring too

Running things in kernel space doesn't make them faster.

It can absolutely make things faster. If your program is running on data that exists in the kernel you don't need to copy it over to userland/ perform expensive context switching.

It can make things faster is not the same as simply running it in the kernel will make it faster. There are definitely certain situations that making use of fewer context switches helps with, and where page mapping isn't sufficient, but if you just write an entire user-space web server, then just compile it as a kernel module, expecting it to see a notable performance improvement, you're going to be disappointed.

edit to clarify: the reason it won't help (much) is because most of the things it would help with have already been optimized via features like CoW pages, the VDSO, sendfile, etc.

Web server sounds like exactly the kind of workload that will benefit from moving to the kernel.

https://en.wikipedia.org/wiki/In-kernel_web_server

Yeah, unikernels try to exploit the benefits as well.

Would that really give a sizable benefit over, say async IO? Especially an “automatic” one like Java’s Loom?

Yes, it can still have significant benefits. Async IO is an attempt to get around the performance issues and, given lots of kernel support that largely does not exist today, it can bridge the gap to a degree, but it's never going to match just avoiding the entire issue.

You can use things like XDP to get a lot of performance back but 0 context switches/ 0 copies is always going to be faster.

Not a kernel hacker, but if it's just for fun, I don't know if you'd need to limit yourself to no_std crates. Allocation is supported (if it wasn't, then Rust's stdlib wouldn't be adding fallible allocation APIs to support the kernel usecase (and even if crates in the wild aren't using these APIs and abort on OOM, again, this is just for fun)). Meanwhile, I feel like OS-specific stuff performed by libstd (e.g. threads, networking) must surely be supportable somehow, since the OS is right there and all its facilities still exist, even if you might need to adjust codegen to account for the difference between kernelspace and userspace (I assume you would need to compile against a specific target?).

Although Rust for Linux has its own alloc, that isn't really alloc. It is like if you wanted Coke and got Pepsi, if you just wanted fizzy brown beverage you're fine, but if you actually cared this isn't OK.

Rust's String (the mutable owned string type from alloc) implements AddAssign meaning you can write fname += ".txt" and that works, but Rust for Linux doesn't allow that. This is just a really obvious example, there are many other differences

You can't use methods that may panic on OOM like Vec::push or Box::new. This means that close to 100% of crates that use the stdlib won't be usable in the kernel without modifications.

My understanding isn't that you _can't_, but that you _aren't allowed to_ by kernel policy. (The risk being that the kernel will panic on OOM, which is not an acceptable way for the kernel to deal with OOM conditions.)

If this is out of tree, AFAIK you can use these all you want. Whether or not you _should_ is obviously a different matter.

No, you can't - they don't exist in Rust for Linux.

In Rust the alloc library's Vec has a function Vec::push(&mut self, value: T)

https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pus...

In Rust for Linux their custom alloc library does not have that function offering instead Vec::try_push(&mut self, value: T) -> Result<(), TryReserveError>

https://rust-for-linux.github.io/docs/alloc/vec/struct.Vec.h...

What’s up with the Allocator API? Then it could be Vec::push<Allocator>(..), giving it an always-failing one for example.

Vec::push<Allocator>(..) makes no sense, the Allocator is a parameter to the Vec type.

That’s what I meant to write

OK and... ? What purpose does an always-failing allocator for Vec have? I guess maybe it's useful for some unit testing cases, but otherwise it seems pointless.

> I wonder how hard it would be to bring in external no-std crates

Wasn't this a thing that would not happen at all? at least that is what I remember from previous discussions. Another question would be how do you avoid an explosion of crates with different versions for each module.

Policy decisions for linux itself don't (necessarily) apply out-of-tree modules?

This is more a question of policy than mechanism - I'd imagine at least a provisional policy is in place, but the only to be found somewhere in the relevant kernel mailing lists.

although it never really sacrifices any control.

It feels like it sacrifices control wrt when you allocate and free-memory.

I understand it's deterministic in rust, but it's not explicitly controllable - or at least I've seen it be.

You have to bring your own memory in no-std. Implicit alloc is provided by the alloc crate (part of std).

I don’t follow. It’s exactly like C in this regard, except with Box::new instead of malloc.

The key difference as outlined in the article is that Box::new cannot fail in Rust, but the underlying malloc can.

In userspace it is rare enough that a Rust panic is considered acceptable behavior, but this is not the case for the kernel.

But, it is controllable for sure

Unsurprisingly the kernel's Box does not have Box::new it provides instead Box::try_new which is fallible.

Rust is a manual memory managed language, it literally has nothing inexpressible that C could do. Hell, C is a “higher level” language in that it doesn’t have any way for SIMD instructions.

To add something concrete, you can manually free memory as well based on some dynamic property if you wish.

if I was curious, what would be a couple of the good complexities?

Not the OP, but I would assume that necessary complexity is at least where the complexity mirrors whatever real world complexity it is implementing, thinking particularly of protocol stacks like usb, networking, etc.

Depends on what kind of problems you you find interesting, but since it's so close to the metal, and since people want their kernel to be fast, there tends to be a lot of clever algorithms, intricate locking, architecture-specific considerations, dealing with the hardware, all sorts of pretty interesting things you wouldn't usually find in regular business logic.

Take filesystem code for example. It can sound like a conceptually simple and well trodden topic, but if you try writing one there's a pretty large design space and tons of interesting problems to try to solve. And then because of concurrency and the need for performance, there can be very intricate locking to the point it can be challenging to hold the whole model in your head all at once (you can have truncates, writes, mmap, all sorts of very different operations in flight in parallel that interract in funny ways).

Or memory models. Reading memory-barriers.txt is a lesson in humility, I believe you can count on your fingers and toes the number of people in this world who can truly claim intimate familiarity with all the corner-cases and details implied by the model in that little text file =)

But take practically any big subsystem of the kernel, and there tends to be plenty of interesting domain-specific problems and challenges.

I believe they're referring to the essential complexity of the domain. An operating system has some "lower bound" on how complex it can be, which is rather high.

But some stuff doesn't _have_ to be hard. Like OP said, there's no inherent reason for error messages and failures to be cryptic or documentation to be sparse. The system could be more transparent or modular, easier to debug/analyze, etc.

I think there's an example in GCC vs Clang here, but I'm not qualified to comment.