Systemd Loves Rust

amutable.com

15 points·birdculture··5 comments

.... i can understand being like .... proactive. But maybe the failable allocations thing leading to writing your own allocator is premature? idk ...

it's one of the core parts of the security model....

i would hope because there's such strict controls in rust for memory management that you wouldn't have the possibility for allocation fails to begin with? idk ?

if it's a low memory situation, i think there's other ways to handle this ... but i can understand not wanting anything to change other than the language.

but maybe it's something that gets better?

Then Rust could not be any part of the init executable. A failed allocation would be a kernel panic.

Since 2017 rust has had a way to throw and error and you can handle the error instead of panic.

https://github.com/rust-lang/rust/issues/46865

Couple of other ways to do it too.

That being said if you have to go this route maybe the article is oversimplifying the decision?

Another benefit might be not having to deal with all the baggage std lib brings that you don’t use and all the resultant cves?

> Static linking for a project like systemd that is split into many tiny components (> 180 binaries currently) is simply not practical or desirable.

It's pretty easy to do this though isn't it? Just have a single binary and switch on argv[0]. Busybox has been doing that for literally decades.

That model is utter garbage for many reasons, for example every single ROP-style attack now has access to the entire codebase, instead of just what is part of the individual, tiny binary. Another example, it makes it pretty much impossible to restrict access to the discrete binaries via LSMs. And so on, and so forth.

Reply on news.ycombinator.com