Linux kernel vulnerability!!!!!!!!!!
Amilius Klootendraaier
http://isc.sans.org/diary.html?storyid=6820
--
PLEASE VISIT OUR HALL OF LINUX IDIOTS:
http://linuxidiots.blogspot.com/
Phil Da Lick!
> A new *fascinating* Linux kernel vulnerability!
> http://isc.sans.org/diary.html?storyid=6820
>
Start the clock.
Peter Köhlmann
> A new *fascinating* Linux kernel vulnerability!
> http://isc.sans.org/diary.html?storyid=6820
>
It is no longer "new" in any shape or form.
And it is *extremely* easy to clamp down
In fact, the new kernels already are no longer suceptible to that
*compiler* flaw (it is no coding error, and the kernel only contains the
bug because the compiler optimizes the check-coding away)
So, out of possible point for trolling you get a -4 (because another
windows cretin already got a -3 for extremely dumb trolling with the same
subject)
--
Microsoft's Guide To System Design:
Making the world safe for competing operating systems.
Phil Da Lick!
> Amilius Klootendraaier wrote:
>
>> A new *fascinating* Linux kernel vulnerability!
>> http://isc.sans.org/diary.html?storyid=6820
>>
>
> It is no longer "new" in any shape or form.
> And it is *extremely* easy to clamp down
>
> In fact, the new kernels already are no longer suceptible to that
> *compiler* flaw (it is no coding error, and the kernel only contains the
> bug because the compiler optimizes the check-coding away)
>
>
> So, out of possible point for trolling you get a -4 (because another
> windows cretin already got a -3 for extremely dumb trolling with the same
> subject)
Stop the clock. Wow, negative score.
Heh. That'll teach me to take wintroll propoganda at face value. :P
Amilius Klootendraaier
news:h47p32$fvv$02$1...@news.t-online.com...
> Amilius Klootendraaier wrote:
>
>> A new *fascinating* Linux kernel vulnerability!
>> http://isc.sans.org/diary.html?storyid=6820
>>
>
> It is no longer "new" in any shape or form.
> And it is *extremely* easy to clamp down
>
> In fact, the new kernels already are no longer suceptible to that
> *compiler* flaw (it is no coding error, and the kernel only contains the
> bug because the compiler optimizes the check-coding away)
Ahh, good to know that all is secure now, on this one.
Isn't it a good moment in time to start some sort of "patch Tuesday" for
Linux distro's?
The number of bugs and security holes in Linux seems endless!
Get your facts straight, you moron!
http://pwnie-awards.org/2009/index.html
[q]
Linux SCTP FWD Chunk Memory Corruption; "Remote kernel memory corruption
vulnerabilities are rare"
Linux udev Netlink Message Privilege Escalation (CVE-2009-1185); Sebastian
Krahmer identified a vulnerability in udevd.
Red Hat Networks Backdoored OpenSSH Packages
Linux: Continually assuming that all kernel memory corruption bugs are only
Denial-of-Service
SCTP overflow resulting in reliable remote disabling of SELinux
*Improperly* *patching* a 7 year running local bypass of a flawed ASLR
implementation
Arbitrary root command execution via an environment variable
Silent disclosure of *numerous* kernel vulnerabilities.
[/q]
cc
wrote:
> Amilius Klootendraaier wrote:
> > A new *fascinating* Linux kernel vulnerability!
> >http://isc.sans.org/diary.html?storyid=6820
>
> It is no longer "new" in any shape or form.
> And it is *extremely* easy to clamp down
>
> In fact, the new kernels already are no longer suceptible to that
> *compiler* flaw (it is no coding error, and the kernel only contains the
> bug because the compiler optimizes the check-coding away)
>
> So, out of possible point for trolling you get a -4 (because another
> windows cretin already got a -3 for extremely dumb trolling with the same
> subject)
It is *NOT* a compiler flaw. It is undefined behavior in C to
dereference a NULL pointer. Since the check was made after the pointer
was dereferenced, the compiler is free to optimize the check away. If
the pointer had been NULL at that point, it would have already invoked
undefined behavior. It was a mistake in the code, plain and simple.
Tim Smith
Peter K�hlmann <peter-k...@t-online.de> wrote:
>
> In fact, the new kernels already are no longer suceptible to that
> *compiler* flaw (it is no coding error, and the kernel only contains the
> bug because the compiler optimizes the check-coding away)
Nonsense. It's a coding error, not a compiler flaw. Dereferencing a null
pointer in C is wrong, *period*.
--
--Tim Smith
Peter Köhlmann
Have you actually looked at the code?
There was a pointer assigned, and because of that the compiler optimized
the check away (for reason that if the pointer just got assigned, it is
useless to check if it is still ZERO).
Problem is, now the pointer could get assigned the address 0 without it
being flagged.
static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
struct sock *sk = tun->sk;
…
if (!tun)
return POLLERR;
The code was OK, it was simply not visible for the programmer that the
compiler would optimize it this way.
Had he switched the two lines, the code would have worked OK.
The kernels will now be compiled with "fno-delete-null-pointer-checks" to
make it impossible for the optimizer to eliminate those checks
Nope, Tim Hadron Smith, it was not a coding error, no matter how often you
would like to imply that
--
You're genuinely bogus.
Tim Smith
Peter Köhlmann <peter-k...@t-online.de> wrote:
>
> static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
>
> struct sock *sk = tun->sk;
If tun is null, the behavior of the above statement is undefined.
> …
> if (!tun)
> return POLLERR;
It is not an error for a compiler to optimize away code that can only be
executed when the program is in an undefined state.
--
--Tim Smith
Hadron
Peter, like Ahlstrom, knows little about C. They both think throwing
casts into C code to eliminate compiler warnings is the thing to
do. When I tried to explain the concept of proper typing and implicit
casting they got confused and scuttled off back to their basements.
--
http://www.faqs.org/faqs/windows-emulation/wine-faq/
"Nope, we know what an emulator does, and wine doesn't." - AH
** http://groups.google.com/group/comp.os.linux.advocacy/msg/dec7cb073d761af4
Hadron
You do realise Peter was, again, wrong? He doesn't understand the
concept of undefined behaviour in C and how, after it, all bets are off.
cc
wrote:
> Tim Smith wrote:
> > In article <h47p32$fvv$0...@news.t-online.com>,
> > Peter K hlmann <peter-koehlm...@t-online.de> wrote:
>
> >> In fact, the new kernels already are no longer suceptible to that
> >> *compiler* flaw (it is no coding error, and the kernel only contains
> >> the bug because the compiler optimizes the check-coding away)
>
> > Nonsense. It's a coding error, not a compiler flaw. Dereferencing a null
> > pointer in C is wrong, *period*.
>
> Have you actually looked at the code?
> There was a pointer assigned, and because of that the compiler optimized
> the check away (for reason that if the pointer just got assigned, it is
> useless to check if it is still ZERO).
> Problem is, now the pointer could get assigned the address 0 without it
> being flagged.
First, address 0 is not always NULL. Second, if the pointer was
assigned the NULL address, the first line of the code you quoted would
be undefined. Since it's undefined if it's NULL the compiler is free
to optimize the check away, since if the code had reached that point
and the pointer had been NULL, it would have invoked undefined
behavior.
> static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
>
> struct sock *sk = tun->sk;
> …
> if (!tun)
> return POLLERR;
>
> The code was OK, it was simply not visible for the programmer that the
> compiler would optimize it this way.
> Had he switched the two lines, the code would have worked OK.
Had he switched the two lines, it would not have been undefined
behavior.
> The kernels will now be compiled with "fno-delete-null-pointer-checks" to
> make it impossible for the optimizer to eliminate those checks
That is an extension outside of the C standard, which is perfectly
acceptable. You also fail to mention that a patch was issued to fix
this code (reverse the statements). The fact that the compiler
optimized it away using standard C is also perfectly acceptable.
> Nope, Tim Hadron Smith, it was not a coding error, no matter how often you
> would like to imply that
It is a coding error. The coder invoked undefined behavior. It is up
to the coder to either fix the undefined behavior, or find an
implementation that defines the behavior to their liking.
cc
> In article <h4923a$16t$0...@news.t-online.com>,
> Peter Köhlmann <peter-koehlm...@t-online.de> wrote:
>
>
>
> > static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
>
> > struct sock *sk = tun->sk;
>
> If tun is null, the behavior of the above statement is undefined.
>
> > …
> > if (!tun)
> > return POLLERR;
>
> It is not an error for a compiler to optimize away code that can only be
> executed when the program is in an undefined state.
>
As a side note, for those of you wondering how it would have ever
reached that statement anyway, if the pointer was NULL; the kernel
doesn't generate traps for dereferencing a NULL pointer. But the C
standard doesn't care how the Linux kernel (or any kernel) handles
dereferencing a NULL, which is why although it may not have generate a
trap, it is still undefined behavior.
Peter Köhlmann
> "Phil Da Lick!" <phil_t...@REMOVETHISSPAMTRAP.hotmail.com> writes:
>
>> Peter Köhlmann wrote:
>>> Amilius Klootendraaier wrote:
>>>
>>>> A new *fascinating* Linux kernel vulnerability!
>>>> http://isc.sans.org/diary.html?storyid=6820
>>>>
>>>
>>> It is no longer "new" in any shape or form.
>>> And it is *extremely* easy to clamp down
>>>
>>> In fact, the new kernels already are no longer suceptible to that
>>> *compiler* flaw (it is no coding error, and the kernel only contains
>>> the bug because the compiler optimizes the check-coding away)
>>>
>>>
>>> So, out of possible point for trolling you get a -4 (because another
>>> windows cretin already got a -3 for extremely dumb trolling with the
>>> same subject)
>>
>> Stop the clock. Wow, negative score.
>>
>> Heh. That'll teach me to take wintroll propoganda at face value. :P
>>
>
> You do realise Peter was, again, wrong? He doesn't understand the
> concept of undefined behaviour in C and how, after it, all bets are off.
>
It would only be "undefined" if the check for NULL would not exist.
The programmer could not know that the optimizer would throw away the
checks he made
--
Meddle not in the affairs of Dragons, For thou art crunchy, and good
with ketchup!
Peter Köhlmann
> cc <scat...@hotmail.com> writes:
>
>> On Jul 22, 3:25 pm, Peter Köhlmann <peter-koehlm...@t-online.de>
>> wrote:
>>> Amilius Klootendraaier wrote:
>>> > A new *fascinating* Linux kernel vulnerability!
>>> >http://isc.sans.org/diary.html?storyid=6820
>>>
>>> It is no longer "new" in any shape or form.
>>> And it is *extremely* easy to clamp down
>>>
>>> In fact, the new kernels already are no longer suceptible to that
>>> *compiler* flaw (it is no coding error, and the kernel only contains
>>> the bug because the compiler optimizes the check-coding away)
>>>
>>> So, out of possible point for trolling you get a -4 (because another
>>> windows cretin already got a -3 for extremely dumb trolling with the
>>> same subject)
>>
>>
>> It is *NOT* a compiler flaw. It is undefined behavior in C to
>> dereference a NULL pointer. Since the check was made after the pointer
>> was dereferenced, the compiler is free to optimize the check away. If
>> the pointer had been NULL at that point, it would have already invoked
>> undefined behavior. It was a mistake in the code, plain and simple.
>
> Peter, like Ahlstrom, knows little about C. They both think throwing
> casts into C code to eliminate compiler warnings is the thing to
> do. When I tried to explain the concept of proper typing and implicit
> casting they got confused and scuttled off back to their basements.
>
You might try to prove that bullshit by supplying links, liar Hadron Snot
Quark
--
Warning: 10 days have passed since your last Windows reinstall.
Chris Ahlstrom
this bit o' wisdom:
> Peter, like Ahlstrom, knows little about C. They both think throwing
> casts into C code to eliminate compiler warnings is the thing to
> do. When I tried to explain the concept of proper typing and implicit
> casting they got confused and scuttled off back to their basements.
I give that a 1 out of 10 on the trolling meter.
Why 1? It contains stuff that "Hadron" cannot know, like how much Peter and
I know about C, so he is simply ignoring our bona fide statements about
fairly long careers *crafting* C and C++, along with diligent study of
magazines and texts related to our chosen *craft*. And it contains lies
about what we have said. Deliberate lies, I might add, since "Hadron" is
using them simply for trolling.
Why not 0? I responded to it.
Also, it looks like "Hadron" has *still* not discovered where some of my
code is available. If he had, he could post excerpts here and complain
about them (and there are bits of code that people could complain about in a
legitimate manner).
As usual, all troll and no meat from "Hadron".
--
A horse! A horse! My kingdom for a horse!
-- Wm. Shakespeare, "Henry VI"
Hadron
> After takin' a swig o' grog, Hadron belched out
> this bit o' wisdom:
>
>> Peter, like Ahlstrom, knows little about C. They both think throwing
>> casts into C code to eliminate compiler warnings is the thing to
>> do. When I tried to explain the concept of proper typing and implicit
>> casting they got confused and scuttled off back to their basements.
>
> I give that a 1 out of 10 on the trolling meter.
>
> Why 1? It contains stuff that "Hadron" cannot know, like how much Peter and
> I know about C, so he is simply ignoring our bona fide statements about
> fairly long careers *crafting* C and C++, along with diligent study of
Crafting? Then why are you so ignorant when it comes to implicit casting?
> magazines and texts related to our chosen *craft*. And it contains lies
> about what we have said. Deliberate lies, I might add, since "Hadron" is
> using them simply for trolling.
But I know enough to know Koehlmann was wrong in this thread. And you
were wrong when you advised using casts to hide compiler warnings about
bad assignments.
As for lies? What lies? It seems you are telling them again. It's why
people call you Liarnut.
>
> Why not 0? I responded to it.
Yet a while back I was killfiled.
"Testing" the no killfile swtitch again? LOL!
>
> Also, it looks like "Hadron" has *still* not discovered where some of my
> code is available. If he had, he could post excerpts here and complain
> about them (and there are bits of code that people could complain about in a
> legitimate manner).
>
> As usual, all troll and no meat from "Hadron".
And yet its me that understands casting and mentioned the reality behind
using them. And me who recognises undefined bahavour which Peter claimed
was a compiler bug.
So 10/10 for sucking up to "advocates" without checking the truth.
Hadron
Hadron
Your ignorance is palpable.
It was a coding error pure and simple. The compiler was right. You were,
unsurprisingly, wrong. I expect Ahlstrom to come sniffing your arse and
back you up any minute.
Yip yip! Heel!
chrisv
> Quack snotted:
>>
>> Peter, like Ahlstrom, knows little about C. They both think throwing
>> casts into C code to eliminate compiler warnings is the thing to
>> do. When I tried to explain the concept of proper typing and implicit
>> casting they got confused and scuttled off back to their basements.
>
>I give that a 1 out of 10 on the trolling meter.
>
>Why 1? It contains stuff that "Hadron" cannot know, like how much Peter and
>I know about C, so he is simply ignoring our bona fide statements about
>fairly long careers *crafting* C and C++, along with diligent study of
>magazines and texts related to our chosen *craft*. And it contains lies
>about what we have said. Deliberate lies, I might add, since "Hadron" is
>using them simply for trolling.
>
>Why not 0? I responded to it.
>
>Also, it looks like "Hadron" has *still* not discovered where some of my
>code is available. If he had, he could post excerpts here and complain
>about them (and there are bits of code that people could complain about in a
>legitimate manner).
>
>As usual, all troll and no meat from "Hadron".
Yep. I was there. You explained your position thoroughly, and it was
the Quack asshole who "scuttled off" in defeat.
Of course, the truth of the matter won't stop him from lying about it.
Peter Köhlmann
Translation: You lied. Again
--
It's sweet to be remembered, but it's often cheaper to be forgotten.
Hadron
Time an time again you plead for links. Only to deny you saw them at a
later date.
So have you figured out undefined behaviour caused by dereferencing a
NULL pointer yet "C crafting guru" Kohlkopf?
Which compiler do you use to compile your Windows code?
Peter Köhlmann
Really? The code would only be "undefined" if there had only been attempts
to work with it. Simply assigning pointers is not at all "undefined". And
that was what happened here
And the programmer explicitly tried to catch the case where a NUll pointer
would be assigned, Unfortunately, because of the way the optimizer worked
this deliberate check was thrown away.
The programmer can stare on his code for thge rest of the century and not
see any obvious error. Because there was none
> It was a coding error pure and simple. The compiler was right.
Oh, it certainly was. Therefore the reason to disallow "optimizations" on
Null-pointer checks from now on in the kernel. Because it was a "coding
error".
Idiot
> You were, unsurprisingly, wrong.
Nope
> I expect Ahlstrom to come sniffing your arse and back you up any minute.
And again, Hadron Snot Quark can't stop from bringing in people he hates
> Yip yip! Heel!
>
Are you 12? Or don't you have reached the "mature" age yet?
--
Microsoft: The company that made email dangerous
And web browsing. And viewing pictures. And...
Peter Köhlmann
Again a lie from you
Apart from the fact that *other* people would be much more convinced of
you when you where able to supply support for your lunatic claims now and
then.
Strange though you never do. Because you can't. You lied
> So have you figured out undefined behaviour caused by dereferencing a
> NULL pointer yet "C crafting guru" Kohlkopf?
Idiot
> Which compiler do you use to compile your Windows code?
>
Which has what exactly to do with this?
--
Who the fuck is General Failure, and why is he reading my harddisk?
cc
wrote:
> Hadron wrote:
That is incorrect. It is undefined for any deference of a NULL
pointer. tun could have been NULL and it was dereferenced before it
was checked. I think you need to get a copy of the C standard.
cc
wrote:
> Hadron wrote:
No. The programmer tried to catch it, AFTER the NULL pointer would be
dereferenced. Ask any C guru, they will tell this is undefined
behavior.
> The programmer can stare on his code for thge rest of the century and not
> see any obvious error. Because there was none
Would you check for a NULL pointer after you dereferenced it?
> > It was a coding error pure and simple. The compiler was right.
>
> Oh, it certainly was. Therefore the reason to disallow "optimizations" on
> Null-pointer checks from now on in the kernel. Because it was a "coding
> error".
>
> Idiot
That reason was to prevent exploitations from occuring on undefined
code. They had to enable that extension of the C language, BECAUSE it
was undefined code.
Hadron
At this stage I am shaking my head in amazement and bewilderment. Such
an obvious coding error and somehow denied by Liarmutt and
Koehlmann. It's BASIC STUFF guys. And Liarmutt only recently wrote a
dissertation about how he "crafts" C code and "studies" articles about
it. Pity he doesn't seem to recognise UB when it slaps him in his face.
Tim Smith
Peter Köhlmann <peter-k...@t-online.de> wrote:
> Really? The code would only be "undefined" if there had only been attempts
> to work with it. Simply assigning pointers is not at all "undefined". And
> that was what happened here
Assigning null pointers is fine. Dereferencing them is not. The code in
question could dereference a null pointer:
struct sock * sk = tun->sk;
That's dereferencing tun. It is equivalent to:
struct sock * sk = (*tun).sk;
(There is one exception in the C99 standard. If E is a null pointer,
then &*E == E).
>
> And the programmer explicitly tried to catch the case where a NUll pointer
> would be assigned, Unfortunately, because of the way the optimizer worked
> this deliberate check was thrown away.
>
> The programmer can stare on his code for thge rest of the century and not
> see any obvious error. Because there was none
Every C programmer I know would have caught this in code review.
--
--Tim Smith
Peter Köhlmann
> In article <h49s28$qga$01$1...@news.t-online.com>,
> Peter Köhlmann <peter-k...@t-online.de> wrote:
>> Really? The code would only be "undefined" if there had only been
>> attempts to work with it. Simply assigning pointers is not at all
>> "undefined". And that was what happened here
>
> Assigning null pointers is fine. Dereferencing them is not. The code in
> question could dereference a null pointer:
>
> struct sock * sk = tun->sk;
>
> That's dereferencing tun. It is equivalent to:
>
> struct sock * sk = (*tun).sk;
Right. And still no harm done. And never would be, if the check is not
optimized away
> (There is one exception in the C99 standard. If E is a null pointer,
> then &*E == E).
>
>>
>> And the programmer explicitly tried to catch the case where a NUll
>> pointer would be assigned, Unfortunately, because of the way the
>> optimizer worked this deliberate check was thrown away.
>>
>> The programmer can stare on his code for thge rest of the century and
>> not see any obvious error. Because there was none
>
> Every C programmer I know would have caught this in code review.
>
Naturally. Hindsight is so much better
--
If you're right 90% of the time, why quibble about the remaining 3%?
Hadron
> In article <h49s28$qga$01$1...@news.t-online.com>,
Watch it Tim. Ahlstrom has been showing off explaining how he and Peter
study C articles and "craft" C code of the highest standard. Which is
amazing for someone who didn't understand how throwing casts at compiler
warnings is not generally a good idea since the warnings are explaining
how implicit casting is not working and there is a potential data clash.
cc
wrote:
> Tim Smith wrote:
> > In article <h49s28$qga$0...@news.t-online.com>,
> > Peter Köhlmann <peter-koehlm...@t-online.de> wrote:
> >> Really? The code would only be "undefined" if there had only been
> >> attempts to work with it. Simply assigning pointers is not at all
> >> "undefined". And that was what happened here
>
> > Assigning null pointers is fine. Dereferencing them is not. The code in
> > question could dereference a null pointer:
>
> > struct sock * sk = tun->sk;
>
> > That's dereferencing tun. It is equivalent to:
>
> > struct sock * sk = (*tun).sk;
>
> Right. And still no harm done. And never would be, if the check is not
> optimized away
>
The check is afterwards. I fail to see how you don't get this. tun->sk
would seg fault on 99% of systems if tun was NULL. The check would not
prevent this. The fact the it would not seg fault in Linux kernel code
is not important. gcc is not a Linux kernel compiler. It's a c
compiler (among other languages). The C standard says that if tun ==
NULL (*tun) is undefined. Therefore anything that would happen after
that statement would be undefined. Therefore that check is useless and
can be optimized away. Coder error.
Hadron
From some of his latest blunders we can only assume Peter is not, and
never was, a programmer. It would explain his inability to understand
how its not straightforward to just "replace the widget set" in Gnu SW
for something like Chrome OS. His thinking is indicative of that of most
freetards - "sure I can do it" and leaves things half arsed and
incomplete with zero adherence to QA and consistency standards lain down
by the various bodies.
cc
I don't know about not a programmer, but not a C programmer for sure.
Although I'm not sure in what language the construct in question would
be a compiler error and not a coder error. The C standard is obtuse,
but any C programmer who has learned about pointers should be able to
recognize that that code snippet invokes undefined behavior. Peter may
never have programmed in C, who knows. But I imagine by now that Peter
has realized his mistake, will not post in this thread anymore, and
will magically forget that this ever happened.
Hadron
I think you're too kind. *Anyone* who didn't recognise that the
dereferencing of the NULL pointer was a bad thing is not a
programmer. The rest is pretty much incidental.
Peter Köhlmann
> cc <scat...@hotmail.com> writes:
>
>> On Jul 23, 2:05 pm, Peter Köhlmann <peter-koehlm...@t-online.de>
>> wrote:
>>> Tim Smith wrote:
>>> > In article <h49s28$qga$0...@news.t-online.com>,
>>> > Peter Köhlmann <peter-koehlm...@t-online.de> wrote:
>>> >> Really? The code would only be "undefined" if there had only been
>>> >> attempts to work with it. Simply assigning pointers is not at all
>>> >> "undefined". And that was what happened here
>>>
>>> > Assigning null pointers is fine. Dereferencing them is not. The code
>>> > in question could dereference a null pointer:
>>>
>>> > struct sock * sk = tun->sk;
>>>
>>> > That's dereferencing tun. It is equivalent to:
>>>
>>> > struct sock * sk = (*tun).sk;
>>>
>>> Right. And still no harm done. And never would be, if the check is not
>>> optimized away
>>>
>>
>> The check is afterwards. I fail to see how you don't get this. tun->sk
>> would seg fault on 99% of systems if tun was NULL.
Why would it do that? The *memory* itself is never accessed
>> The check would not prevent this.
Sure it would
>> The fact the it would not seg fault in Linux kernel code
>> is not important.
It would, if the meory gets accessed. It doesn't get accessed with the
check in place
>> gcc is not a Linux kernel compiler. It's a c
>> compiler (among other languages). The C standard says that if tun ==
>> NULL (*tun) is undefined.
And? If you dereference tun->sk, then sock *sk is also just a pointer to
an NULL address. Still no harm done unless accessed
>> Therefore anything that would happen after
>> that statement would be undefined.
Right. *If* the memory gets accessed. Which the check which was optimized
away should prevent
>> Therefore that check is useless and
>> can be optimized away. Coder error.
You are a "C programmer" of Hadron Snot Quark proportions, it seems.
After all, you seem to think that placing NULL into a *pointer* gives
segfaults. Which is about as far from the truth as a typical Snot Glasser
statement. Or a Hadron Quark claim
Good that you are killfiled forever like your ass-buddy Snot Glasser.
You are equally worthless
> From some of his latest blunders we can only assume Peter is not, and
> never was, a programmer. It would explain his inability to understand
> how its not straightforward to just "replace the widget set" in Gnu SW
> for something like Chrome OS. His thinking is indicative of that of most
> freetards - "sure I can do it" and leaves things half arsed and
> incomplete with zero adherence to QA and consistency standards lain down
> by the various bodies.
>
Hilarious
--
Howe's Law: Everyone has a scheme that will not work.
Tim Smith
Peter Köhlmann <peter-k...@t-online.de> wrote:
> >
> > Every C programmer I know would have caught this in code review.
> >
>
> Naturally. Hindsight is so much better
Peter, I know they would have caught it because they HAVE caught that
kind of thing before in code review. In most environments in which C
code runs, dereferencing a null pointer causes an immediate crash of the
application, and so you HAVE to do your check for null before
dereferencing, or your program won't even work. (It would normally cause
a run time error in the kernel, too, because there normally isn't
anything at 0. The exploit code for the bug first gets something mapped
to 0).
The first thing you ask when you see a function use a pointer is "what
if this pointer is null?". You look for a test, and if you don't see
one, you check to see if there is something that guarantees the caller
will only pass a valid pointer.
It is then blatantly obvious if the check is misplaced, and comes after
the pointer has been used.
--
--Tim Smith
peterwn
<A_m_i_l_...@invalid.invalid> wrote:
> A new *fascinating* Linux kernel vulnerability!http://isc.sans.org/diary.html?storyid=6820
>
This vulnerability would potentially apply to any os kernel (or other
software) compiled with an optimising compiler
In any case the specific vulnerability was fixed long ago.
.
Tim Smith
Peter Köhlmann <peter-k...@t-online.de> wrote:
> >>
> >> The check is afterwards. I fail to see how you don't get this. tun->sk
> >> would seg fault on 99% of systems if tun was NULL.
>
> Why would it do that? The *memory* itself is never accessed
How do you think it gets the value of tun->sk without accessing the
memory?
Let's write a little test case:
struct sock {
int blah;
int bletch;
};
struct Foo {
int foo;
struct sock * sk;
};
int something(struct Foo * tun) {
struct sock * sk = tun->sk;
if ( ! tun ) {
return -1;
}
return sk->blah;
}
Here's the assembly code, without optimization:
.text
.globl _something
_something:
pushl %ebp
movl %esp, %ebp
subl $40, %esp
movl 8(%ebp), %eax # 8(%ebp) is tun, and it is now in %eax
movl 4(%eax), %eax # ...which is dereferenced to get sk
movl %eax, -12(%ebp)
cmpl $0, 8(%ebp) # here is the check for null tun
jne L2
movl $-1, -28(%ebp)
jmp L4
L2:
movl -12(%ebp), %eax
movl (%eax), %eax
movl %eax, -28(%ebp)
L4:
movl -28(%ebp), %eax
leave
ret
.subsections_via_symbols
Please explain how on an x86 the check, which comes two instructions
after the dereference, can change the outcome of the dereference.
...
> And? If you dereference tun->sk, then sock *sk is also just a pointer to
> an NULL address. Still no harm done unless accessed
Peter, this is the code in question:
struct sock *sk = tun->sk;
…
if (!tun)
return POLLERR; // if tun is NULL return error
Your posts on this would make sense if the code was this instead, and
the issue was whether or not sk is null:
struct sock *sk = tun->sk;
…
if (!sk)
return POLLERR; // if tun is NULL return error
Did you misread the code?
--
--Tim Smith
Hadron
> Hadron wrote:
>
>> cc <scat...@hotmail.com> writes:
>>
>>> On Jul 23, 2:05 pm, Peter Köhlmann <peter-koehlm...@t-online.de>
>>> wrote:
>>>> Tim Smith wrote:
>>>> > In article <h49s28$qga$0...@news.t-online.com>,
>>>> > Peter Köhlmann <peter-koehlm...@t-online.de> wrote:
>>>> >> Really? The code would only be "undefined" if there had only been
>>>> >> attempts to work with it. Simply assigning pointers is not at all
>>>> >> "undefined". And that was what happened here
>>>>
>>>> > Assigning null pointers is fine. Dereferencing them is not. The code
>>>> > in question could dereference a null pointer:
>>>>
>>>> > struct sock * sk = tun->sk;
>>>>
>>>> > That's dereferencing tun. It is equivalent to:
>>>>
>>>> > struct sock * sk = (*tun).sk;
>>>>
>>>> Right. And still no harm done. And never would be, if the check is not
>>>> optimized away
>>>>
>>>
>>> The check is afterwards. I fail to see how you don't get this. tun->sk
>>> would seg fault on 99% of systems if tun was NULL.
>
> Why would it do that? The *memory* itself is never accessed
YE GODS!!!!!!!!!!!
>
>>> The check would not prevent this.
>
> Sure it would
>
>>> The fact the it would not seg fault in Linux kernel code
>>> is not important.
>
> It would, if the meory gets accessed. It doesn't get accessed with the
> check in place
>
>>> gcc is not a Linux kernel compiler. It's a c
>>> compiler (among other languages). The C standard says that if tun ==
>>> NULL (*tun) is undefined.
>
> And? If you dereference tun->sk, then sock *sk is also just a pointer to
> an NULL address. Still no harm done unless accessed
>
>>> Therefore anything that would happen after
>>> that statement would be undefined.
>
> Right. *If* the memory gets accessed. Which the check which was optimized
> away should prevent
>
>>> Therefore that check is useless and
>>> can be optimized away. Coder error.
>
> You are a "C programmer" of Hadron Snot Quark proportions, it seems.
> After all, you seem to think that placing NULL into a *pointer* gives
> segfaults.
Nobody claims this.
You have now resorted to outright lies. Either that or you are MORE
clueless about C than even I gave you credit for.
This thread will stay to haunt you Peter "Kernighan and Ritchie peer and
C Guru" Koehlmann.
Hadron
> Peter, this is the code in question:
>
> struct sock *sk = tun->sk;
> …
> if (!tun)
> Â Â Â return POLLERR;Â // if tun is NULL return error
>
I simply can NOT believe he has programmed in C if he doesn't understand
this. This is entry level stuff that spotty grads are given to debug to
learn systems.
Clearly Peter does not understand the use of pointers and how the ->
automatically dereferences.
Simply shocking. I wonder where Ahlstrom is now?
Peter Köhlmann
> In article <h4aeoo$tu6$02$1...@news.t-online.com>,
> Peter Köhlmann <peter-k...@t-online.de> wrote:
>> >>
>> >> The check is afterwards. I fail to see how you don't get this.
>> >> tun->sk would seg fault on 99% of systems if tun was NULL.
>>
>> Why would it do that? The *memory* itself is never accessed
>
> How do you think it gets the value of tun->sk without accessing the
> memory?
>
Are you serious?
tun->sk is simply an offset into the "tun-structure"
It gets that *value* from including some header files.
Assigning sock *sk to tun->sk *never* ever accesses *any* memory
It simply sets the address into that pointer. No memory access to any
address in those pointes needed at all
And if you don't know such simple facts, just lets stop here. Because by
now you sound rather hadronesque
< snip bullshit >
--
Designed for Windows. No user serviceable parts inside. By design
Ezekiel
"Peter K�hlmann" <peter-k...@t-online.de> wrote in message
news:h4akc9$dou$01$1...@news.t-online.com...
>>> >>
>>> >> The check is afterwards. I fail to see how you don't get this.
>>> >> tun->sk would seg fault on 99% of systems if tun was NULL.
>>>
>>> Why would it do that? The *memory* itself is never accessed
>>
>> How do you think it gets the value of tun->sk without accessing the
>> memory?
>>
>
> Are you serious?
Are you? I've kept out of this thinking that you would realize your error
but instead you keep digging that hole deeper and deeper.
> tun->sk is simply an offset into the "tun-structure"
Correct. It's an offset to the value stored at "tun" plus the offset of the
"sk" member.
> It gets that *value* from including some header files.
WHAT???? How does some "header file" have the actual value that's stored
there?
It gets it's value from accessing the value stored in memory at offset "sk"
relative to the address of "tun".
And if "tun" is NULL then it's going to try and read NULL + offset(sk) which
is somewhere around memory location 0x00000008;
> Assigning sock *sk to tun->sk *never* ever accesses *any* memory
Bullshit. Where is the value of tun->sk stored??? It's stored in memory.
> It simply sets the address into that pointer. No memory access to any
> address in those pointes needed at all
Yes... because it needs to get the value of "sk" from somewhere. And that
value of "sk" is stored in memory at an offset of N-many bytes from the
value of "tun."
> And if you don't know such simple facts, just lets stop here.
You should have stopped a long time ago Mr. "C" programming expert.
> Because by
> now you sound rather hadronesque
Which is evidently orders of magnitude better than being K�hlmanneque.
Do show a sample code snipped of this that compiles and runs without
crashing.
Hadron
> "Peter Köhlmann" <peter-k...@t-online.de> wrote in message
> news:h4akc9$dou$01$1...@news.t-online.com...
>> Tim Smith wrote:
>>
>>> In article <h4aeoo$tu6$02$1...@news.t-online.com>,
> Which is evidently orders of magnitude better than being Köhlmanneque.
>
> Do show a sample code snipped of this that compiles and runs without
> crashing.
Simply amazing.
It was evident from his comments about Liarnut's understanding of when
casts ARE a good thing and when not that he had only a small knowledge
of C. As usual my suspicions of fraud and exaggeration on the part of
"advocates" is proven to be correct.
It is simply unbelievable that he didn't realise how dereferencing works
in C.
Peter Köhlmann
>
> "Peter K�hlmann" <peter-k...@t-online.de> wrote in message
> news:h4akc9$dou$01$1...@news.t-online.com...
>> Tim Smith wrote:
>>
>>> In article <h4aeoo$tu6$02$1...@news.t-online.com>,
>>> Peter K�hlmann <peter-k...@t-online.de> wrote:
>>>> >>
>>>> >> The check is afterwards. I fail to see how you don't get this.
>>>> >> tun->sk would seg fault on 99% of systems if tun was NULL.
>>>>
>>>> Why would it do that? The *memory* itself is never accessed
>>>
>>> How do you think it gets the value of tun->sk without accessing the
>>> memory?
>>>
>>
>> Are you serious?
>
> Are you? I've kept out of this thinking that you would realize your
> error but instead you keep digging that hole deeper and deeper.
>
>
>> tun->sk is simply an offset into the "tun-structure"
>
> Correct. It's an offset to the value stored at "tun" plus the offset of
> the "sk" member.
>
>
>> It gets that *value* from including some header files.
>
> WHAT???? How does some "header file" have the actual value that's stored
> there?
There is no "actual value" stored in "tun->sk"
"tun" is a structure build somewhere in memory, pointing to some address.
It is *not* that address itself
> It gets it's value from accessing the value stored in memory at offset
> "sk" relative to the address of "tun".
>
> And if "tun" is NULL then it's going to try and read NULL + offset(sk)
> which is somewhere around memory location 0x00000008;
>
Good. And now please address yourself at that warden next to your room.
You need a double dose of your meds
>
>> Assigning sock *sk to tun->sk *never* ever accesses *any* memory
> Bullshit. Where is the value of tun->sk stored??? It's stored in memory.
>
>> It simply sets the address into that pointer. No memory access to any
>> address in those pointes needed at all
> Yes... because it needs to get the value of "sk" from somewhere. And
> that value of "sk" is stored in memory at an offset of N-many bytes from
> the value of "tun."
Idiot.
tun-sk is simply a pointer. A pointer to an address somewhere
so "sk" is equally just a pointer. It is an offset into that "tun-
structure".
No memory access to "tun" is ever needed to get "tun->sk". If you assign
"sock *sk" to "tun->sk", all you are doing is setting it to the value of
"tun" plus the ofset of "sk" into "tun". No access to any memory of "tun"
will ever happen at this stage
>
>> And if you don't know such simple facts, just lets stop here.
> You should have stopped a long time ago Mr. "C" programming expert.
>
>> Because by
>> now you sound rather hadronesque
> Which is evidently orders of magnitude better than being K�hlmanneque.
>
> Do show a sample code snipped of this that compiles and runs without
> crashing.
Why? Because dimwits like you say so? Please keep to your "threading
code". You know nothing about that, and you know even less about pointers
Hadron
The point Peter is that to get the contents of the field you need to
dereference the area of memory that tun points to.
When tun is a NULL pointer *THAT* causes UB.
You clearly know NOTHING about C.
here:
http://home.netcom.com/~tjensen/ptr/ch5x.htm
If you need any help just ask.
Peter Köhlmann
Bullshit. What do you think header files are needed for?
"tun" is simply some structure in memory, pointing somewhere. If that
"somewhere" is a legal address or not is not known to the compiler at that
time
> When tun is a NULL pointer *THAT* causes UB.
>
> You clearly know NOTHING about C.
Fine. You know nothing about pointer arithmetics
> here:
>
> http://home.netcom.com/~tjensen/ptr/ch5x.htm
>
> If you need any help just ask.
>
Ask you? You must be kidding
--
Tact, n.:
The unsaid part of what you're thinking.
Ezekiel
> Ezekiel wrote:
>
>>
>> "Peter K?hlmann" <peter-k...@t-online.de> wrote in message
>> news:h4akc9$dou$01$1...@news.t-online.com...
>>> Tim Smith wrote:
>>>
>>>> In article <h4aeoo$tu6$02$1...@news.t-online.com>,
>>>>> >>
>>>>> >> The check is afterwards. I fail to see how you don't get this.
>>>>> >> tun->sk would seg fault on 99% of systems if tun was NULL.
>>>>>
>>>>> Why would it do that? The *memory* itself is never accessed
>>>>
>>>> How do you think it gets the value of tun->sk without accessing the
>>>> memory?
>>>>
>>>
>>> Are you serious?
>>
>> Are you? I've kept out of this thinking that you would realize your
>> error but instead you keep digging that hole deeper and deeper.
>>
>>
>>> tun->sk is simply an offset into the "tun-structure"
>>
>> Correct. It's an offset to the value stored at "tun" plus the offset of
>> the "sk" member.
>>
>>
>>> It gets that *value* from including some header files.
>>
>> WHAT???? How does some "header file" have the actual value that's stored
>> there?
>
> There is no "actual value" stored in "tun->sk"
Bullshit. There's a pointer stored at tun->sk. Pointers have values too you
know.
> "tun" is a structure build somewhere in memory, pointing to some address.
> It is *not* that address itself
Correct. It points to some address. And the code needs to *read* what
address is stored at tun->sk in order to assign it to another variable.
>> It gets it's value from accessing the value stored in memory at offset
>> "sk" relative to the address of "tun".
>>
>> And if "tun" is NULL then it's going to try and read NULL + offset(sk)
>> which is somewhere around memory location 0x00000008;
>>
>
> Good. And now please address yourself at that warden next to your room.
> You need a double dose of your meds
You need a "C programming for clueless idiots" book.
>>
>>> Assigning sock *sk to tun->sk *never* ever accesses *any* memory
>> Bullshit. Where is the value of tun->sk stored??? It's stored in memory.
>>
>>> It simply sets the address into that pointer. No memory access to any
>>> address in those pointes needed at all
>> Yes... because it needs to get the value of "sk" from somewhere. And
>> that value of "sk" is stored in memory at an offset of N-many bytes from
>> the value of "tun."
>
> Idiot.
That's ripe coming from someone who can't understand the simplest of C
programming basics.
> tun-sk is simply a pointer. A pointer to an address somewhere
Yes. It points to memory somewhere. And that "address" that it points to
needs to be *read* in order to assign it to another variable.
> so "sk" is equally just a pointer. It is an offset into that "tun-
> structure".
It's an assignment you idiot.
struct sock * sk = tun->sk;
In order to assign the variable "sk" the current value of tun->sk must be
read first in order to know what value to assign it to. If this were a
"reference" it would be a different story but given how you don't have a
clue about pointers I'm not going to further confuse you with references.
> No memory access to "tun" is ever needed to get "tun->sk".
It needs to read value that's stored at memory location "tun" plus the
offset of "sk" in order to get the value of tun->sk.
> If you assign
> "sock *sk" to "tun->sk", all you are doing is setting it to the value of
> "tun" plus the ofset of "sk" into "tun". No access to any memory of "tun"
> will ever happen at this stage
Bullshit. If true then you ought to be able to write a short code snipped
that doesn't SEGV when you run it. (Hint... why don't you have someone
write you a code snipped that does this before you keep making an even
bigger fool of yourself.)
>>> And if you don't know such simple facts, just lets stop here.
>> You should have stopped a long time ago Mr. "C" programming expert.
>>
>>> Because by
>>> now you sound rather hadronesque
>> Which is evidently orders of magnitude better than being K?hlmanneque.
>>
>> Do show a sample code snipped of this that compiles and runs without
>> crashing.
>
> Why? Because dimwits like you say so?
Because you would then realize that you are dead-wrong and you might have
enough sense to STFU instead of continuing to make a fool of yourself.
> Please keep to your "threading
> code". You know nothing about that, and you know even less about pointers
My threading code and my knowledge of pointers is just fine. I suggest you
actually learn something because you are making a complete fool of
yourself. Unfortunately you're so stupid that you don't realize how much of
a fool you actually are.
Do yourself a favor and have someone write that snipped of code for you.
Obviously you are too incompetent to do something like this yourself. When
the code crashes and burns at the line "tun->sk" you might have enough
common sense to shut the fuck up and run away for a few weeks in order to
save face.
Hadron
> "Peter Köhlmann" <peter-k...@t-online.de> wrote in message
Tim kindly broke it down to the assembler level to help Peter "Brian
Kernighan is not fit to lick my jack boots" Koehlmann.
We can but hope.
So much for Liarnut's claims about the two of them "crafting" the finest
C code known to man. Littered with UB and dangerous casts. Yuck.
Ezekiel
> Hadron wrote:
>
>> Peter K�hlmann <peter-k...@t-online.de> writes:
>>
>>> Ezekiel wrote:
>>>
>>>>
>>>> "Peter K?hlmann" <peter-k...@t-online.de> wrote in message
>>>> news:h4akc9$dou$01$1...@news.t-online.com...
>>>>> Tim Smith wrote:
>>>>>
>>>>>> In article <h4aeoo$tu6$02$1...@news.t-online.com>,
>>>>
>>>> Do show a sample code snipped of this that compiles and runs without
>>>> crashing.
>>>
>>> Why? Because dimwits like you say so? Please keep to your "threading
>>> code". You know nothing about that, and you know even less about
>>> pointers
>>
>> The point Peter is that to get the contents of the field you need to
>> dereference the area of memory that tun points to.
>
> Bullshit. What do you think header files are needed for?
So it knows what offset to add to "tun" in order to get "sk." But the
header file doesn't magically contain the actual value. The value needs to
be accessed at runtime from a valid readable memory location.
> "tun" is simply some structure in memory, pointing somewhere. If that
> "somewhere" is a legal address or not is not known to the compiler at
> that
> time
>> When tun is a NULL pointer *THAT* causes UB.
>>
>> You clearly know NOTHING about C.
>
> Fine. You know nothing about pointer arithmetics
Wow. At first I was going to give you the benefit of the doubt and simply
assume that you are too stupid to read code. But since *you* insist on
beating this dead horse it is abundantly clear that you know absolutely
NOTHING about C programming.
Ezekiel
"Hadron" <hadro...@gmail.com> wrote in message
news:h4ar0k$ba5$3...@news.eternal-september.org...
> "Ezekiel" <ze...@nosuchdomain.com> writes:
>
>> "Peter K�hlmann" <peter-k...@t-online.de> wrote in message
This C�ahlmann guy is an absolute idiot. For two reasons:
#1 - He's too stupid to understand that referencing this via a NULL pointer
causes a crash.
#2 - He doesn't have enough brains to actually "try this" or "test this"
himself and realize that he's wrong. Instead he continues arguing a point
that he can't possibly win and insists on making a bigger and bigger fool
out of himself.
It's funny listening to idiots like this try to discuss "programming." He
must have heard some real programmers talking about 'pointers' while he was
cleaning the urinals at the software company that he "works at" and now he
thinks that he knows something about the topic.
Being absolutely clueless is bad enough. But being so damn clueless that he
can't even tell that he's clueless after having been corrected a dozen
times is the sign of a true idiot.
Hadron
> Hadron wrote:
>
>>
>> The point Peter is that to get the contents of the field you need to
>> dereference the area of memory that tun points to.
>
> Bullshit. What do you think header files are needed for?
Err, to tell the compiler how to calculate the offset in this case ....
> "tun" is simply some structure in memory, pointing somewhere. If that
> "somewhere" is a legal address or not is not known to the compiler at that
> time
No. Tun is a pointer. It is not a structure.
If you could read function prototypes you would know this.
"struct Foo * tun"
tun is a pointer to a structure of type Foo.
Elementary stuff.
It should point to a structure in memory. Its value here is
NULL. Therefore it does NOT point to a valid structure. THEREFORE an
attempt to access an element of a non existent structure fails. All
COMPETENT C programmers do rudimentary checks somewhere in the call
stack to ensure the pointer used is not NULL. I find it astonishing you
do not know this.
>
>> When tun is a NULL pointer *THAT* causes UB.
>>
>> You clearly know NOTHING about C.
>
> Fine. You know nothing about pointer arithmetics
>
This is simply ridiculous. Is someone forging Peter? He knows jack shit
about C. And earlier he was boasting about his abilities with it.
Please stop now.
>> here:
>>
>> http://home.netcom.com/~tjensen/ptr/ch5x.htm
>>
>> If you need any help just ask.
>>
>
> Ask you? You must be kidding
No. Really. You clearly have some real difficulties with C.
I have a formidable background in machine code/assembler and so can
explain how pointers work in a manner which might make it clearer to you
since you are clearly confused.
cc
wrote:
> Hadron wrote:
Yes it does. tun->sk accesses the memory.
> >> gcc is not a Linux kernel compiler. It's a c
> >> compiler (among other languages). The C standard says that if tun ==
> >> NULL (*tun) is undefined.
>
> And? If you dereference tun->sk, then sock *sk is also just a pointer to
> an NULL address. Still no harm done unless accessed
>
> >> Therefore anything that would happen after
> >> that statement would be undefined.
>
> Right. *If* the memory gets accessed. Which the check which was optimized
> away should prevent
No it wouldn't. tun->sk accesses the memory already. You need to pick
up a book on C.
cc
wrote:
> Tim Smith wrote:
> > In article <h4aeoo$tu6$0...@news.t-online.com>,
> > Peter Köhlmann <peter-koehlm...@t-online.de> wrote:
>
> >> >> The check is afterwards. I fail to see how you don't get this.
> >> >> tun->sk would seg fault on 99% of systems if tun was NULL.
>
> >> Why would it do that? The *memory* itself is never accessed
>
> > How do you think it gets the value of tun->sk without accessing the
> > memory?
>
> Are you serious?
>
> tun->sk is simply an offset into the "tun-structure"
> It gets that *value* from including some header files.
>
> Assigning sock *sk to tun->sk *never* ever accesses *any* memory
> It simply sets the address into that pointer. No memory access to any
> address in those pointes needed at all
It assigned tun->sk to *sk, no the other way around. It's equivalent
to (*tun).sk. How is (*tun) not accessing memory?
cc
wrote:
> Ezekiel wrote:
>
> > "Peter K hlmann" <peter-koehlm...@t-online.de> wrote in message
> >news:h4akc9$dou$01$1...@news.t-online.com...
> >> Tim Smith wrote:
>
> >>> Peter K hlmann <peter-koehlm...@t-online.de> wrote:
>
> >>>> >> The check is afterwards. I fail to see how you don't get this.
> >>>> >> tun->sk would seg fault on 99% of systems if tun was NULL.
>
> >>>> Why would it do that? The *memory* itself is never accessed
>
> >>> How do you think it gets the value of tun->sk without accessing the
> >>> memory?
>
> >> Are you serious?
>
> > Are you? I've kept out of this thinking that you would realize your
> > error but instead you keep digging that hole deeper and deeper.
>
> >> tun->sk is simply an offset into the "tun-structure"
>
> > Correct. It's an offset to the value stored at "tun" plus the offset of
> > the "sk" member.
>
> >> It gets that *value* from including some header files.
>
> > WHAT???? How does some "header file" have the actual value that's stored
> > there?
>
> There is no "actual value" stored in "tun->sk"
> "tun" is a structure build somewhere in memory, pointing to some address.
> It is *not* that address itself
Ahh, I see your confusion. tun is not a structure, tun is an instance
of the structure. It has to exist in memory as an "object."
cc
wrote:
> Hadron wrote:> >>> "Peter K hlmann" <peter-koehlm...@t-online.de> wrote in message
> >>>news:h4akc9$dou$01$1...@news.t-online.com...
> >>>> Tim Smith wrote:
>
"tun" is the name, not the type. The fact that it may or may not be a
legal address is the entire point of the compiler optimization that
you call an error. If it is a legal address, then the check afterwards
is not needed. If it points to NULL, then the check afterwards is not
needed because tun has already been dereferenced when accessing the sk
field, causing undefined behavior.
> > When tun is a NULL pointer *THAT* causes UB.
>
> > You clearly know NOTHING about C.
>
> Fine. You know nothing about pointer arithmetics
You're insane if you think has something to do with pointer
arithmetic. Ask around in comp.lang.c and see what they tell you about
this.
Ezekiel
>"cc" <scat...@hotmail.com> wrote in message
>news:d7b1d004-4701-43fd...@b14g2000yqd.googlegroups.com...
>On Jul 23, 6:55 pm, Peter K�hlmann <peter-koehlm...@t-online.de>
>wrote:
>>
>> > You clearly know NOTHING about C.
>>
>> Fine. You know nothing about pointer arithmetics
>
>You're insane if you think has something to do with pointer
>arithmetic.
> Ask around in comp.lang.c and see what they tell
> you about this.
Brilliant idea. I should monitor that newsgroup so that I can see Koahlmann
get his ass laughed right out of there when he starts telling the people
there how he's right and they know nothing about C or "pointer
arithmetics."
That'll be more entertaining than the movie of the week.
Please Peter... PLEASE!!! Go over to comp.lang.c and tell everyone how
they're clueless because you think that it's okay to access data through a
NULL pointer.
Tim Smith
Peter Köhlmann <peter-k...@t-online.de> wrote:
> >
> > How do you think it gets the value of tun->sk without accessing the
> > memory?
> >
>
> Are you serious?
>
> tun->sk is simply an offset into the "tun-structure"
> It gets that *value* from including some header files.
>
> Assigning sock *sk to tun->sk *never* ever accesses *any* memory
> It simply sets the address into that pointer. No memory access to any
> address in those pointes needed at all
No, what you are describing is what *this* code would do:
sock *sk = &tun->sk;
We are talking about THIS code:
sock *sk = tun->sk;
--
--Tim Smith
Tim Smith
Hadron <hadro...@gmail.com> wrote:
>
> Tim kindly broke it down to the assembler level to help Peter "Brian
> Kernighan is not fit to lick my jack boots" Koehlmann.
>
> We can but hope.
There is actually one way that this code:
struct sock * sk = tun->sk;
could *NOT* dereference tun. That would be if the sk member of the tun
struct were an array. In that case, the code would be equivalent to
struct sock * sk = &(tun->sk[0]);
That would not dereference tun. However, that's not the case. Here is
the tun structure:
struct tun_struct {
struct tun_file *tfile;
unsigned int flags;
uid_t owner;
gid_t group;
struct sk_buff_head readq;
struct net_device *dev;
struct fasync_struct *fasync;
struct tap_filter txflt;
struct sock *sk;
struct socket socket;
#ifdef TUN_DEBUG
int debug;
#endif
};
and thus, all the code
struct sock * sk = tun->sk;
is doing is copying a sock * from the tun_struct pointed to by tun to
the local sock * variable named sk. It is exactly equivalent to this
code:
struct sock * sk = (*tun).sk;
What is confusing Peter is the the sk member of tun holds a pointer. He
would perhaps be less confused if the code involved a different element
of tun, such as
unsigned int flags = tun->flags;
Even Peter should be able to see that this dereferences tun.
--
--Tim Smith
Peter Köhlmann
Right. It needs to address the memory location of the object "tun" and add
the offset of "sk"
Which still is *not* accessing the memory tun *points* to
>> "tun" is simply some structure in memory, pointing somewhere. If that
>> "somewhere" is a legal address or not is not known to the compiler at
>> that
>> time
>
>>> When tun is a NULL pointer *THAT* causes UB.
>>>
>>> You clearly know NOTHING about C.
>>
>> Fine. You know nothing about pointer arithmetics
>
> Wow. At first I was going to give you the benefit of the doubt and
> simply assume that you are too stupid to read code. But since *you*
> insist on beating this dead horse it is abundantly clear that you know
> absolutely NOTHING about C programming.
You keep on claiming that assigning a Null-pointer to an object or a
structure or whatever is already triggering the segfault.
That is bullshit of the highest order.
*Accessing* the memory "tun" points to is doing that, not assigning the
value
--
Avoid reality at all costs.
Hadron
Not its not.
tun is a pointer to an instance of the structure (and in common verbiage you
can remove the "instance of" too). Or should be. When NULL it's
not.... it's a pointer of type "pointer to a Foo struct".
cc
wrote:
> Ezekiel wrote:
>
> > "Peter K hlmann" <peter-koehlm...@t-online.de> wrote in message
> >news:h4apo9$np6$01$1...@news.t-online.com...
> >> Hadron wrote:> >>>>> "Peter K?hlmann" <peter-koehlm...@t-online.de> wrote in message
> >>>>>news:h4akc9$dou$01$1...@news.t-online.com...
> >>>>>> Tim Smith wrote:
>
No, that is not what it does. It accesses the pointer tun, to see what
address is there. Then it goes to that address, accessing the memory +
the offset sk. So if tun is NULL (*NULL).sk is accessed. That would
segfault in any userland program in Linux. That is undefined in
standard C.
> >> "tun" is simply some structure in memory, pointing somewhere. If that
> >> "somewhere" is a legal address or not is not known to the compiler at
> >> that
> >> time
>
> >>> When tun is a NULL pointer *THAT* causes UB.
>
> >>> You clearly know NOTHING about C.
>
> >> Fine. You know nothing about pointer arithmetics
>
> > Wow. At first I was going to give you the benefit of the doubt and
> > simply assume that you are too stupid to read code. But since *you*
> > insist on beating this dead horse it is abundantly clear that you know
> > absolutely NOTHING about C programming.
>
> You keep on claiming that assigning a Null-pointer to an object or a
> structure or whatever is already triggering the segfault.
That is not what anyone is claiming. We are claiming that deferencing
a NULL pointer is undefined. Assigning a NULL pointer is not the
issue.
> That is bullshit of the highest order.
> *Accessing* the memory "tun" points to is doing that, not assigning the
> value
If you're not a C programmer, then hopefully this discussion has been
informative for you. If you ask in any group dedicated to C they will
tell you the exact same thing we are here. If you read any book on C
beyond the beginners level, you would find the same information. We
are 100% right on this, I'm sorry to say.
If you are a C programmer, then this discussion is very unfortunate
and a stinging blow to whatever institution educated you.
cc
http://groups.google.com/group/comp.lang.c/msg/ca9424d08597b1dc?hl=en&dmode=source
You're welcome.
Chris Ahlstrom
this bit o' wisdom:
> Crafting? Then why are you so ignorant when it comes to implicit casting?
You asked for proof of yourself posting lies.
Done.
> But I know enough to know Koehlmann was wrong in this thread. And you
> were wrong when you advised using casts to hide compiler warnings about
> bad assignments.
Lie repeated.
> As for lies? What lies? It seems you are telling them again. It's why
> people call you Liarnut.
Actually, only you and "Moshe" and the one person who is crazier than all of
you nutcases, Clogwog, do that.
To me, the conclusion is clear. You are all nuts.
>> Why not 0? I responded to it.
>
> Yet a while back I was killfiled.
>
> "Testing" the no killfile swtitch again? LOL!
Nah, I was wondering why eternal-september.org was clobbering your posts for
awhile.
>> Also, it looks like "Hadron" has *still* not discovered where some of my
>> code is available. If he had, he could post excerpts here and complain
>> about them (and there are bits of code that people could complain about in a
>> legitimate manner).
>>
>> As usual, all troll and no meat from "Hadron".
>
> And yet its me that understands casting and mentioned the reality behind
> using them. And me who recognises undefined bahavour which Peter claimed
> was a compiler bug.
>
> So 10/10 for sucking up to "advocates" without checking the truth.
Thanks for claiming you are a good C programmer who apparently cannot
manage to Google for C code.
That, my friend, is a real laugh.
--
Having nothing, nothing can he lose.
-- William Shakespeare, "Henry VI"
Chris Ahlstrom
this bit o' wisdom:
> Hadron wrote:
>>
>> Time an time again you plead for links. Only to deny you saw them at a
>> later date.
>
> Again a lie from you
> Apart from the fact that *other* people would be much more convinced of
> you when you where able to supply support for your lunatic claims now and
> then.
>
> Strange though you never do. Because you can't. You lied
>
>> So have you figured out undefined behaviour caused by dereferencing a
>> NULL pointer yet "C crafting guru" Kohlkopf?
>
> Idiot
>
>> Which compiler do you use to compile your Windows code?
>>
>
> Which has what exactly to do with this?
Interesting. Reading "Hadron" for the last few days, he was almost
reasonable (except in the Wally thread). Then, once I start responding to
him, he goes straight into Insane Quark Troll mode.
And he seems almost *happy*!
It looks like I fulfill some morbid need in "Hadron"'s "soul".
Give us a kiss, love.
--
Try to have as good a life as you can under the circumstances.
Chris Ahlstrom
this bit o' wisdom:
> Yip yip! Heel!
(Usenet Tourette syndrom?)
--
FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #15
A: The Royal Canadian Mounted Police.
Q: What was the greatest achievement in taxidermy?
Chris Ahlstrom
this bit o' wisdom:
> ...somehow denied by Liarmutt...
LOL.
--
Consider well the proportions of things. It is better to be a young June-bug
than an old bird of paradise.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
Chris Ahlstrom
this bit o' wisdom:
> It is then blatantly obvious if the check is misplaced, and comes after
> the pointer has been used.
I'm skipping all the cackling insults from "Hadron". Whatever he knows
about code, he is nonetheless a lunatic. Mad as a hatter.
Here's the code (again):
http://xorl.wordpress.com/2009/07/17/linux-kernel-devnettun-null-pointer-dereference/
struct tun_struct *tun = __tun_get(tfile);
struct sock *sk = tun->sk;
unsigned int mask = 0;
if (!tun)
return POLLERR;
If tun is 0, and the kernel doesn't have read permission at
offet sk, it'll blow up.
I think Peter, in this case, is so against /anything/ that the insane Quark
troll says that he can't even look at your assembler code objectively.
--
You two ought to be more careful--your love could drag on for years and years.
Chris Ahlstrom
this bit o' wisdom:
> Chris Ahlstrom wrote:
>
>> Quack snotted:
>>>
>>> Peter, like Ahlstrom, knows little about C. They both think throwing
>>> casts into C code to eliminate compiler warnings is the thing to
>>> do. When I tried to explain the concept of proper typing and implicit
>>> casting they got confused and scuttled off back to their basements.
>
> Yep. I was there. You explained your position thoroughly, and it was
> the Quack asshole who "scuttled off" in defeat.
>
> Of course, the truth of the matter won't stop him from lying about it.
And repeatedly. He's played this same outright lie nearly a dozen times.
I find it pretty interesting that there was a lull in his behavior until I
started responding. Then "Hadron" went nuts. I've preserved a few of his
crazy cacklings for posterity.
Maybe he is bipolar?
--
Domestic happiness and faithful friends.
Chris Ahlstrom
this bit o' wisdom:
> This thread will stay to haunt you Peter "Kernighan and Ritchie peer and
> C Guru" Koehlmann.
Sigh. I'm afraid so.
"Hadron" is insufferable enough when he is /wrong/....
--
You will have long and healthy life.
chrisv
> Quack snotted:
>>
>> ...somehow denied by Liarmutt...
>
>LOL.
The trolling POS is quite obsessed with you, isn't he?
--
"Well, to tell the truth, I would be one of the first to sign up as a
Bill Gates fan if there were a club being formed." - Rat
chrisv
>And repeatedly. He's played this same outright lie nearly a dozen times.
Typical. Quack will lie, lie, lie, and than ask "what lies"?
>I find it pretty interesting that there was a lull in his behavior until I
>started responding. Then "Hadron" went nuts. I've preserved a few of his
>crazy cacklings for posterity.
>
>Maybe he is bipolar?
Half shit, half snot?
chrisv
> Hadron snotted:
>
>> This thread will stay to haunt you Peter "Kernighan and Ritchie peer and
>> C Guru" Koehlmann.
>
>Sigh. I'm afraid so.
>
>"Hadron" is insufferable enough when he is /wrong/....
When has the Wintard not been /wrong/?
The only difference this time is that it's a technical issue.
cc
> After takin' a swig o' grog, Tim Smith belched out
> this bit o' wisdom:
>
> > It is then blatantly obvious if the check is misplaced, and comes after
> > the pointer has been used.
>
> I'm skipping all the cackling insults from "Hadron". Whatever he knows
> about code, he is nonetheless a lunatic. Mad as a hatter.
>
> Here's the code (again):
>
>
> struct tun_struct *tun = __tun_get(tfile);
> struct sock *sk = tun->sk;
> unsigned int mask = 0;
> if (!tun)
> return POLLERR;
>
> If tun is 0, and the kernel doesn't have read permission at
> offet sk, it'll blow up.
Again, it doesn't matter whether the kernel has read permission or
not. Standard C says that if it was NULL, then anything that happens
after it's dereferenced is undefined behavior. So it could optimize
the check away. In fact, the kernel won't blow up if tun is NULL, but
the compiler doesn't know or care about that.
> I think Peter, in this case, is so against /anything/ that the insane Quark
> troll says that he can't even look at your assembler code objectively.
>
Peter has a hard time admitting he was wrong.
Chris Ahlstrom
this bit o' wisdom:
> Chris Ahlstrom wrote:
>
>> Quack snotted:
>>>
>>> ...somehow denied by Liarmutt...
>>
>>LOL.
>
> The trolling POS is quite obsessed with you, isn't he?
Maybe "Hadron" fancies me tallywhacker?
--
They have been at a great feast of languages, and stolen the scraps.
-- William Shakespeare, "Love's Labour's Lost"
Chris Ahlstrom
this bit o' wisdom:
> On Jul 24, 2:16?pm, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>
>> ? ?struct tun_struct *tun = __tun_get(tfile);
>> ? ?struct sock *sk = tun->sk;
>> ? ?unsigned int mask = 0;
>> ? ?if (!tun)
>> ? ? ? return POLLERR;
>>
>> If tun is 0, and the kernel doesn't have read permission at
>> offet sk, it'll blow up.
>
> Again, it doesn't matter whether the kernel has read permission or
> not. Standard C says that if it was NULL, then anything that happens
> after it's dereferenced is undefined behavior.
It's /undefined/. The compiler will most likely do this operation:
*(0 + offset(sk))
The expression in the outer parentheses is not null.
> So it could optimize the check away. In fact, the kernel won't blow up if
> tun is NULL, but the compiler doesn't know or care about that.
>
>> I think Peter, in this case, is so against /anything/ that the insane Quark
>> troll says that he can't even look at your assembler code objectively.
>
> Peter has a hard time admitting he was wrong.
That too.
--
It is by the fortune of God that, in this country, we have three benefits:
freedom of speech, freedom of thought, and the wisdom never to use either.
-- Mark Twain
cc
> After takin' a swig o' grog, cc belched out
> this bit o' wisdom:
>
> > On Jul 24, 2:16?pm, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>
> >> ? ?struct tun_struct *tun = __tun_get(tfile);
> >> ? ?struct sock *sk = tun->sk;
> >> ? ?unsigned int mask = 0;
> >> ? ?if (!tun)
> >> ? ? ? return POLLERR;
>
> >> If tun is 0, and the kernel doesn't have read permission at
> >> offet sk, it'll blow up.
>
> > Again, it doesn't matter whether the kernel has read permission or
> > not. Standard C says that if it was NULL, then anything that happens
> > after it's dereferenced is undefined behavior.
>
> It's /undefined/. The compiler will most likely do this operation:
That's what I just said.
> *(0 + offset(sk))
No, that's not what the compiler does. The compiler does (*tun).sk,
which does *(0) first, which would be undefined. What it does after
that is anyone's guess.
Alexander Terekhov
Tim Smith wrote:
>
> In article <h4akc9$dou$01$1...@news.t-online.com>,
> Peter Köhlmann <peter-k...@t-online.de> wrote:
> > >
> > > How do you think it gets the value of tun->sk without accessing the
> > > memory?
> > >
> >
> > Are you serious?
> >
> > tun->sk is simply an offset into the "tun-structure"
> > It gets that *value* from including some header files.
> >
> > Assigning sock *sk to tun->sk *never* ever accesses *any* memory
> > It simply sets the address into that pointer. No memory access to any
> > address in those pointes needed at all
>
> No, what you are describing is what *this* code would do:
>
> sock *sk = &tun->sk;
IIRC, the standard C/C++ contemplates implementations which validate
pointers when the program "simply sets the address" such that the
program may trap at that point if the pointer value is invalid. That is
why a pointer to a dealocated object is said to be "indeterminate" (may
have trap representation) and is noncopyable as a pointer. On
implementations which trap on &(tun=NULL)->sk (constant value and not
NULL) pointer store, removal of subsequent check for tun==NULL is quite
reasonable. So it's a good idea to put the check for tun==NULL before
"sock *sk = &tun->sk;" if tun can be NULL.
>
> We are talking about THIS code:
>
> sock *sk = tun->sk;
regards,
alexander.
--
http://gng.z505.com/index.htm
(GNG is a derecursive recursive derecursion which pwns GNU since it can
be infinitely looped as GNGNGNGNG...NGNGNG... and can be said backwards
too, whereas GNU cannot.)
Chris Ahlstrom
this bit o' wisdom:
> On Jul 24, 4:25?pm, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>
>> It's /undefined/. ?The compiler will most likely do this operation:
>
> That's what I just said.
>
>> *(0 + offset(sk))
>
> No, that's not what the compiler does. The compiler does (*tun).sk,
> which does *(0) first, which would be undefined. What it does after
> that is anyone's guess.
Why guess? Let's see what the compiler does with a some test code.
Here's a little C module and the assembler it generates (on a 64-bit AMD
CPU):
#include <stddef.h> // offsetof() macro
struct tun_t
{
int ak;
};
int main ()
{
struct tun_t tunobject;
struct tun_t * tun = &tunobject; // lea -0x20(%rbp),%rax
int offak = (int) offsetof(struct tun_t, ak); // movl $0x0,-0x4(%rbp)
tun->ak = 5; // mov -0x10(%rbp),%rax
// movl $0x5,(%rax)
(*tun).ak = 5; // mov -0x10(%rbp),%rax
// movl $0x5,(%rax)
*( (int *) (tun + offak)) = 5; // mov -0x10(%rbp),%rdx
// load offak into EAX // mov -0x4(%rbp),%eax
// sign-extend EAX to quad in RAX // cltq
// double it // shl $0x2,%rax
// put the final address in RAX // lea (%rdx,%rax,1),%rax
// stick 5 in it // movl $0x5,(%rax)
return 0; // mov $0x0,%eax
// leaveq
// retq
}
The last case (the one I claimed) is rendered a bit more complex because
of the casting and accessing of the offset via an integer variable, so
let's break it down:
tun->ak = 5; // mov -0x10(%rbp),%rax
// movl $0x5,(%rax)
(*tun).ak = 5; // mov -0x10(%rbp),%rax
// movl $0x5,(%rax)
So, you, cc, are partly correct -- the two notations work out to the same
code.
Now we KNOW where you got your "nym", cc. :-D
Now, if we drop off the crap needed to get the offset
*( (int *) (tun + offak)) = 5; // mov -0x10(%rbp),%rdx
// movl $0x5,(%rax) [filled from %rdx]
So I would say that, basically, I was also correct.
But back to your second claim, that
> The compiler does (*tun).sk, which does *(0) first...
The null address isn't used directly, though. Instead, the final address
of tunobject.ak (on the stack in this case) is accessed directly. However,
that's not quite fair, since no null pointer is involved. If we remove the
"tunobject" from the code and assign 0 to "tun" instead, the only thing that
changes is that
struct tun_t * tun = &tunobject; // lea -0x20(%rbp),%rax
becomes
struct tun_t * tun = 0; // movq $0x0,-0x10(%rbp)
The rest is the same.
Anyway, I will give Peter a partial "out" ... he's right about the null
pointer never being dereferenced on its own.
--
Q: How many Californians does it take to screw in a light bulb?
A: Five. One to screw in the light bulb and four to share the
experience. (Actually, Californians don't screw in
light bulbs, they screw in hot tubs.)
Q: How many Oregonians does it take to screw in a light bulb?
A: Three. One to screw in the light bulb and two to fend off all
those Californians trying to share the experience.
Ezekiel
"Chris Ahlstrom" <ahls...@launchmodem.com> wrote in message
news:h4fbcr$q9k$1...@news.eternal-september.org...
> After takin' a swig o' grog, cc belched out
> this bit o' wisdom:
>
>> On Jul 24, 4:25?pm, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>>
>>> It's /undefined/. ?The compiler will most likely do this operation:
>>
>> That's what I just said.
>>
>>> *(0 + offset(sk))
>>
>> No, that's not what the compiler does. The compiler does (*tun).sk,
>> which does *(0) first, which would be undefined. What it does after
>> that is anyone's guess.
>
> Why guess? Let's see what the compiler does with a some test code.
> Here's a little C module and the assembler it generates (on a 64-bit AMD
> CPU):
>
>
> #include <stddef.h> // offsetof() macro
> struct tun_t
> {
> int ak;
> };
>
> int main ()
> {
> struct tun_t tunobject;
> struct tun_t * tun = &tunobject; // lea -0x20(%rbp),%rax
> int offak = (int) offsetof(struct tun_t, ak); // movl $0x0,-0x4(%rbp)
> tun->ak = 5; //
> // movl $0x5,(%rax)
> (*tun).ak = 5; //
> // movl $0x5,(%rax)
> *( (int *) (tun + offak)) = 5; //
> // load offak into EAX //
Bullshit. He's as wrong as you can possibly get. Here's a direct quote from
him. Pay attention to *his* emphasis on how this *NEVER* accesses *ANY*
memory and how 'no memory access to any address is needed at all.'
Your reading ability is equally incompetent as Koahlmanns programming
skills.
<quote>
Assigning sock *sk to tun->sk *never* ever accesses *any* memory
It simply sets the address into that pointer. No memory access to any
address in those pointes needed at all
And if you don't know such simple facts, just lets stop here. Because by
now you sound rather hadronesque
</quote>
Hadron
Liarnut is a sycophantic suck up. I am astonished he is trying to
squeeze Peter out of the hole.
There is NOTHING complex here.
It was crap code with the NULL check in the wrong place. Pure and
simple. Nothing to see and bread and butter basics for any half
competent C programmer.
Bringing it down to the assembler is incredibly naive since the code
can be targeted at differ enc CPUS which can and do things
differently. It is the STANDARD that has to be referenced.
>
>
> <quote>
> Assigning sock *sk to tun->sk *never* ever accesses *any* memory
> It simply sets the address into that pointer. No memory access to any
> address in those pointes needed at all
>
> And if you don't know such simple facts, just lets stop here. Because by
> now you sound rather hadronesque
> </quote>
>
>
--
Ezekiel
"Chris Ahlstrom" <ahls...@launchmodem.com> wrote in message
news:h4fbcr$q9k$1...@news.eternal-september.org...
> this bit o' wisdom:
>
>> On Jul 24, 4:25?pm, Chris Ahlstrom <ahlstr...@launchmodem.com> wrote:
>>
>>> It's /undefined/. ?The compiler will most likely do this operation:
>>
>> That's what I just said.
>>
>>> *(0 + offset(sk))
>>
>> No, that's not what the compiler does. The compiler does (*tun).sk,
>> which does *(0) first, which would be undefined. What it does after
>> that is anyone's guess.
>
> Why guess? Let's see what the compiler does with a some test code.
> Here's a little C module and the assembler it generates (on a 64-bit AMD
> CPU):
>
>
> #include <stddef.h> // offsetof() macro
> struct tun_t
> {
> int ak;
> };
>
> int main ()
> {
> struct tun_t tunobject;
> struct tun_t * tun = &tunobject; // lea -0x20(%rbp),%rax
> int offak = (int) offsetof(struct tun_t, ak); // movl $0x0,-0x4(%rbp)
> tun->ak = 5; //
> // movl $0x5,(%rax)
> (*tun).ak = 5; //
> // movl $0x5,(%rax)
> *( (int *) (tun + offak)) = 5; //
> // load offak into EAX //
And being the clueless developer that you are... you're code is exactly
backwards.
The code in question is *not*
tun->ak = 5; // mov -0x10(%rbp),%rax
The correct code is:
int x = tun->ak;
There is a difference between "reading" a member of a structure and
"writing" to that member.
Hadron
"on its own" ?!?!?!?
For f*cks sake. Peter was completely and utterly WRONG.
The coding error was a common C error and one that anyone with more that
3 seconds C experience should spot. The fact he tried to argue against
the NULL check being necessary demonstrates he hasn't a clue. In
addition he misread the parameters and thought tun was an INSTANCE of a
tun_t struct.
So give up sucking up and try to be honest for once in your life.
Chris Ahlstrom
this bit o' wisdom:
> "Ezekiel" <ze...@nosuchdomain.com> writes:
>
>>> Anyway, I will give Peter a partial "out" ... he's right about the null
>>> pointer never being dereferenced on its own.
>>
>> Bullshit. He's as wrong as you can possibly get. Here's a direct quote from
>> him. Pay attention to *his* emphasis on how this *NEVER* accesses *ANY*
>> memory and how 'no memory access to any address is needed at all.'
>>
>> Your reading ability is equally incompetent as Koahlmanns programming
>> skills.
Not really. A large number of statements were made in that pissing contest
thread, and I merely picked one of Peter's statements to corroborate.
> It was crap code with the NULL check in the wrong place. Pure and
> simple. Nothing to see and bread and butter basics for any half
> competent C programmer.
Of course. I agree entirely with you, and have not argued against it.
I merely wanted to clarify cc's statements about the handling of a couple of
cases of pointer-to-structure dereferencing.
> Bringing it down to the assembler is incredibly naive since the code
> can be targeted at differ enc CPUS which can and do things
> differently. It is the STANDARD that has to be referenced.
For a guy with "a formidable background in machine code/assembler" (LOL),
"Hadron", you're sure quick to shy away from the correct and specific
technical presentation I gave, and instead concentrate on your obsession
with "sucking up" and other personal attacks.
>> <quote>
>> Assigning sock *sk to tun->sk *never* ever accesses *any* memory
>> It simply sets the address into that pointer. No memory access to any
>> address in those pointes needed at all
>> </quote>
That part is wrong, of course. But the part where he talks about the null
pointer itself never being dereferenced is correct.
No sucking up involved. I'm sure Peter feels quite chagrined enough, and I
surely do not appreciate your personal attacks and ridicule of Peter any
more than I appreciate your personal attacks and ridicule of myself.
However, it seems all you have is feckless carping about my specific
example with the very same compiler used to compile the kernel.
Pretty odd for a guy who boasts and brags about his assembly language
skills.
--
I have a formidable background in machine code/assembler and so can
explain how pointers work in a manner which might make it clearer to you
since you are clearly confused.
Hadron, <h4as8k$ba5$4...@news.eternal-september.org>
Alexander Terekhov
Ezekiel wrote:
[...]
> Koahlmanns programming skills.
I've heard that upcoming programmers are mostly learned through Java (or
C#) in academia.
Consider that
(Java)
public class Foo {
Foo bar;
public static void main(String args[]) {
Foo foo = null;
Object bar = foo.bar;
}
}
results in
Exception in thread "main" java.lang.NullPointerException
at Foo.main(Foo.java:9)
Should Peter K�hlmann go back to school? I think so.
Chris Ahlstrom
this bit o' wisdom:
> Chris Ahlstrom <ahls...@launchmodem.com> writes:
>>
>> Anyway, I will give Peter a partial "out" ... he's right about the null
>> pointer never being dereferenced on its own.
>
> "on its own" ?!?!?!?
>
> For f*cks sake. Peter was completely and utterly WRONG.
No, just mainly wrong.
> The coding error was a common C error and one that anyone with more that
> 3 seconds C experience should spot. The fact he tried to argue against
> the NULL check being necessary demonstrates he hasn't a clue. In
> addition he misread the parameters and thought tun was an INSTANCE of a
> tun_t struct.
>
> So give up sucking up and try to be honest for once in your life.
I was totally honest, "Hadron", and I never "suck up". That is a childish
concept, and I am surprised that someone like yourself with a
"formidable background in machine code/assembler" would resort to such a
stratagem in response to my simply cutting a poster a bit of slack.
Peter was wrong *en toto*, but he did say something that was correct.
Does that bother you?
--
Watch it Tim. Ahlstrom has been showing off explaining how he and Peter
study C articles and "craft" C code of the highest standard. Which is
amazing for someone who didn't understand how throwing casts at compiler
warnings is not generally a good idea since the warnings are explaining
how implicit casting is not working and there is a potential data clash.
Hadron, trying the same trolling lie for the umpteenth time in
<h4aae9$4o1$3...@hadron.eternal-september.org>
Tim Smith
Chris Ahlstrom <ahls...@launchmodem.com> wrote:
>
> > The compiler does (*tun).sk, which does *(0) first...
>
> The null address isn't used directly, though. Instead, the final address
> of tunobject.ak (on the stack in this case) is accessed directly. However,
> that's not quite fair, since no null pointer is involved. If we remove the
> "tunobject" from the code and assign 0 to "tun" instead, the only thing that
> changes is that
>
> struct tun_t * tun = &tunobject; // lea -0x20(%rbp),%rax
>
> becomes
>
> struct tun_t * tun = 0; // movq $0x0,-0x10(%rbp)
>
> The rest is the same.
>
> Anyway, I will give Peter a partial "out" ... he's right about the null
> pointer never being dereferenced on its own.
Yes, if *foo is a structure, and foo is null, then foo->member (if
member is not the first element in the structure) does not attempt to
access the memory at the address whose bit pattern is the same as the
bit pattern used for the null pointer, but rather at an offset from that.
However, that counts in the C standard as a dereference of foo, and is
undefined behavior. I don't have a cite to the exact part of the
standard for this, but it was discussed over in one of the C newsgroups
(there was a long thread on this kernel bug there), where people gave
cites, if you want to track one down.
--
--Tim Smith
Ezekiel
> After takin' a swig o' grog, Hadron belched out
> this bit o' wisdom:
>
>> "Ezekiel" <ze...@nosuchdomain.com> writes:
>>
>
>>> <quote>
>>> Assigning sock *sk to tun->sk *never* ever accesses *any* memory
>>> It simply sets the address into that pointer. No memory access to any
>>> address in those pointes needed at all
>>> </quote>
>
> That part is wrong, of course. But the part where he talks about the
> null
> pointer itself never being dereferenced is correct.
And /that part/ is the basis for his entire argument. It doesn't take much
programming skill to realize that you can't call code:
sock* sk = tun->sk;
when "tun" is NULL. This is as basic as C programming gets. It doesn't get
any easier than this and only a complete idiot would argue over and over
and over again that this code is valid and that "no memory access is needed
at all." But he wouldn't shut up and he wouldn't admit his mistake. He was
his typical asshole self and resorted to insulting everyone who dared
correct him on his ineptitude.
> No sucking up involved. I'm sure Peter feels quite chagrined enough,
I couldn't care less about how "Peter feels." Perhaps if Peter wasn't one
of the bigger A-holes in COLA then I would be willing to cut him a break.
But do list the last time that Peter ever cut anyone a break over one of
their mistakes.... he never has. So excuse me if I use this to ridicule is
"programming skills" for the next 5 years.
> and I surely do not appreciate your personal attacks and ridicule
> of Peter any more than I appreciate your personal attacks and
> ridicule of myself.
Are you Peter's mom or something??? Who cares whether you think we should
ridicule the idiot or not. He deserves it because he had ample opportunity
to realize that he was wrong but instead continued to dig his hole deeper
and deeper. After all... how dare anyone attempt to tell him that you can't
access data via a NULL pointer. And now Peter is exposed for being the
incompetent programmer moron I've always suspected. He's simply reaping the
harvest he has sown.
Hadron
And, more to the point, Liarsuck( thanks DFS), proves himself to be a
suck up of the worst order.
The whole argument was a non issue.
So much for "we craft the best code".....
Chris Ahlstrom
this bit o' wisdom:
> "Ezekiel" <ze...@nosuchdomain.com> writes:
>
> <Zeke's puerile bullshit snipped almost completely unread>
>
> And, more to the point, Liarsuck( thanks DFS), proves himself to be a
> suck up of the worst order.
Only a "hateful Hadron" would sneer at someone else's generous attitude
toward another person.
> The whole argument was a non issue.
>
> So much for "we craft the best code".....
Who said that, "Hadron"? I certainly did not. And what does cutting Peter
some slack have to do with the actual quality of my code? Nothing.
And, regardless of Peter's mistake, my guess is that he, like myself,
considers coding a *craft*, and takes it very seriously.
Unlike you two sneering bozos.
--
You are a fluke of the universe; you have no right to be here.
Chris Ahlstrom
this bit o' wisdom:
> In article <h4fbcr$q9k$1...@news.eternal-september.org>,
> Chris Ahlstrom <ahls...@launchmodem.com> wrote:
>>
>> Anyway, I will give Peter a partial "out" ... he's right about the null
>> pointer never being dereferenced on its own.
>
> Yes, if *foo is a structure, and foo is null, then foo->member (if
> member is not the first element in the structure) does not attempt to
> access the memory at the address whose bit pattern is the same as the
> bit pattern used for the null pointer, but rather at an offset from that.
You suck up! You're admitting that my partial (and very limited) defense of
Peter is warranted!!!!!!
:-D
> However, that counts in the C standard as a dereference of foo, and is
> undefined behavior. I don't have a cite to the exact part of the
> standard for this, but it was discussed over in one of the C newsgroups
> (there was a long thread on this kernel bug there), where people gave
> cites, if you want to track one down.
I looked at every instance of null in this document:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
and the closest I can find is this footnote:
87) Thus, &*E is equivalent to E (even if E is a null pointer), and
&(E1[E2]) to ((E1)+(E2)). It is always true that if E is a function
designator or an lvalue that is a valid operand of the unary & operator,
*&E is a function designator or an lvalue equal to E. If *P is an lvalue
and T is the name of an object pointer type, *(T)P is an lvalue that has
a type compatible with that to which T points.
Among the invalid values for dereferencing a pointer by the unary *
operator are a null pointer, an address inappropriately aligned for the
type of object pointed to, and the address of an object after the end of
its lifetime.
--
Do not sleep in a eucalyptus tree tonight.