151–160 of 186 posts
Earlier quoted context omitted.
[dead]
> Also, the Linux kernel developers turned off strict aliasing in the C compilers they use, because they found strict aliasing too difficult. I'm not sure "they found strict aliasing too difficult" is an entirely correct characterization? From this rather (in)famous email from Linus [0]: The fact is, using a union to do type punning is the traditional AND STANDARD way to do type punning in gcc. In fact, it is the *do…
Earlier quoted context omitted.
[dead]
> But unsafe Rust, which is generally more often used in low-level code, is more difficult than C and C++. I think "is" is a bit too strong. "Can be", sure, but I'm rather skeptical that all uses of unsafe Rust will be more difficult than writing equivalent C/C++ code.
Earlier quoted context omitted.
I'd argue, that while null ref and those classes of bugs may decrease, logic errors will increase. Rust is not an extraordinary readable language in my opinion, especially in the kernel where the kernel has its own data structures. IMHO Apple did it right in their kernel stack, they have a restricted subset of C++ that you can write drivers with. Which is also why in my opinion Zig is much more suitable, because it a…
I would argue logic errors would decrease because you aren't spending as much time worrying about and fixing null ref and other errors.
Before the "rewrite it in Rust" comments take over the thread: It is worth noting that the class of bugs described here (logic errors in highly concurrent state machines, incorrect hardware assumptions) wouldn't necessarily be caught by the borrow checker. Rust is fantastic for memory safety, but it will not stop you from misunderstanding the spec of a network card or writing a race condition in unsafe logic that int…
I don't think 70% of bugs are memory safety issues. In my experience it's closer to 5%.
Before the "rewrite it in Rust" comments take over the thread: It is worth noting that the class of bugs described here (logic errors in highly concurrent state machines, incorrect hardware assumptions) wouldn't necessarily be caught by the borrow checker. Rust is fantastic for memory safety, but it will not stop you from misunderstanding the spec of a network card or writing a race condition in unsafe logic that int…
The lesson here is that people have an unrealistic view of how complex it is to write correct and safe multithreaded code on multi-core, multi-thread, assymmetric core, out-of-order processors. This is no shade to kernel developers. Rather, I direct this at people who seem to you can just create a thread pool in C++ and solve all your concurrency problems. One criticism of Rust (and, no, I'm not saying "rewrite it in…
There are entire classes of structures that no, aren't hard to do properly, but the borrow checker makes artificially hard due to design limitations that are known to be sub-optimal.
No, two-directional linked lists and partially editable data structures aren't inherently hard. It's a Rust limitation that a piece of code can't take enough ownership of them to edit they safely.
What's with the odd scribbles in the background?
Interesting! We did a similar analysis on Content Security Policy bugs in Chrome and Firefox some time ago, where the average bug-to-report time was around 3 years and 1 year, respectively. https://www.usenix.org/conference/usenixsecurity23/presentat... Our bug dataset was way smaller, though, as we had to pinpoint all bug introductions unfortunately. It's nice to see the Linux project uses proper "Fixes: " tags.
Sort of. They often don't.
grsecurity project has fixed many security bugs but did not contribute back, as they're profiting from selling the patchset. It's not uncommon for the bugs they found to be rediscovered 6-7 years later. https://xcancel.com/spendergrsec
1. Tons of bugs are reported upstream by grsecurity historically.
2. Tons of critical security mitigations in the kernel were outright invented by that team. ASLR, SMAP, SMEP, NX, etc.
3. They were completely FOSS until very recently.
4. They have always maintained that they are entirely willing to upstream patches but that it's a lot of work and would require funding. Upstream has always been extremely hostile towards attempts to take small pieces of Grsecurity and upstream them.
Earlier quoted context omitted.
probably quite a bit less than 5%, however, they tend to be quite serious when they happen
Only serious if you care about protecting from malicious actors running code on the same host.