> a rewrite for the sake of safety is not sufficient imo
I would disagree; I think a rewrite for the sake of safety, especially when we are talking about a piece of server software that deals with untrusted clients, is often worth it.
Certainly it isn't always: rewriting huge, complex pieces of software for the sake of anything (including safety) may just not be justifiable. Like, sure, maybe the Linux kernel would benefit from a rewrite in Rust, but I don't think that would be a good idea.
NTP is a fairly small protocol, and at least the server portion -- where I'd be the most worried about memory safety issues -- can be implemented in Rust without too much difficulty. As I understand it, NTP clients can be a bit more complicated. But I still expect they're much less complicated than many other types of clients.
> Are they going to maintain that forever and push Linux distro and the industry to move to that new solution?
Why not? That's how open source Linux software works. Someone builds it, and if there's enough interest, it gets adopted, and attracts new contributors and maintainers over time. If there isn't enough interest, it withers away.
That may not be your idea of the best use of your time (and I might agree), but who are we to tell others what to do with their time?
They are justifying the rewrite by saying that it is memory safe.
I don’t think its a bad goal but if they don’t do the work to maintain and package these for distros it wont make it very far.
However im always surprised by how many people are fanatics of rust and they do contribute a lot to packaging at least for Gentoo which is my daily driver. I could see a lot of these taking off if it does show a reduction in attack surface and it works seamlessly as a replacement for existing solutions hopefully not forcing a new config on everyone.
Doesn't Rust just panic and abort on runtime memory errors?
So, we maybe get memory security, but we seemingly do nothing for DoS. Isn't that a large attack vector for NTP, given it's primary utility in other protocols?
Rust the language doesn’t know anything about heap allocation, so in a strict sense, no.
The standard library provides a number of APIs that abort on allocation failures, yes. There are currently nightly-only APIs for some of them to return Result instead, and they’ll hit stable eventually. You could also not use them if you don’t want that behavior.
No, rust avoids most memory errors by proving at compile time that they don't exist. That's why it forces you to write code with lifetime annotations and such, so that thst proof becomes feasible.
I say "most" because it also allows you to get out the footguns, meaning you can sidestep this proof mechanism. But you do that by declaring a block/function as "unsafe", so if you do find a memory bug, you know exactly where to start your search.
That's right, DoS in Rust is still a thing you can have. But it's no worse than in memory unsafe languages, since memory unsafety can also lead to DoS (and in a much worse way - there are methods for managing panics, managing segfaults is much harder).
> Doesn't Rust just panic and abort on runtime memory errors?
Technically yes if you directly access an index that's OOB but stuff like Vecs and Arrays have the get and get_mut methods which allows you to try to retrieve an element (or slice). If the element is in bounds you get a Some<T> with a reference to the element (or slice) and if it fails it'll return an Error type which can be handled rather than panicking out.
It's not even slower to use the .get method rather than direct indexes because attempts to access indexes directly are implemented as .get.unwrap()
NTP takes in untrusted input from the net, does complex processing on it, and requires the ability to do something administrative on your system (adjust the time).
This gives NTP a lot of attack surface and makes it a likely vector for compromise.
Rewriting NTP in any language safer than C/C++ is likely to be a good idea.
That drives home the point that NTP would likely benefit from privilege separation too. One component talks to the network, another component adjusts time. Second component would enforce gradual skewing only. (Or a time jump once in early boot, per policy. And it could enforce the max size of that jump too, implement a policy where the machine boots into repair mode if it was more than 5 minutes off the desired time, etc.)
A very simple one-way data channel between the components would make attacking the second component near impossible.
With that, and an attacker that completely pwns component 1: At worst they could start a very gradual skew, which could then be picked up by monitoring before it causes much of an issue.
There's no reason to believe there isn't some vulnerability lurking in chrony, which is a highly privileged process. These are exactly the starting points I would hope for.
On the other hand, the statement that they did not study chrony because they couldn't understand it does not exactly fill me with confidence.
To be fair, chrony, at least on my system, is not running as root. I'm not sure what mechanism it uses to set the system time, whether it's capabilities, or a setuid helper program, but I think it's safe to assume that, if compromised, the only malicious thing that it could do would be to set my system time to something incorrect. Which isn't nothing, but also isn't much, either.
