[flagged]
It's difficult to say if a kernel written in rust would not have similar vulnerabilites, because it would be impossible to build a kernel without significant amounts of `unsafe`.
OpenBSD has a use-after-free allowing local privilege escalation to root
41–50 of 170 posts
Re: OpenBSD has a use-after-free allowing local privilege escalation to root
#42[flagged]
The OpenBSD project was started in 1995, with ancestry going back further than that. Should they have first invented Rust? Or at what point do you suppose the decades-old codebase should have been completely rewritten?
It's not too late to start now, similar to how Linux did a few years back.
Re: OpenBSD has a use-after-free allowing local privilege escalation to root
#43Earlier quoted context omitted.
Or Linux development is significantly more active.
This is an external audit. Why would Linux activity make a difference here? Are you theorizing that the churn causes bugs?
Linux is a much larger project receiving changes to tons of systems from lots of different sources. The combined behaviour of those things working together is massively harder to understand and test.
Copyfail being introduced by an optimization made to some random crypto module is a good example of this.
Re: OpenBSD has a use-after-free allowing local privilege escalation to root
#44Earlier quoted context omitted.
Or Linux development is significantly more active.
This is an external audit. Why would Linux activity make a difference here? Are you theorizing that the churn causes bugs?
> Are you theorizing that the churn causes bugs?
Seems to be the case.
How many times do you see a bug investigation and it's determined when the bug was introduced?
Do you ever look at the diff that introduced it to understand what was going on in the project at the time? Often, it's in service to a new feature. Sometimes the original change is questionable when you consider you traded it for a severe bug.
Re: OpenBSD has a use-after-free allowing local privilege escalation to root
#45Would Rust have made this issue impossible by construction? I know Linus has spoken about Rust's promises about memory safety not being equivalently applicable in the kernel domain, so I would be curious to hear any kernel developer's perspectives.
I'm not a kernel developer but I am an embedded firmware engineer.
To be clear: I like Rust. It's great, I use it a lot. But, Rust's memory safety stuff can't really save you from the screwiness of ISRs. Here's a long-winded example:
ST has a nifty double-buffer DMA mode for their ADCs, so you can give the ADC two different buffers, it'll fill one, fire an IRQ, you catch the IRQ and handle the data, meanwhile, it's filling the other buffer, and the IRQ fires again, you handle the data in the other buffer, rinse, repeat.
This allows the ADC to run continuously, monotonically and at very high sample rates, without monopolizing CPU. It's really a terrific design. I used it for a DIY telephony project once to run continuous FFTs on several ADC channels at once.
This is all fun, but the architecture introduces synchronization issues that aren't immediately solvable within Rust's data model.
Okay, so I can't run the FFT from within the ISR, so I delegate that to a thread. Do I have the thread read the DMA buffer directly, and just pray that it does it fast enough that the ADC doesn't loop back around to that buffer until the thread is done?
Or, do I have the ISR copy the buffer into a queue, mitigating the memory corruption risk? Well that seems good, but how do I make the queue visible to both the ISR and the thread? The ISR takes no arguments, it's just an address the CPU jumps to when a thing happens. Thus, the queue has to be global, which means more unsafe blocks and more very un-idiomatic Rust.
side note: in my use case, it actually worked just fine with the thread reading straight from the DMA buffer, even with the risk of memory corruption. But you can imagine use cases where the risk would be more severe, like maybe decoding packets from a serial interface.
Re: OpenBSD has a use-after-free allowing local privilege escalation to root
#46Earlier quoted context omitted.
The OpenBSD project was started in 1995, with ancestry going back further than that. Should they have first invented Rust? Or at what point do you suppose the decades-old codebase should have been completely rewritten?
It's not too late to start now, similar to how Linux did a few years back.
Rumours of Linux being rewritten in Rust are greatly exaggerated.
Re: OpenBSD has a use-after-free allowing local privilege escalation to root
#47OpenBSD's security stance being the stuff of legend, I'm curious how many vulns have been found over the last couple months while the big model companies are flaunting their ability to find exploits. It'd be super cool to see it remain tiny.
According to https://openai.com/index/patch-the-planet/ Linux: 24 LPEs, plus many additional vulnerabilities. OpenBSD: 1 LPE. FreeBSD: 7 LPEs, plus many additional vulnerabilities. Not sure what that says, though. Perhaps the models are more likely to find Linux issues because of the training.
It is quite possible that Linux is the bigger target so it gets more focus. Vulnerabilities there are generally considered more valuable and notable. It would be very difficult to use these numbers to get a meaningful "more secure" stance as there are tons of variables.
Re: OpenBSD has a use-after-free allowing local privilege escalation to root
#48Would Rust have made this issue impossible by construction? I know Linus has spoken about Rust's promises about memory safety not being equivalently applicable in the kernel domain, so I would be curious to hear any kernel developer's perspectives.
Rust is designed to make this type of issue impossible, but that assumes that you can correctly encode object lifetimes in the kernel in a way that allows the compiler to check them. So I would say that any easy answer like “this would not compile” would just be a guess, because you would want to know more of the particulars in order to answer this question. I know that this is kind of a non-answer, but if you want t…
I would say that Rust has a good story here. The simple form of this wouldn't compile. So you are generally presented two options:
1. Slap a reference count on it.
2. Use `unsafe` to promise the compiler that your code is right.
I would say that 1 is a pretty good habit to have. It may open you to memory leaks if you aren't careful but those are much less bad than a use-after-free or other memory management issues. And of course the fact that this was the route the patch took is a good sign. I think this is a pretty good default option.
Now if performance is a major issue you may consider going to 2, so it is impossible to say "Rust would have prevented this" because if it was originally written in Rust this may have been the route taken. But I think it is still very valuable to make that an explicit choice and obvious to reviewers and readers.
Re: OpenBSD has a use-after-free allowing local privilege escalation to root
#49OpenBSD's security stance being the stuff of legend, I'm curious how many vulns have been found over the last couple months while the big model companies are flaunting their ability to find exploits. It'd be super cool to see it remain tiny.
I think of it more as their attention to quality in their code: Given the 'quality' of most code, especially under commercial pressure, it's no surprise that much more effective tools will find many more vulnerabilities. Did OpenBSDs quality approach work in this respect?
A local escalation in BSD is still apparently worth a front page post here, so that seems pretty good.
I wonder why we don’t see more about local escalations in Windows. Of course, being closed source is a little bit of a barrier, but these tools can read assembly pretty well, right?
Re: OpenBSD has a use-after-free allowing local privilege escalation to root
#50OpenBSD's security stance being the stuff of legend, I'm curious how many vulns have been found over the last couple months while the big model companies are flaunting their ability to find exploits. It'd be super cool to see it remain tiny.
> OpenBSD's security stance being the stuff of legend, More so their marketing.
What does openbsd marketing look like?