Dirty COW redux: Linux devs patch botched patch for 2016 mess Linus Torvalds last week rushed a patch into the Linux kernel, after researchers discovered the patch for 2016's Dirty COW bug had a bug of its own. Dirty COW is a privilege escalation vulnerability in Linux's “copy-on-write” mechanism, first documented in October 2016 and affecting both Linux and Android systems. As The …
>>Many other *nixes do have the bug: “Every kernel version with THP support and the Dirty COW patch should be vulnerable (2.6.38 – 4.14)”, Yaakov and Shapiro wrote.
Uh, It doesn't affect *nix. It affects Linux and Linux alone as it is a kernel flaw.
The BSDs don't use the Linux kernel and neither do the commerical UNIXes like macOS, AIX, Solaris and HP-UX. None of them are affected. Android, however, is a Linux (somewhere) in its guts and it is. Google's kernels tend toward the older side even on the Nexus/Pixel handsets so kernel flaws are an even bigger deal there.
Interesting that RHEL isn't affected though. Then again, there are probably a good number of systemd bugs that are likely just as potentially harmful to make up for it.
And this isnt to say that commerical UNIX or the BSDs are better, nine years is nothing compared to 25 years, like a bug in dir() that existed from 1983 to 2008.
"Interesting that RHEL isn't affected though.".
Had to look into that as there has to be some simple explanation.
From: https://bugzilla.redhat.com/show_bug.cgi?id=1516514
"this issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 5, 6, 7 and Red Hat Enterprise MRG 2. They do not contain the upstream commit ".
But then again:
"This issue affects the Linux kernel packages as shipped with Red Hat Enterprise Linux 7 for ARM and Red Hat Enterprise Linux for Power LE kernel-alt packages."
("The new kernel version provided by the kernel-alt packages is based on upstream version 4.11)".
(The article was just a bit imprecise)
It is huge pages and vm. Each and every unix has very different internal implementation of that part.
It is also a part where Linux has had its share of bugs over the years - the code there is distinctly gothic and not for the feinthearted. The reason for this is that Linux was the first to go fully dynamic VM with tight integration between vm and filesystem cache. It is hairy, crazy, but also extremely fast for file IO and very flexible for changes in network/IO load.
The other Unix-like OSes (and not just unix-like) lagged 5+ years behind - the original BSD and SysV designs used fixed memory pools dedicated to a particular use which you could retune only upon startup or kernel recompile (this rather archaic idea is being resold to us as a part of DPDK and other similar toolkits as the freshest fresh bovine dung at the moment). They went dynamic later learning from Linux mistakes and they are significantly cleaner in this area.
And this isnt to say that commerical UNIX or the BSDs are better, nine years is nothing compared to 25 years, like a bug in dir() that existed from 1983 to 2008.
While I agree with your statement, you are comparing a bug in a function that potentially skipped a file entry in a directory when you were reading the contents of a directory with this privilege escalation bug ?
News flash! All software that has 100's of lines of code has bugs.
All software has bugs.
Because bugs are literally "loopholes" missed in the prescription of what you want the computer to do. Those bugs can come from assumptions made, difference in architecture, simple human error, un-considered special cases, or even just a compiler bug (you always assume the compiler does exactly what you tell it, but the compiler is just as likely to have bugs too!).
You can't stop it. What you can do is take more care. But that's costly, expensive, time-consuming and difficult and may not solve the problem.
In terms of allocation of resources, it's much more sensible to take basic care all the time, special care when something happens and VERY special care when crafting a fix for a serious bug in case you make it (or something else) worse. In this case, even that special care wasn't enough.
But like lawyers poking through a century of established law, people looking for bugs can always find a loophole eventually, especially when the "law" in this case is required to keep up with the very-cutting-edge of technology on machines that don't even exist yet.
There's no language, methodology, tool or analyser that can stop code having bugs. Because they aren't "things". They are "absence of things". They are loopholes in logic itself. Rarely are they "whoops, we accidentally trash all memory which results in data loss". In fact, it often takes longer to explain why they are a problem than to discover or fix them.
Faced with that, all those "you're using the wrong language", "you should use this process", etc. people really drive me mad. Sure, those things can help. But they just change the boilerplate, they don't stop the possibility of loopholes in the logic.
> There's no language, methodology, tool or analyser that can stop code having bugs.
You are suffering from a basic confusion. You believe that just because you have never and will never take a systematic approach to software safety that that somehow implies that anybody else taking a systematic approach to software safety is doomed to failure. Either that or you're peddling the old dodge that a methodology or technology that only solves SOME of the problems instead of literally ALL the problems ever is absolutely worthless.
"Bugs happen!", you say, while chuckling, and then you, and everybody else who thinks like you, gleefully inflict them on others.
It's like finding a car dealer who only sells Ford Pintos and then, when a steady stream of maimed and burnt customers shamble back in says "Ford Pintos are perfectly safe! All you have to do is never let anybody crash into your car from behind! Man, I'm sure exhausted from solving all the problems!"
> This is why theorem provers have been invented.
Not quite, certainly not worth the "LOLNO".
Theorem provers were invented - because, hey, why not, they're fun - and after that someone had a go at applying them to software. And found that it is jolly tricky to express your software, requirements and all, in a way that can be usefully processed by a theorem prover. So, precious little software has ever been "proved correct" and bug free - so little, and encountered by so few working programmers, that the "all" in "all software ... has bugs" barely even registers as hyperbole.
And even that is pre-supposing that the requirements can still be regarded as 'bug free' themselves, as Lee D pointed out.
So you theorem-prove your code.
What do you compile it with?
Was that theorem-proved for all cases too?
What OS do you run it on? Was that?
What hardware do you run it on? Was that?
Besides that, it's an INCREDIBLY EXPENSIVE exercise to prove anything like that (Hint: I've a degree in mathematics and computer science). Multiplying that out by even a new kernel configuration, let alone a different kernel on different machines using different patches in different configurations compiled under different compilers and running under different environments (e.g. VMs etc.), and then do so for EVERY change made is literally bankrupt-the-world territory.
Bugs happen. And at least half the bugs are in the LOGIC of what you express, not how you chose to express it. Because those 100's of lines of code express BILLIONS of potential code-paths / hardware combinations almost immediately.
Hell, who sits and proves that Intel chips stick to the x86-64 specifications in all circumstances? I'm pretty sure that Intel don't, because if they did everything from the old FDIV bug up to errata on every fabricated chip in existence wouldn't happen. Intel processors have a microcode update almost every month nowadays, it gets patched-in with your Windows driver updates or Linux firmware updates, on-the-fly, as the machine boots, to stop you seeing the things that the chip never got right.
There's no such thing as bug-free code, even mathematically-speaking, as you literally cannot define strictly enough that you could afford to test it all. What you do is allocate resources accordingly (e.g. mathematically prove things like life-support systems, attend to security code more carefully, but don't try to pretend that everything you churn out could ever be bug-free).
Even NASA get it drastically wrong, let alone Microsoft, let alone "one-man-band who knocks up a free bit of software".
MOAN MOAN MOAN!
Can't be done, won't be done, here is why, I'm so unbeliever, I don't wanna live in this century etc. etc.
It's really like I'm back in first semester. In 1989.
Reasoning and Verification: State of the Art and Current Trends (2014 IEEE INTELLIGENT SYSTEMS)
I'll throw a real world anecdote on the heap - Guild Wars.
The first Guild Wars game client had crash dumps. On investigation, some of these crash reports were meant to be impossible, but they kept coming in no matter what they tweaked. So far, so familiar.
They had an Old Coder in their ranks. He wrote into the game client some gentle background mathematical and memory doodling; little exercises with known results. These would go back in any crash reports.
Turns out, there's vast swathes of PC hardware out there that can't be trusted not to randomly fumble basic operations. And now they could detect and discard them.
INMOS used formal methods to verify their IEEE754 implementation, sure they made mistakes but they made *far* fewer than the established players in the field, and consequently made less steppings/field changes to compensate. It was a reasonably quick FPU for the day too. :)
Hardware guys are light years ahead with formal methods, but their dev iterations are considerably more time consuming and costly so they have a greater incentive to weed out thinkos and bugs early. There is already software out in the wild that has had formal methods applied (rigorously in some cases) with varying degrees of success, as time goes by economics may justify/drive more software to apply formal methods. There's no reason to apply them willy-nilly, select the areas that can benefit the most to maximise the bang for buck.
I remember back in the late 1960's I was writing the exec code for a ~100 user time sharing system one of the programmers came to me and said I had a bug in the executive (called kernel now). He was writing a debugger and claimed I was incorrectly setting a bit indicating whether a trap occurred "normally" or in "code being debugged". With him watching I checked the relevant code and, sure enough, there was a bug.
I fixed the bug and a day later he came back sheepishly and said that he had committed the exact same bug in his code, which he had discovered when debugging the debugger debugging the debugger.
Logic bugs are really hard to catch and stamp out.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
