 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Someone recently found a bug whereby a piece of C code read
xyz->pdq = some value;
....
if (!xyz) return (error code);
...
do_something_dangerous();
Someone mapped a page into 0, invoked the bit of the kernel that had the
code, and did something dangerous in spite of xyz being null. It turns out
GCC looks at the test for NULL in the second line, decides that since it has
already been dereferenced in the first line it can't be NULL (or a segfault
would have thrown), and eliminates that test.
Now the question I have is, why in the world would you optimize that test
away? Is using a value and then testing it for null later so frequent that
you need to throw away that test? And if so, wouldn't it be better to simply
warn that it probably isn't what you intend, just like happens with
comparing an unsigned value to a negative number? I just can't imagine a
situation where the compiler can prove that xyz has been dereferenced
without it being checked yet the null test later isn't indicative of a
programming error.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Someone recently found a bug whereby a piece of C code read
... Which should be interpreted as "I recently found a discussion of a bug
that someone else found..." :-) Just to clear that up.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Darren New wrote:
>> Someone recently found a bug whereby a piece of C code read
>
> .... Which should be interpreted as "I recently found a discussion of a
> bug that someone else found..." :-) Just to clear that up.
>
At a guess that would be:
http://www.theregister.co.uk/2009/07/17/linux_kernel_exploit/
John
--
"Eppur si muove" - Galileo Galilei
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Someone recently found a bug whereby a piece of C code read
> xyz->pdq = some value;
> ....
> if (!xyz) return (error code);
> ...
> do_something_dangerous();
> Someone mapped a page into 0, invoked the bit of the kernel that had the
> code, and did something dangerous in spite of xyz being null. It turns out
> GCC looks at the test for NULL in the second line, decides that since it has
> already been dereferenced in the first line it can't be NULL (or a segfault
> would have thrown), and eliminates that test.
Why couldn't the compiler assume that if nothing modifies xyz between
the assignment and the test, that it doesn't get modified? It seems to me
like a rather valid assumption.
The only exception is if xyz is not local to the function, in which case
it might get modified by another thread. But in that case you have to tell
the compiler that it may be modified at any time (by at the very least
specifying that xyz is volatile, although it's better that access to it
is guarded by a mutex lock).
(Btw, AFAIK the C standard specifially says that a null pointer cannot
contain a valid value. Thus the compiler can assume that it can't contain
a valid value.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Doctor John wrote:
> At a guess that would be:
> http://www.theregister.co.uk/2009/07/17/linux_kernel_exploit/
Yes, but since that wasn't the point of my question and people might
reasonably assume I'm bashing on Linux if I posted a link to it, I thought
I'd omit it. The question was why the compiler felt the need for *that*
optimization in the first place. When would it ever be a good idea?
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Someone recently found a bug whereby a piece of C code read
>
>> xyz->pdq = some value;
>> ....
>> if (!xyz) return (error code);
>> ...
>> do_something_dangerous();
>
>
>> Someone mapped a page into 0, invoked the bit of the kernel that had the
>> code, and did something dangerous in spite of xyz being null. It turns out
>> GCC looks at the test for NULL in the second line, decides that since it has
>> already been dereferenced in the first line it can't be NULL (or a segfault
>> would have thrown), and eliminates that test.
>
> Why couldn't the compiler assume that if nothing modifies xyz between
> the assignment and the test, that it doesn't get modified? It seems to me
> like a rather valid assumption.
There's no assumption xyz didn't get modified. The assumption is that since
you referenced it in the first line, the second line will never fail because
the first line would have dumped core. I.e., if the first line had been
int pdq = *xyz;
if (!xyz) do_something();
then the compiler would omit the code to invoke do_something(), as well as
the test. No assignment to xyz, but just a reference.
I'm trying to figure out what possible benefit such an optimization could
have. I.e., this code is obviously *wrong* - why would you bother to include
optimizations to improve the performance of erroneous code?
> (Btw, AFAIK the C standard specifially says that a null pointer cannot
> contain a valid value. Thus the compiler can assume that it can't contain
> a valid value.)
Yep.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> (Btw, AFAIK the C standard specifially says that a null pointer cannot
> contain a valid value. Thus the compiler can assume that it can't contain
> a valid value.)
The problem is that in C a null pointer is represented
by 0, but 0 is a valid memory address. So when you
have a valid pointer to address 0, then the optimizer
thinks you are checking for null, not for address 0.
It does seem bad to me to have a so much bloat
in the control switches for the GCC optimizer.
Take a look...
http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Optimize-Options.html#Optimize-Options
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Attwood wrote:
> The problem is that in C a null pointer is represented
> by 0,
Depends on the architecture, really, but in most cases, yes.
> but 0 is a valid memory address. So when you
> have a valid pointer to address 0, then the optimizer
> thinks you are checking for null, not for address 0.
The exploit was a bug in the kernel that dereferenced a pointer before
checking for null, and the compiler silently optimized out the later check
for null. If you can get the first dereference to work (by mapping some
valid memory to the address associated with the null pointer value) then you
skip over code people thought they wrote into their program and which the
compiler removed.
> It does seem bad to me to have a so much bloat
> in the control switches for the GCC optimizer.
Tell me about it. Just wait till you have the fun of cross-compiling the
compiler. :-)
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Let's say I wrote a macro that does something that happens to be useful to
me, along these lines:
#define DO_USEFUL_STUFF( OBJECT ) if ( OBJECT ) OBJECT->usefulMethod();
Now, I go and use this macro in different places. In some places, the object
passed is likely to be NULL. In others, it's not. I would be glad that the
compiler is optimizing out the unnecessary checks for me, while still
letting me benefit from the general usefulness of my macro.
Of course this is a contrived example, but it's probably not too far from a
real use case.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Attwood <tim### [at] anti-spamcomcastnet> wrote:
> > (Btw, AFAIK the C standard specifially says that a null pointer cannot
> > contain a valid value. Thus the compiler can assume that it can't contain
> > a valid value.)
> The problem is that in C a null pointer is represented
> by 0, but 0 is a valid memory address. So when you
> have a valid pointer to address 0, then the optimizer
> thinks you are checking for null, not for address 0.
Well, dereferencing a null pointer is undefined behavior, so from the point
of view of the standard the compiler can do whatever it wants. Thus gcc is
not doing anything wrong here (because after a null pointer dereference there
is no "wrong" to be done).
If someone is to be blamed is the designers of the kernel if they decided
that a null pointer points to a valid address, against the C standard, and
then implemented the kernel in C (using a standard-conforming C compiler).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> The exploit was a bug in the kernel that dereferenced a pointer before
> checking for null, and the compiler silently optimized out the later check
> for null. If you can get the first dereference to work (by mapping some
> valid memory to the address associated with the null pointer value) then you
> skip over code people thought they wrote into their program and which the
> compiler removed.
I'd rather say it was a flaw in the kernel, forgetting to already check for null
*before* dereferencing.
In such a "mission-critical" piece of software such as a kernel, *all* that
comes in from untrusted sources should *always* be checked thoroughly before
doing *anything* with it. "Oh, if this pointer happens to be NULL, the software
will core dump anyway" is a *very* questionable mode of operation.
Code dereferencing a possibly-NULL pointer *is* bogus - it's nothing you can
simply blame on the compiler. And mission-critical code should not *never* be
bogus.
There's even some reason to argue that if the programmer happily dereferences a
pointer without checking it for NULL, why shouldn't the compiler assume that
other provisions have been made that it cannot be NULL in the first place?
I'm also surprised that this flaw wasn't found and fixed earlier. There's tools
like PC-lint (taken as an example here because I'm a bit familiar with it) that
do a pretty good job at complaining when you're trying to dereference a
potentially-NULL pointer. I mean, you'd expect that *someone* runs *something*
like PC-lint on code as widely-used as a Linux kernel?!
Well, maybe that's a problem with free-software projects: PC-lint costs money.
Companies developing commercial software can afford to buy a few licenses. The
individual parties in a free-software project possibly can't, or refuse to pay
anything for their tools, or refuse to be the only ones paying for something
that benefits all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> Code dereferencing a possibly-NULL pointer *is* bogus - it's nothing you can
> simply blame on the compiler. And mission-critical code should not *never* be
> bogus.
I didn't get the impression that they were dereferencing a null pointer
deliberately in order to get an exception, or that it was a mistake. (The
only "mistake" was not realizing what kind of optimization gcc would do.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> I'd rather say it was a flaw in the kernel, forgetting to already check for null
> *before* dereferencing.
Yes, exactly. But I'm trying to figure out why you would add optimizations
specifically to improve the performance of code you are optimizing *because*
you know it is flawed.
Note that this isn't just a general dead-code-elimination. This is
specifically checking for "test for null after already dereferencing", as
there's an explicit compiler chip to turn that off.
> In such a "mission-critical" piece of software such as a kernel, *all* that
> comes in from untrusted sources should *always* be checked thoroughly before
> doing *anything* with it.
Right. I think the comments on the report of it that I read implied that
the assignment was added later, and the problem is that in C, the
declarations all had to be at the top.
So someone wrote
blah * xyz;
if (!xyz) return failure;
... use xyz ...
Someone else came along and added a declaration
blah * xyz;
another pdq = xyz->something;
if (!xyz) ....
Instead, they should have said
blah * xyz;
another pdq;
if (!xyz) ...
pdq = xyz->something;
> "Oh, if this pointer happens to be NULL, the software
> will core dump anyway" is a *very* questionable mode of operation.
Exactly.
> Code dereferencing a possibly-NULL pointer *is* bogus - it's nothing you can
> simply blame on the compiler. And mission-critical code should not *never* be
> bogus.
Agreed. The problem is that the compiler optimized out good code based on
bogus code. My only question is whether I'm missing something here, because
such an optimization seems really a bad idea.
> There's even some reason to argue that if the programmer happily dereferences a
> pointer without checking it for NULL, why shouldn't the compiler assume that
> other provisions have been made that it cannot be NULL in the first place?
That's exactly what the compiler did. It looked, saw the dereference of the
pointer, then the check that the pointer isn't null, and optimized out the
check for the pointer being null. But the fact that the programmer said to
check for NULL at a point where all code paths have already dereferenced the
pointer would seem to be at least a warning, not an "oh good, here's an
optimization I can apply."
The only reason I can think of for that would be code generated from some
other language, at which point I'd think you'd want a compiler flag to turn
*on* that optimization, with it being off by default.
> I'm also surprised that this flaw wasn't found and fixed earlier.
I'm surprised and dismayed when the kernel gets code checked in that's
syntactically invalid, then released, then when people complain about it
they say "Oh, I didn't know how that code builds" and someone else says "try
changing the ownership of the source file to be root", and then a few weeks
later they have a patch on some website somewhere unassociated with the
actual original project that makes it compile.
I'm beyond being surprised at how bad the free stuff can be if you're
actually a programmer. </rant>
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> Of course this is a contrived example, but it's probably not too far from a
> real use case.
Ah, that makes sense. Thank you for clarifying that.
It *is* code generation. Just from the same language you're compiling. That
didn't occur to me. :-)
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Doctor John wrote:
>> At a guess that would be:
>> http://www.theregister.co.uk/2009/07/17/linux_kernel_exploit/
>
> Yes, but since that wasn't the point of my question and people might
> reasonably assume I'm bashing on Linux if I posted a link to it, I
> thought I'd omit it. The question was why the compiler felt the need
> for *that* optimization in the first place. When would it ever be a good
> idea?
>
Actually, I was going to ask the group the same question but you just
beat me to it :-) and you could hardly assume that I was in any way
anti-Linux.
What bothers me (apart from the unwanted optimisation) is why Torvalds
et al have chosen to remain silent on this.
Another thing to remember is that it is not only the kernel code that is
the problem here, it's also gcc - so comments from the Stallman camp
would also be appropriate.
John
--
"Eppur si muove" - Galileo Galilei
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> But I'm trying to figure out why you would add optimizations
> specifically to improve the performance of code you are optimizing *because*
> you know it is flawed.
No, optimizers don't optimize code *because* it's flawed, just maybe *although*
it's flawed.
Or, possibly more particularly fitting the intention in this case: Although it
is *redundant*.
After all, that's a crucual part of optimization. It allows programmers to write
source code that is more self-descriptive and more self-defensive, yet at the
speed of hand-optimized code.
For instance, one might write:
if (i <= LOWER_BOUND) {
return ERR_TOO_LOW;
}
// very long code here
if (i > LOWER_BOUND && i <= UPPER_BOUND) {
// (1)
return OK;
}
The test for i>LOWER_BOUND is, of course, perfectly redundant. But explicitly
stating it may help...
(a) to make it easier to see for the casual reader that at (1), i>LOWER_BOUND is
always true; after all, they may not have read the part before the very long
code, or may have forgotten about the i<=LOWER_BOUND test by then; and
(b) to make sure that at (1), i>LOWER_BOUND is true even when someone tampers
with the remainder of the code and happens to remove the first check.
> Right. I think the comments on the report of it that I read implied that
> the assignment was added later, and the problem is that in C, the
> declarations all had to be at the top.
>
> So someone wrote
> blah * xyz;
> if (!xyz) return failure;
> ... use xyz ...
>
> Someone else came along and added a declaration
> blah * xyz;
> another pdq = xyz->something;
> if (!xyz) ....
That may indeed explain how the code came to be there in the first place.
> Instead, they should have said
> blah * xyz;
> another pdq;
> if (!xyz) ...
> pdq = xyz->something;
Yesss. Absolutely.
I must confess that I used to do it otherwise, too. It was PC-lint that taught
me not to, by constantly pestering me about it. And developing embedded
software for the automotive industry, I had to obey it: MISRA rules forbid to
use *any* language constructs that officially lead to unspecified behavior.
> Agreed. The problem is that the compiler optimized out good code based on
> bogus code. My only question is whether I'm missing something here, because
> such an optimization seems really a bad idea.
Optimizers aren't designed to detect bogus code - they're designed to speed up
things.
Even most compilers do a pretty poor job at detecting bogus code.
That's why you need static code-analysis tools, specifically designed to
identify such bogosities.
> > There's even some reason to argue that if the programmer happily dereferences a
> > pointer without checking it for NULL, why shouldn't the compiler assume that
> > other provisions have been made that it cannot be NULL in the first place?
>
> That's exactly what the compiler did. It looked, saw the dereference of the
> pointer, then the check that the pointer isn't null, and optimized out the
> check for the pointer being null. But the fact that the programmer said to
> check for NULL at a point where all code paths have already dereferenced the
> pointer would seem to be at least a warning, not an "oh good, here's an
> optimization I can apply."
As I already pointed out above, it may also have been code that the developer
left in there just for clarity, to be removed later, or whatever, *expecting*
the compiler to optimize it away.
> I'm surprised and dismayed when the kernel gets code checked in that's
> syntactically invalid,
At this point, in a good commercial project the developer would already get his
head chopped off - by colleagues wo *do* their homework and therefore hit this
stumbling block when trying to compile their own changes to do their own module
testing (and as good developers had suspected themselves to have done something
wrong first, and spent hours to track down the problem, until ultimately
identifying their colleague as the culprit and being *not* amused).
Checking in code you never actually compiled yourself? Hey, haven't done our
homework, have we?!?
> then released,
.... and at this point it would be the build manager's head to roll if it's a
single-platform project or the particular code applies to all projects - or the
test team leader's head if it's intended to be a portable thing and the code is
activated only on certain target platforms (unless of course the code is a fix
for an exotic platform that isn't available in-house).
In free-software projects with all contributors being volunteers, unfortunately
there's no authority to chop off some heads. After all, if you treat the
volunteers too harshly, off they go to someplace more relaxed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Doctor John <joh### [at] homecom> wrote:
> What bothers me (apart from the unwanted optimisation) is why Torvalds
> et al have chosen to remain silent on this.
What? And lose ground on their "safest operating system on earth" territory?
I did believe that, too, but hearing these news and thinking about the
background and how the "top hats" went to deal with the issue, I guess it's
time to start thinking out of the box once again: The Linux developer
community, too, want to "sell" their products in a way. Both their kernel, and
their FSF ideals.
Now, after always claming that free software is the superior development
approach, they prove that some of its drawbacks are potentially more serious
than they would like them to be.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> [-- text/plain, encoding 8bit, charset: iso-8859-1, 18 lines --]
> Doctor John <joh### [at] homecom> wrote:
> > What bothers me (apart from the unwanted optimisation) is why Torvalds
> > et al have chosen to remain silent on this.
> What? And lose ground on their "safest operating system on earth" territory?
> I did believe that, too, but hearing these news and thinking about the
> background and how the "top hats" went to deal with the issue, I guess it's
> time to start thinking out of the box once again: The Linux developer
> community, too, want to "sell" their products in a way. Both their kernel, and
> their FSF ideals.
> Now, after always claming that free software is the superior development
> approach, they prove that some of its drawbacks are potentially more serious
> than they would like them to be.
Aren't you exaggerating a bit?
Do you know how many serious security holes are found each year in Linux?
I think the number is in the *hundreds*. A few of these bugs each year provide
a way to get root privileges by running a program exploiting the bug. It has
happened dozens of times in the past, and it will happen in the future. This
is just another one of those.
(And before anyone says anything, no, Windows is not better. Windows is
year after year always at the top of the list of most security flaws found
during the year.)
You *can't* expect the OS to be completely safe.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Do you know how many serious security holes are found each year in Linux?
And I don't think this one is even in a kernel that was released into major
distributions, for that matter. :-)
> (And before anyone says anything, no, Windows is not better. Windows is
> year after year always at the top of the list of most security flaws found
> during the year.)
Is this still true? I think there's more 3rd-party flakey code, but not
stuff that comes with Windows necessarily. Certainly not as much as it used
to be.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Optimizers aren't designed to detect bogus code - they're designed to speed up
> things.
Sure, but it sounded like an optimization that only worked on bogus code,
which seemed like a waste of time of the person writing the optimizer.
Macros make a good explanation why, tho.
> As I already pointed out above, it may also have been code that the developer
> left in there just for clarity, to be removed later, or whatever, *expecting*
> the compiler to optimize it away.
I think this is different. Your cases, sure.
> At this point, in a good commercial project the developer would already get his
> head chopped off
Well, to be fair, they all know it's bogus. It's been at 0.9.x for like five
years. :-) I'm always amused at open source folks who won't recognise that
the first thing they give to the public is 1.0 regardless of how you number it.
> Checking in code you never actually compiled yourself? Hey, haven't done our
> homework, have we?!?
Crap like this would be completely untenable before Google, really.
> test team leader's head if it's intended to be a portable thing and the code is
> activated only on certain target platforms (unless of course the code is a fix
> for an exotic platform that isn't available in-house).
This happened to be some mips-specific assembly. Not exactly exotic, but
then why are you changing that file if you don't have a mips chip to test it
on in the first place?
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > (And before anyone says anything, no, Windows is not better. Windows is
> > year after year always at the top of the list of most security flaws found
> > during the year.)
> Is this still true? I think there's more 3rd-party flakey code, but not
> stuff that comes with Windows necessarily. Certainly not as much as it used
> to be.
I don't know. I haven't been reading such reports lately. One would think,
though, that new OS = new bugs (unless Vista isn't really "new").
But I still think it's fair to say that Linux is safer than Windows. Why?
For the simple reason that Linux is not such a popular *target* for attacks
and malware as Windows is. For example, basically 100% of email virii and
http exploits have targetted Windows. I'd bet at least 99.99% of more
traditional virii out there work only on Windows (and the older ones in
DOS). Almost 100% of malware (spyware, adware, trojans, rootkits...) target
Windows. While I have no idea how popular Windows as a target is among
crackers, I bet it's well over half of them for the simple reason that
Windows is way more widespread than Linux. (The only place where other
systems might rival Windows as a target of crackers is in the web servers
and other such servers, because there other systems are more popular than
in desktop computers.)
Of course, Linux is in no way safe from attacks either. In fact, the linux
box of a good friend of mine got hijacked by a hacker some years ago (and it
remained so for a good amount of time, I think it was several weeks or even
months, without my friend noticing). However, usually these cases are direct
attacks by individual hackers, rather than being a massive attack by a
self-spreading program. You are much less likely to get your computer hacked
by someone directly, than by a self-spreading program (assuming you are
running an OS supported by that program). While I don't assume that my
linux box has not been hijacked without me noticing, I'd say it's pretty
unlikely.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I don't know. I haven't been reading such reports lately.
Same here.
> One would think,
> though, that new OS = new bugs (unless Vista isn't really "new").
Well, it's not really new. It's built on NT, 2000, 2003, etc. And it has a
whole bunch of new security stuff added (Defender, UAC, secure desktops (or
whatever they call the thing that prevents the shatter attack), etc)
I'd have to start taking the SANS stuff out of the junk folder, but my
memory is that most of the attacks are against web-based services, with very
rare root-access on either OS, most of which are privilege escalation. Maybe
one every week or two even attacks on either kernel from outside.
> But I still think it's fair to say that Linux is safer than Windows. Why?
I agree. It used to be Windows had about 2x the code and 2x the attacks found.
> For the simple reason that Linux is not such a popular *target* for attacks
> and malware as Windows is.
Yeah. UNIX had way, way more exploits back before Windows was a popular
internet presence. Every week there would be reports of credit card lists
being stolen from ISPs, viruses attacking sendmail, etc. Then it was
Netscape's servers. *Then* it was Windows, around the '98 timeframe.
And before that, floppy boot-sector viruses ran rampant amongst
microcomputer OSes, but I never heard of any of those being done for money.
> email virii
I saw a great rant from someone who actually knows Latin about "virii".
"Virii" is apparently the plural of some completely unrelated latin word,
like "voice" or "people" or something. "Virus" is apparently already a mass
noun not unlike "stuff".
> I bet it's well over half of them for the simple reason that
> Windows is way more widespread than Linux.
I think it's three things. 1 - There's more Windows desktops. 2 - People
with Linux desktops tend to be more clued and/or have someone administering
them that is clued. 3 - I suspect that most Linux machines are actually
servers that are quite locked down and rarely doing anything not
specifically planned.
I've run Windows servers whose only job was running the database, or answers
calls from credit card terminals, or etc, and it was trivial to lock them
down enough that you didn't have to worry much about exploits. It's when you
actually put someone in front of the keyboard who will surf web pages, run
stuff people email to them, and so on, that you get lots of infections.
Of course there are some break-ins, but I understand that most of them are
patched before they're actually exploited, and it's the people who didn't
patch that are the problem.
> (The only place where other
> systems might rival Windows as a target of crackers is in the web servers
> and other such servers, because there other systems are more popular than
> in desktop computers.)
That, and web servers have value in and of themselves. You can either
disrupt a rival, steal credit cards, etc. Hacking an individual desktop
machine only gives you what's on that machine (i.e., one person's financial
data) or one node of a bot-net.
> However, usually these cases are direct
> attacks by individual hackers, rather than being a massive attack by a
> self-spreading program.
Now, yes. It used to be way more common for even proprietary UNIXes to get
hit by viruses and worms than it is now for Windows, methinks.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> (And before anyone says anything, no, Windows is not better. Windows is
> year after year always at the top of the list of most security flaws found
> during the year.)
True, but the superiority of Linux crumbles in my eyes, if the responsible
people brush aside security holes that easily. I always had expected the Linux
community to have a basic mentality of "oops, right, our mistake; we'll fix
that of course", or at least "oops, right, this is problematic; we'll work
around that of course". But now they show that they, too, are more like "well,
that's not our fault; we won't fix it".
And knowing (through obvious proof) that the Linux kernel code isn't checked
with professional tools (or rather, probably is, but the results seem to be
brushed off and not taken seriously unless proven to be exploitable) doesn't
convince me of Linux' alleged superior security either.
I'm not saying "they're worse than Microsoft" - all I'm saying is "they're no
better".
Which is to say, "they're worse than what they claim and are percieved to
be". And as we all know, overestimating a system's security is a bad thing. If
you run two systems which are equally secure from a technical point of view but
one is percieved as more secure, that one will actually pose the higher security
threat.
(And what I'm also saying is that I think the commercial approach is
*potentially* better suited to produce secure software.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> But I still think it's fair to say that Linux is safer than Windows. Why?
> For the simple reason that Linux is not such a popular *target* for attacks
> and malware as Windows is. For example, basically 100% of email virii and
> http exploits have targetted Windows. I'd bet at least 99.99% of more
> traditional virii out there work only on Windows (and the older ones in
> DOS). Almost 100% of malware (spyware, adware, trojans, rootkits...) target
> Windows. While I have no idea how popular Windows as a target is among
> crackers, I bet it's well over half of them for the simple reason that
> Windows is way more widespread than Linux. (The only place where other
> systems might rival Windows as a target of crackers is in the web servers
> and other such servers, because there other systems are more popular than
> in desktop computers.)
I dare to disagree - I'd even postulate that Linux poses a *higher* security
risk than Windows.
Why?
Because Windows has its highest popularity on Desktops. Yeah, that makes great
targets, and a great number of them to set up bot networks.
But Linux systems, being the more popular among Web servers and such, are
typically a good deal closer to the infrastructure.
If you can infiltrate the very infrastrucuture of the web, this makes
infiltrating the end-user computers much easier.
So if some infiltrated Windows systems would be an inflammation, I'd liken some
infiltrated Linux systems to a sepsis.
Note that Web servers have already been infiltrated as meta-targets in order to
infiltrate end-user computers; if these attacks become more common and
sophisticated (and I expect they will), I'd care more about a secure Linux
kernel than I'd do about a secure Windows kernel.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> So if some infiltrated Windows systems would be an inflammation, I'd liken some
> infiltrated Linux systems to a sepsis.
Plus, it's generally a lot easier to infiltrate a web server using code
injection or something than it is to infiltrate a kernel. :-)
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> This happened to be some mips-specific assembly. Not exactly exotic, but
> then why are you changing that file if you don't have a mips chip to test it
> on in the first place?
In a commercial project, I'd say maybe because the developing company doesn't
have a mips system to test it on, and has made an agreement with one of its
customers who needs this fix. But still the change should not be included in
the main branch before the customer has confirmed that it does compile and fix
the issue.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> I dare to disagree - I'd even postulate that Linux poses a *higher* security
> risk than Windows.
> Why?
> Because Windows has its highest popularity on Desktops. Yeah, that makes great
> targets, and a great number of them to set up bot networks.
You are twisting the whole thing in a really strange way.
It doesn't change the fact that Linux is more secure for the average
user than Windows is, for the simple reason that Linux is not targetted
as much as Windows is.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > (And before anyone says anything, no, Windows is not better. Windows is
> > year after year always at the top of the list of most security flaws found
> > during the year.)
> True, but the superiority of Linux crumbles in my eyes, if the responsible
> people brush aside security holes that easily.
Then the answer is rather simple, isn't it: Don't use Linux.
> And knowing (through obvious proof) that the Linux kernel code isn't checked
> with professional tools
Define "professional tool".
> I'm not saying "they're worse than Microsoft" - all I'm saying is "they're no
> better".
That's BS. Basically every time a security hole is found in the linux kernel,
a patch appears in a matter of *hours*.
How soon do you get security patches for Windows when security flaws are
found? Certainly not within hours. At best within days, at worst within
months (yes, it has happened).
So yes, the linux community *is* better in security than MS is.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> It doesn't change the fact that Linux is more secure for the average
> user than Windows is, for the simple reason that Linux is not targetted
> as much as Windows is.
I think he's saying the average Linux user isn't the same as the average
Windows user, and the average Linux's user's machine is more valuable to
attack. You're just measuring two different ways.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> This happened to be some mips-specific assembly. Not exactly exotic, but
>> then why are you changing that file if you don't have a mips chip to test it
>> on in the first place?
>
> In a commercial project,
Sure. This isn't a commercial project, tho.
Actually, in my experience, it's really hard to find help with getting
consulting on Linux open source projects. There's just nobody willing to
rent you their experience with some piece of software, when they could
instead sell you some other software they wrote that's proprietary. The
whole idea that you'll make money with FOSS by selling consulting services
seems to not be very common at all.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> You are twisting the whole thing in a really strange way.
I'm not twisting the thing, I'm just twisting the perspective. And I wouldn't
call it strange, but rather just unconventional.
> It doesn't change the fact that Linux is more secure for the average
> user than Windows is, for the simple reason that Linux is not targetted
> as much as Windows is.
I'm not saying "Linux kernel needs more attention because it is less secure".
I'm saying "Linux kernel needs more attention because a breach of the Linux
kernel poses a higher security risk". Seen from a larger perspective than just
the rather egocentric "how safe is *my* individual computer" perspective.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> clipka <nomail@nomail> wrote:
> > Warp <war### [at] tagpovrayorg> wrote:
> > > (And before anyone says anything, no, Windows is not better. Windows is
> > > year after year always at the top of the list of most security flaws found
> > > during the year.)
>
> > True, but the superiority of Linux crumbles in my eyes, if the responsible
> > people brush aside security holes that easily.
>
> Then the answer is rather simple, isn't it: Don't use Linux.
No, the answer is rather, "Stop proclaiming that Linux' security is superior",
or "Get back to making Linux as secure as it is claimed to be".
> > And knowing (through obvious proof) that the Linux kernel code isn't checked
> > with professional tools
>
> Define "professional tool".
In this sense, roughly speaking anything that a professional SW developing
entity would be willing(!) to pay more money for than the average hobbyist
would be willing to spend.
Note that free software might qualify in this sense, too.
> > I'm not saying "they're worse than Microsoft" - all I'm saying is "they're no
> > better".
>
> That's BS. Basically every time a security hole is found in the linux kernel,
> a patch appears in a matter of *hours*.
Did you verify that assumption, or are you just repeating hearsay?
I see now a security hole which the top hats apparently weren't even *willing*
to fix, and flawed code which I assume would have been discovered earlier in a
commercial environment - so I'm throwing that hearsay overboard right now
because *that* seems to be BS.
> How soon do you get security patches for Windows when security flaws are
> found? Certainly not within hours. At best within days, at worst within
> months (yes, it has happened).
>
> So yes, the linux community *is* better in security than MS is.
By now I seriously doubt it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > email virii
>
> I saw a great rant from someone who actually knows Latin about "virii".
> "Virii" is apparently the plural of some completely unrelated latin word,
> like "voice" or "people" or something. "Virus" is apparently already a mass
> noun not unlike "stuff".
Actually, the word "virus" is taken from latin, originally meaning
"slime/poison/venom" ; the correct latin plural would be "vira", while "viri"
would be singular genitive; a double-i form ("virii") does not exist.
There's also a latin word having the plural form "viri" - that would be "vir",
meaning "man/hero"; again, no double-i form here.
If there existed a lating word with the plural form "virii", it would have to be
"viri" in singular. To the best of my knowledge, there is no such word in latin.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19-7-2009 21:17, Darren New wrote:
> Warp wrote:
>> It doesn't change the fact that Linux is more secure for the average
>> user than Windows is, for the simple reason that Linux is not targetted
>> as much as Windows is.
>
> I think he's saying the average Linux user isn't the same as the average
> Windows user, and the average Linux's user's machine is more valuable to
> attack. You're just measuring two different ways.
>
A third difference is that Linux administrators of those more critical
machines are generally more aware of threads and more knowledgeable.
<back to lurk mode for this thread>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> flawed code which I assume would have been discovered earlier in a
> commercial environment
Interestingly, I can imagine this particular flaw might be easier to find by
a bad guy in proprietary code. You can look at the machine code to see
there's no check for NULL in that routine.
If the source code is available, how many people are really going to look at
the generated machine code to see if security checks were optimized out by
the compiler? Obviously someone did, or came across it by accident, or
something. (I didn't read the original original report.)
Just a thought...
How many routines in Linux look like they check for buffer overrun but don't
because the compiler did something wrong or unexpected? Of those, how many
will people notice, compared to the legions of people single-stepping thru
IE.exe with a debugger looking for flaws? :-)
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And, of course, its now fixed
> The Linux folks have meanwhile:
>
> - Fixed the actual bug. ;) (CVE-2009-1897)
> Only affects 2.6.30,2.6.30.1.
>
> 2.6.30.2 release soon.
>
> - Added -fno-delete-null-pointers to their Makefiles
>
> Also in 2.6.30.2 and 2.
>
> - fixed the personality - PER_CLEAR_ON_SETTID inheritance issue (CVE-2009-1895)
> to work around mmap_min_addr protection.
> Affects 2.6.23-2.6.30.1
>
> 2.6.30.2 and 2.6.27.x releases soon.
>
> I am not sure about the SELinux policy error he used to
> exploit the RHEL 5.? Beta.
>
> Ciao, Marcus
I'm quoting from an email sent to me; I have no reason to distrust the
source
John
--
"Eppur si muove" - Galileo Galilei
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> clipka wrote:
> > flawed code which I assume would have been discovered earlier in a
> > commercial environment
>
> Interestingly, I can imagine this particular flaw might be easier to find by
> a bad guy in proprietary code. You can look at the machine code to see
> there's no check for NULL in that routine.
It may be interesting news to you that examining compiled piece of software is
just as easy with open-source software as it is with closed-source software...
;)
And knowing this particular compiler behavior, the bad guy's job has become a
whole lot easier with open-source software: Just get a good static
code-analysis tool and have it grind the code for places where pointers are
de-referenced without checking for NULL first.
*Then* dig through the compiled code to see if the compiler optimized away a
later check for NULL.
So however you toss and turn it: Breaking into any piece of software is easier
if it's open-source than if it's closed-source.
Butt also note that of course the *good* guys' job *should* be a lot easier with
open-source, too: Just get a good static code-analysis tool... (You know the
rest.) That's the very paradigm on which the alleged superior safety of open
source is founded: More eyes looking at the code will spot more of the bugs.
The problem - at least in this case - is that the good guys obviously didn't do
it. Or they didn't listen to one another when some of them did.
If that's how it typically works in reality, then as far as security is
concerned the whole superiority of the open source concept crumbles, leaving
only its disadvantages in this respect. Making software open source doesn't
improve security (or quality in general) *per se* - the good guys need to do
their homework, too.
> How many routines in Linux look like they check for buffer overrun but don't
> because the compiler did something wrong or unexpected? Of those, how many
> will people notice,
Yet how many more could a static code-analysis tool notice? Quite a lot, I bet.
Unless the compiler is outright buggy of course, but that would surface sooner
or later, too.
The major problems are code constructs that lead to undefined behavior according
to the C (or C++) standard specifications - because "undefined behavior" *by
definition* includes the potential for security breaches. Static code analysis
tools do a great job at identifying the use of such constructs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> It may be interesting news to you that examining compiled piece of software is
> just as easy with open-source software as it is with closed-source software...
Oh, I know that. I was just saying that many might not even look for
(essentially) compiler errors if they have the source.
> And knowing this particular compiler behavior, the bad guy's job has become a
> whole lot easier with open-source software: Just get a good static
> code-analysis tool and have it grind the code for places where pointers are
> de-referenced without checking for NULL first.
True. If you think of it.
> So however you toss and turn it: Breaking into any piece of software is easier
> if it's open-source than if it's closed-source.
Yes. Perhaps the word "easier" should have been "more likely."
> Yet how many more could a static code-analysis tool notice? Quite a lot, I bet.
Hopefully, people are running such static analysis tools on their
proprietary software too. :-)
> Unless the compiler is outright buggy of course, but that would surface sooner
> or later, too.
I understand the good folks at JPL actually *do* disassemble the machine
code the compiler generated and checks that it does what they think it does.
When you're sending something to Mars, it's probably worth it.
> Static code analysis
> tools do a great job at identifying the use of such constructs.
Well, not so good, no. At least, not in C. Otherwise, buffer overruns
wouldn't be the black hat's attack of choice for C programs.
You can make a language where it's a lot easier to find such things, tho,
even without a lot of runtime overhead.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Hopefully, people are running such static analysis tools on their
> proprietary software too. :-)
Hopefully, yes. And hopefully the QA guys running those tools are heard.
But given the cost of typical statc code analysis tools, you may be more likely
to find them in companies than in open-source projects.
> I understand the good folks at JPL actually *do* disassemble the machine
> code the compiler generated and checks that it does what they think it does.
> When you're sending something to Mars, it's probably worth it.
Definitely so: It's probably cheaper to have hordes of expensive experts inspect
every line of source code and every byte of compiled code - both with automatic
tools *and* manually - than it would be to send a "beta" satellite first. Let
alone that some missions are single-chance: A favorable planetary constellation
as with the Voyager probes won't come again anytime soon, for instance.
Maybe one problem with open source is also that its value is underestimated;
something like, "if it doesn't cost anything to code, how can it be worth
investing any money into QA?".
> > Static code analysis
> > tools do a great job at identifying the use of such constructs.
>
> Well, not so good, no. At least, not in C. Otherwise, buffer overruns
> wouldn't be the black hat's attack of choice for C programs.
Granted, some variants of these are indeed hard to identify even with static
code analysis tools. Other variants, though, are darn easy for these tools.
Anyway, we're talking about a thing here that is very simple to identify
automatically. And even *that* wasn't detected, or people who detected it
weren't listened to.
> You can make a language where it's a lot easier to find such things, tho,
> even without a lot of runtime overhead.
Sure, no argument here. One of the very few valid reasons for using C is that it
is extremely widespread; but this widespread use has significant side effects:
- It makes it (comparatively) easy to port code to virtually any target
platform. (Of course there's a circular thing here: C is the language of choice
when maximum portability is needed, because there's C compilers for virtually
all platforms; and there's C compilers for virtually all platforms because C is
the language of choice when maximum portability is needed. Still that's the way
it happens to be.) For a project like the Linux kernel that is aimed at high
portability, C/C++ therefore seems to be the *only* reasonable choice.
- The most common C compilers for the most common platforms are used so heavily
that even compiler bugs related to unconventional cases are still quite likely
to manifest soon.
Another reason is speed, of course, but just like with Assembler it could be
argued that only the most heavily-used portions of a project should resort to C
for speed these days.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Anyway, we're talking about a thing here that is very simple to identify
> automatically.
Certainly. And for that matter, it *was* identified automatically. It's just
that the wrong solution was taken. :-)
> For a project like the Linux kernel that is aimed at high portability,
Well, no. The Linux kernel wasn't started aimed at high portability. Just
the opposite, really.
> - The most common C compilers for the most common platforms are used so heavily
> that even compiler bugs related to unconventional cases are still quite likely
> to manifest soon.
True.
> Another reason is speed, of course, but just like with Assembler it could be
> argued that only the most heavily-used portions of a project should resort to C
> for speed these days.
Mmmm.... Debatable. :-) It really depends on the rest of the system. If
you're writing in some language fundamentally different from C, you might
spend more time translating into C data structures than you do to run it.
Nobody says "Wow, this SQL query is really slow. Let's rewrite it in C."
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > For a project like the Linux kernel that is aimed at high portability,
>
> Well, no. The Linux kernel wasn't started aimed at high portability. Just
> the opposite, really.
Yeah, but what is the *current* aim?
> > Another reason is speed, of course, but just like with Assembler it could be
> > argued that only the most heavily-used portions of a project should resort to C
> > for speed these days.
>
> Mmmm.... Debatable. :-) It really depends on the rest of the system. If
> you're writing in some language fundamentally different from C, you might
> spend more time translating into C data structures than you do to run it.
> Nobody says "Wow, this SQL query is really slow. Let's rewrite it in C."
I said, it *could* be argued. And BTW, *some* SQL queries are indeed easier to
do by just pumping the data into a C program and doing the filtering & sortng
manually (though generally you'd first have a look to see if you can somehow
improve performance by tweaking the DB, rephrasing the query, or the like).
And in general, serious languages tend to have *some* generic interface to
libraries written in C (though then again, some of these interfaces seem to be
pathological, as with Perl for instance; seen a colleague once struggling to
pass a NULL pointer or some such into a C API function).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Yeah, but what is the *current* aim?
From *my* experience, the current aim is to dick around with it for fun so
it takes several weeks of intense concentration and trial-and-error to get
each new point release to even compile.
> I said, it *could* be argued. And BTW, *some* SQL queries are indeed easier to
> do by just pumping the data into a C program and doing the filtering & sortng
> manually (though generally you'd first have a look to see if you can somehow
> improve performance by tweaking the DB, rephrasing the query, or the like).
Exactly. My point was that nobody rewrites a chunk of SQL in C. They pull
the data and manipulate it in C, which is rather different from cracking
open the RDBMS and modifying it to add their query as a SQL primitive. :-)
> And in general, serious languages tend to have *some* generic interface to
> libraries written in C
Sure, but that's because C is close to assembler. Anything with a reasonable
calling convention can do that, assuming the CPU is designed to run C. Most
of them also have some generic interface to Windows COM as well. I'm not
sure what the point is. :-)
LISP machines, Smalltalk machines, and FORTH machines all lack generic
interfaces to libraries written in C. :-)
> (though then again, some of these interfaces seem to be
> pathological, as with Perl for instance; seen a colleague once struggling to
> pass a NULL pointer or some such into a C API function).
Precisely my point. The farther from C your language gets, the less likely
you can easily invoke C.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's a whole description of the whole chain of events that led up to it
breaking. I don't know if it got posted before, but it's pretty interesting.
http://lwn.net/SubscriberLink/342330/f66e8ace8a572bcb/
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Here's a whole description of the whole chain of events that led up to it
> breaking. I don't know if it got posted before, but it's pretty interesting.
> http://lwn.net/SubscriberLink/342330/f66e8ace8a572bcb/
"But Herbert's patch added a line which dereferences the pointer prior
to the check. That, of course, is a bug."
That's what I thought. You can't blame a compiler optimization for
"screwing up" buggy code, even though without the optimization the bug
would perhaps not have been symptomatic by pure chance.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
