Comment by whytevuhuni
3 days ago
> My question is how likely can it be adopted in the kernel (likely high).
My guess is, it cannot. The way -fbounds-safety works, as far as I understand, is that it aborts the program in case of an out-of-bounds read or write. This is similar to a Rust panic.
Aborting or panicking the kernel is absolutely not a better alternative to simply allowing the read/write to happen, even if it results in a memory vulnerability.
Turning people's computer off whenever a driver stumbles on a bug is not acceptable. Most people cannot debug a kernel panic, and won't even have a way to see it.
Rust can side-step this with its `.get()` (which returns an Option, which can be converted to an error value), and with iterators, which often bypass the need for indexing in the first place.
Unfortunately, Rust can still panic in case of a normal indexing operation that does OOB access; my guess is that the index operation will quickly be fixed to be completely disallowed in the kernel as soon as the first such bug hits production servers and desktop PCs.
Alternatively, it might be changed to always do buf[i % buf.size()], so that it gives the wrong answer, but stays within bounds (making it similar to other logic errors, as opposed to a memory corruption error).
Yes, panicking in kernels is bad. I've followed the whole R4L fight about working around it.
https://github.com/apple-oss-distributions/xnu/blob/main/doc...
https://github.com/apple-oss-distributions/xnu/blob/main/doc...
Upstream fbounds in xnu has options for controlling if it panics or is just a telemetry event. They are in a kernel situation and have the exact same considerations on trying to keep the kernel alive.
Ah, thank you. If it can just do the equivalent of WARN_ON_ONCE(…) and continue, and the check wouldn’t be slow enough to make people disable it, then yeah, that sounds really good.
https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-May11/...
Supposedly ~5% (1-29%), but I'm testing my own projects to verify (my guess is higher at 10-20%, but will depend on the code). Supposedly it's to land in gcc at some point but I dunno the time table.
Here are some Linus's thoughts on why security hardening efforts should never break the program: https://lkml.org/lkml/2017/11/21/356
What does "hardening" mean here?
For GCC I have a patch (maybe 10 lines of code) that emits a warning whenever the compiler inserts a trap. You could use a sanitizer, i.e. bounds checking or signed overflow, add code that turns the warning into an error, and so ensure that your code does not have a signed overflow or OOB.
That sounds like a useful patch. Why didn't you upstream it?
I submitted it upstream but it was not accepted. There was a request to add a string argument that can be printed with the warning.
Sanitizers don’t ship to production.
The use case I described is not for production.
So out of bounds access leading to data loss and possible security vulnerability is better than crashing the kernel? That doesn't make sense to me.
One of those things might take your server/application/data out. The other is guaranteed.
For many use cases, blowing up loudly is strongly preferable to silently doing the wrong thing. Especially in the presence of hostile actors, who are trying to use your out -of-bounds error for their own gain.
1 reply →
One of those things might allow attacker to get access to data they should not have access to or to run arbitrary code on your server. The other does not.