Yeah, one CVE is literally "You can use the MacOS variant of LD_PRELOAD on the client to hook libc calls! Oh no!!" This is a bogus CVE; any application can perform arbitrary actions when its system calls are hooked, but it requires such a strong threat model that the adversary realistically gains no ground by doing so.
("A code injection in Nextcloud Desktop Client for macOS allowed to load arbitrary code when starting the client with DYLD_INSERT_LIBRARIES set in the enviroment")
Yeah, it's strange to me that's a CVE. That seems like "working as intended" if I, the owner of the machine, want to load other libraries, why shouldn't it respect that?
He actually did mention it if you look at the blog post his quote comes from. He's specifically calling for a Linux-ABI-compatible rust kernel that just re-implements things as they were rather than trying to delve into new researchy OS concepts like what Redox does.
Writing a Linux-ABI-compatible kernel in Rust will lead to a kernel no one uses. What would be the advantage of such a kernel? It would be much, much slower for many workloads and only be interesting to Rust hackers. In "Linux the OS", we are stuck with the "Linux the kernel", and Drew knows this very well. You will never catch up with the years of development that went into it. So if you want Rust in the kernel of "Linux the OS", you need to get Rust into "Linux the kernel" proper. This approach can work, see for instance the history of PREEMPT-RT.
> This approach can work, see for instance the history of PREEMPT-RT.
Good point, I note that realtime preemption has been in the works for more than twenty years, but (surprisingly) still isn't in mainline. On the other hand it's widely used and available and has caused lots of changes upstream already.
PREEMPT-RT is almost completely in mainline. As your linked article says, pretty much the last issue is printk. You can download the last patch here, it's not much anymore:
Because if you write a kernel from scratch, things like the scheduler or the networking stack will be much, much less performant than the one from the Linux kernel. As I've written: you'll never catch up with the years and years of development that have poured into these systems.
Now, you could take these stacks from the Linux kernel and rewrite them in Rust, but that's not what Drew has suggested. Besides, that would also take ages: it's a lot of very complicated code, and a lot of it cannot just be transferred to Rust without it becoming unsafe, making the whole point of having a kernel in Rust moot.
> Because if you write a kernel from scratch, things like the scheduler or the networking stack will be much, much less performant than the one from the Linux kernel.
Yeah, I don't think you know this.
As I understand it, there have been schedulers written in Rust for Linux already which are faster in specific use cases.
> Now, you could take these stacks from the Linux kernel and rewrite them in Rust, but that's not what Drew has suggested.
As I understand it, Drew that's exactly what he suggested? He didn't say go write a new system. He said go write an ABI compatible system. It's hard for me to imagine he meant "Write an ABI compatible system with wildly different semantics."
> Besides, that would also take ages:
Agreed, and that's what makes his suggestion mostly ridiculous.
> it's a lot of very complicated code, and a lot of it cannot just be transferred to Rust without it becoming unsafe, making the whole point of having a kernel in Rust moot.
I think this passage confuses a few key concepts. First, I'm not really certain how much unsafe a scheduler or a networking stack would have to use. My guess is not that much. Do you have some reason to believe it would have to use an inordinate amount of unsafe? Next, simply using unsafe does not moot the safety argument for using Rust. I've said this about a billion times, but once more: unsafe constrains memory safety to a small enough area that one can reason about it.
Unfortunately, they also have plenty of low-quality venues that dilute the discoverability of the high-quality ones. Some orgs (Usenix for instance) hold to at least a decent standard across nearly all their research conferences, so I can better gauge the quality of a paper in a field I'm less familiar with based on whether it was accepted to a conference in that org. When it comes to IEEE, it seems like they'll let any low-quality journal or conference spring up with their brand as long as it brings in the cash.
("A code injection in Nextcloud Desktop Client for macOS allowed to load arbitrary code when starting the client with DYLD_INSERT_LIBRARIES set in the enviroment")