On Fri, 2013-03-08 at 13:14 +0100, Paolo Bonzini wrote: > Il 08/03/2013 01:14, Andrew Fish ha scritto: > > We just ran into an issue that I thought was worth sharing with the > > group. We just updated our compiler and a memory test got optimized > > away. At first we thought it was a compiler bug. But then we were > > informed that in the C language the dereference of a NULL pointer is > > undefined behavior. So technically it is legal for the compiler to > > optimize it way. > > > > So to be pedantic in C if you ever dereference a NULL point on > > purpose you need to make it a volatile to conform to the C standard. > > A memory test may want to access address 0, and code that writes the > > ARM or 8086 vector table may also end up dereferencing a NULL > > pointer. > > > > I think folks will find Chris Lattner's blog interesting > > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html > > Do you know what MSVC does about this? For GCC/clang, it is probably > best to add -fno-delete-null-pointer-checks to the command line, because > a NULL pointer dereference will not cause abnormal termination in > TianoCore. The Linux kernel uses the same option.
We do it for slightly different reasons — I'm not sure it's really addressing the same issue that Andrew was talking about. GCC will optimise away a NULL pointer check only if it happens *after* the pointer has already been dereferenced. It does this on the basis that if the pointer is NULL, you're going to die before you ever reach the place in the code that would check the pointer. There is a class of vulnerability where the attacker actually maps something at zero, and then tricks the kernel into using it (usually executing it). A checking pointers for NULL would normally stop the kernel from succumbing to such a trick. But if we accidentally dereference the pointer *before* checking it (which is a bug, but it happens) and GCC therefore elides the check, then the kernel becomes vulnerable. It'll happily go ahead and do all kinds of things with the NULL pointer that it shouldn't have done. Which will normally just crash immediately, of course, but in the case where an attacker has deliberately mapped something at zero... not so good. So in http://git.kernel.org/linus/a3ca86aea we added the -fno-delete-null-pointer-checks option, to ensure that GCC *doesn't* elide the check. That commit has a full worked example of the type of vulnerability I describe, if you want more detail. But Andrew seemed to be talking about a case where the compiler *knew* that the address being dereferenced was a constant NULL, and actually optimised away the *dereference*. I don't think -fno-delete-null-pointer-checks will do anything about that. That isn't a problem we have in the kernel because NULL *is* normally a bad pointer. It *should* cause a crash, and we never dereference it on purpose. But for compatibility reasons, wine and some other things actually need to be able to map code at zero, and that's what allows the above-mentioned class of vulnerabilities to exist. But in our case the NULL pointer is *always* handed in from outside; the compiler can never predict it and *know* that we're going to dereference NULL. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
