Too much kool-aid
Too much kool-aid
Posted Feb 12, 2025 20:42 UTC (Wed) by roc (subscriber, #30627)In reply to: Too much kool-aid by alx.manpages
Parent article: Maintainer opinions on Rust-for-Linux
Is this bait? There is ample real-world evidence to the contrary, too much to even cite here, but you can start by comparing the CVE record for rustls vs OpenSSL.
Mass-rewriting of C into Rust might introduce a few logic errors. It is likely to eliminate more, since Rust provides powerful tools for avoiding logic errors, newtypes and the Result type, that are infeasible in C. And if you choose Rust instead of C for new code (e.g. new kernel drivers), the logic error advantage of Rust is clear.
Posted Feb 12, 2025 21:12 UTC (Wed)
by alx.manpages (subscriber, #145117)
[Link] (11 responses)
I don't know what C dialect is used by OpenSSL, but I looked at a random file in their source code, and immediately identified some less-than-ideal patterns. Also, the language isn't enough; you also need to design non-error-prone APIs, which is something that no tool can help you with (at least not enough).
That Rust defaults to not allow certain things is nice. We should severely restrict what is allowed in modern dialects of C.
Here's the example of unsafe code I identified in OpenSSL:
<https://github.com/openssl/openssl/blob/6f3ada8a14233e76d...>
```
A better API (only implementable as a macro) would ask for a number of elements and a type:
```
Here's an example of such an API:
And here are the commits that added such an API, which document the kind of improvements it adds:
Posted Feb 12, 2025 21:43 UTC (Wed)
by mb (subscriber, #50428)
[Link] (1 responses)
Posted Feb 12, 2025 23:05 UTC (Wed)
by alx.manpages (subscriber, #145117)
[Link]
It is not, if you're asking that. I considered not responding, because your comment looked plausibly trolling, but I think I should respond, in case your comment was honest.
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Posted Feb 13, 2025 4:48 UTC (Thu)
by roc (subscriber, #30627)
[Link] (8 responses)
Rust helps with this because you have to encode ownership and thread-safety information in the API. E.g.
fn new_blagh(s: &str) -> Blagh
In the Rust API, unlike the C API:
And in Rust you can go much much further towards making APIs difficult to misuse. For just one example see how rustls's API prevents certain kinds of configuration errors: https://docs.rs/rustls/latest/rustls/struct.ConfigBuilder...
Posted Feb 13, 2025 10:15 UTC (Thu)
by alx.manpages (subscriber, #145117)
[Link] (7 responses)
I only work with single-threaded projects at the moment. That aspect is not very appealing to me at the moment.
> * The callee can be sure that it is not responsible for freeing `s`
Consistent use of the [[gnu::malloc(free)]] attribute can help with that too.
---
Look, Rust does have very good ideas. I don't claim it doesn't. But:
- You can improve your C code's safety significantly just by designing good APIs and self-limiting to a subset of the language.
- As a longer-term goal, you can probably add those Rust features to C.
In the end, a safe language is a language that prevents you from accidentally granting rights to an attacker.
You may call it luck, but I have been refactoring shadow-utils at a very high rate (including complaints by packagers that were worried that such rate of churn would introduce security vulnerabilities almost certainly) for quite a few years already. So far, I have introduced 0 remote holes in a heck of a long time (at least, for what we know). The code is now significantly safer than it was before I started. The more I refactor it, the safer I feel when doing so. You just need to follow some rules, and at least you'll have a hard time introducing a vulnerability. It's not impossible, but it's all a compromise.
I know the language so damn well that that offsets the theoretical benefits that Rust could give me. People talk their mother tongue better, even if it's significantly more complex than other languages, because they know it by heart. They say Norwegian is similar to English but simpler (and thus easier), but we speak English because we already know it. Would it be better if there was a big-bang change in the world to make Norwegian the global language? Maybe it would help learners in the long term, but we'll agree that it's not a good idea. The same holds for Rust and C, IMO.
Plus, for a setuid-root set of programs (which is what I'm mainly working on at the moment, apart from the Linux man-pages project), a logic error is as bad as a buffer overflow. If I toggle a conditional and grant root privileges to a random user in su(1), I've screwed as badly as if I would have caused the worst UB. That also diminishes the reasons for using Rust, _in my case_.
Posted Feb 14, 2025 23:33 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (6 responses)
I hope your projects survive you moving on. Projects using arcane knowledge to hold themselves up are at risk of becoming like one of the `roff` implementations (`nroff`?): inscrutable to even the other Unix prophets so as to be left alone after the original author's untimely end[1].
[1] At least if my memory of a BSD podcast which interviewed Bryan Cantrill where it was mentioned is accurate.
Posted Feb 14, 2025 23:45 UTC (Fri)
by alx.manpages (subscriber, #145117)
[Link]
That's a valid concern. I try to educate the other co-maintainers and regular contributors on those matters. But I should be more careful on that effort, just in case.
Posted Feb 15, 2025 23:40 UTC (Sat)
by mirabilos (subscriber, #84359)
[Link] (4 responses)
J�rg Schilling (rip.) also used to maintain a fork, similarily.
Posted Feb 17, 2025 7:32 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Here's the source of my claim as well: https://www.youtube.com/watch?v=l6XQUciI-Sc&t=5315s
Posted Feb 17, 2025 21:23 UTC (Mon)
by mirabilos (subscriber, #84359)
[Link] (2 responses)
No, we’re talking about the 32V-based one.
Posted Feb 17, 2025 21:55 UTC (Mon)
by excors (subscriber, #95769)
[Link] (1 responses)
Posted Feb 17, 2025 22:42 UTC (Mon)
by mirabilos (subscriber, #84359)
[Link]
Too much kool-aid
ret = OPENSSL_zalloc(sizeof(*ret))
```
ret = XXX_ZALLOC(1, OSSL_COMP_CERT);
```
<https://github.com/shadow-maint/shadow/blob/master/lib/al...>
<https://github.com/shadow-maint/shadow/commit/6e58c127525...>
<https://github.com/shadow-maint/shadow/commit/09775d3718d...>
Too much kool-aid
No, you're not talking to a random text generator
Too much kool-aid
vs
Blagh new_blagh(char* s);
* The callee can be sure that `s` won't be modified by another thread while `foo` is running
* The callee can be sure that it is not responsible for freeing `s`
* The callee understands that if `Blagh` contains part of `s` then it needs to copy that data into `Blagh`
* The caller can be sure that the returned object does not depend on `s` being kept alive
* The caller can be sure that it retains ownership of `s`
* The caller can be sure that it has exclusive ownership of `Blagh`, i.e. nothing depends on it keeping `Blagh` alive
Of course Rust not only forces you to write these critical properties into the code, it also checks that the caller and callee maintain them.
Too much kool-aid
Too much kool-aid
C arcange knowledge, bus factor
Too much kool-aid
Too much kool-aid
Too much kool-aid
https://mbsd.evolvis.org/cvs.cgi/src/usr.bin/oldroff/nroff/ still shows some of the horrors.
Too much kool-aid
Too much kool-aid