Re:Moving the Linux Kernel to Modern C
by neysofu on Thursday February 24, 2022 @05:44PM
(#30461378)
Yes, he did, but that just shows that it's possible to inject self-replicating code in a compiler. It doesn't actually tell us how resistant such code is to compiler source changes, audits, binary analysis, etc. which are all required for a successful exploit.
[ Parent
| on HN ]
Re:Moving the Linux Kernel to Modern C
by boogies on Thursday February 24, 2022 @06:02PM
(#30461550)
But the University of Minnesota experiments prove at least some malicious code is capable of passing at least standard Linux code review, right?
Re:Moving the Linux Kernel to Modern C
by gmfawcett on Thursday February 24, 2022 @06:39PM
(#30461886)
There's a world of difference between that and Thompson's attack. You don't exploit the kernel code: you exploit the compiler code, such that every program it compiles (a) is compromised, and (b) is incapable of detecting the exploit in programs compiled by the same compiler.
Re:Moving the Linux Kernel to Modern C
by IshKebab on Thursday February 24, 2022 @06:37PM
(#30461865)
That's a completely separate issue. The trusting trust bug requires you to convince people to use your compiler binaries. The thing you're talking about just requires a patch to pass code review.
It's more work - you have to figure out a sneaky bug and write a legit looking patch - but anyone can do it. You don't have to be in a position of power already (e.g. being the Debian GCC packager) so overall it is much easier.
I think they only got past a single reviewer and counted that as success, none of their harm code made it into the kernel proper. However the University also committed thousands of automated "fixes" for linter warnings that weren't part of the study and the kernel maintainers ended up reverting all of them due to the Universities overblown claims.
No, no malicious code passed. All malicious code was rejected before making it into the kernel.