LWN: Comments on "Stable kernels 2.6.27.27 and 2.6.30.2"

Stable kernels 2.6.27.27 and 2.6.30.2

nix — Wed, 22 Jul 2009 15:30:22 +0000

Add one, or fix the makefiles? The kernel pretty much depends on your compiler, whatever compiler it is, acting like GCC. This includes supporting similar language extensions (especially weird ones like the statement expression extension), and supporting command-line arguments which at least do the same thing, even if their names aren't the same.

Stable kernels 2.6.27.27 and 2.6.30.2

MisterIO — Tue, 21 Jul 2009 04:56:38 +0000

I meant that it seems irrelevant and dangerous for the kernel, I didn't mean to say that it should be removed altogether. I doubt you'll see any noticeable differenct on the kernel performance without this optimization.

Stable kernels 2.6.27.27 and 2.6.30.2

qg6te2 — Mon, 20 Jul 2009 23:21:27 +0000

Say someone wants to compile the kernel with a compiler other than GCC -- what if the compiler doesn't have an equivalent to "-fno-delete-null-pointer-checks" ?

Stable kernels 2.6.27.27 and 2.6.30.2

stevenb — Mon, 20 Jul 2009 19:28:26 +0000

Stop being so kernel-minded. The rest of the world would laugh at any compiler that doesn't do this optimization for their user space code. And even for the kernel it is a useful optimization in principle. What is missing, is a static checker to catch these mistakes, and/or a warning from GCC somehow when this happens within a function.

Stable kernels 2.6.27.27 and 2.6.30.2

stevenb — Mon, 20 Jul 2009 19:25:39 +0000

If there are no such cases, of course.

But examples abound. Simple one from http://lwn.net/Articles/342226/:

inline char foo(char *p) { if (p == 0) return 0; else return *p; }
char bar(char *p) { *p = 2; return foo(p); }
int main() { char c = 0; return bar(&c); }

I already see GCC bugzilla fill with complaints when it would no longer compile this (perfectly valid) piece of code with a redundant NULL pointer check...

Stable kernels 2.6.27.27 and 2.6.30.2

xorbe — Mon, 20 Jul 2009 18:46:02 +0000

Because 12 months from now, some new coder will come through and modify/enhance the functionality, and then accidentally break some key assumption, leading to a NULL pointer (or other condition). Or, perhaps it could be key in catching a memory corruption bug. I really hate when the compiler removes safety check (as I coded a "safety"/debug STL library once.) Sometimes you want the *#$^ compiler to do as you say, and not to second-guess the coder.

Stable kernels 2.6.27.27 and 2.6.30.2

cbcbcb — Mon, 20 Jul 2009 17:10:49 +0000

Although this optimisation looks useless ("why would a programmer write a NULL check where it was obvious the value couldn't be NULL anyway?"), this sort of thing actually occurs all the time.

Consider this: When a programmer writes a function, lets call it f(), it is good practice to validate all inputs and return an error code if they are not correct. If the programmer calls f() in a loop, and the compiler decides to inline f(), then these checks for parameters may be done repeatedly and cost significant time.

This is very important for C++ where inline functions are used more often than in C (eg when small functions are placed inside class definitions)

[Side note: in Java it is particularly important (for performance) to remove unneeded null pointer checks, because every pointer dereference implies a null pointer and array bounds check.]

Stable kernels 2.6.27.27 and 2.6.30.2

vonbrand — Mon, 20 Jul 2009 16:58:13 +0000

Because leaving (unnecesary) checks in the generated code makes it worse?

Stable kernels 2.6.27.27 and 2.6.30.2

luto — Mon, 20 Jul 2009 16:33:20 +0000

Because optimizers can be clever and might determine that knowing that something is non-NULL can allow some (legit) optimization, but the programmer shouldn't be obligated to do that optimization by hand to get the code to compile.

The reason that the kernel wants this option but userspace doesn't is because, in kernel space, an attacker might map something into address 0, so assuming that null pointer dereferences always crash is dangerous. In userspace, on the other hand, you've already been owned by the time someone maps something at address 0.

Stable kernels 2.6.27.27 and 2.6.30.2

MisterIO — Mon, 20 Jul 2009 16:27:49 +0000

IMO the removal of "useless" checks for NULL is a legitimate but quite useless optimization. At most it'll just erase an if and that at the risk of more exploitable bugs?! No, thanks!

Stable kernels 2.6.27.27 and 2.6.30.2

nybble41 — Mon, 20 Jul 2009 15:40:53 +0000

There are some cases where this pattern makes sense. For example, you might dereference a pointer which you know to be non-NULL by design, and then pass it to a generic macro intended to work where that isn't always the case. As things are, the compiler reasonably takes the dereference as a sign that the programmer knows the pointer to be non-NULL, and thus optimizes away the presumably redundant test.

With the recent changes this optimization is no longer performed, which--as a fix for a single obvious logic error in the code--will lead to less efficient code in general without solving the core issue, which is the failure to test for NULL before dereferencing a potentially-NULL pointer. It would make more sense to either guarantee that execution will not continue following a NULL dereference or classify all NULL dereferences as exploitable vulnerabilities (or both).

Stable kernels 2.6.27.27 and 2.6.30.2

zorro — Mon, 20 Jul 2009 15:10:43 +0000

I agree with the sentiment. If there are no cases in which it makes sense to check a pointer for NULL after dereferencing it, why not make the compilation fail and remove the "-fno-delete-null-pointer-checks" option altogether?

Stable kernels 2.6.27.27 and 2.6.30.2

proski — Mon, 20 Jul 2009 14:10:17 +0000

Why?

By the way, it would be interesting to see which object files change if this option is enabled.

Perhaps future version of gcc should warn if they encounter NULL pointer checks that can be eliminated.

Stable kernels 2.6.27.27 and 2.6.30.2

qg6te2 — Mon, 20 Jul 2009 14:05:45 +0000

Eugene Teo (1): Add '-fno-delete-null-pointer-checks' to gcc CFLAGS

I sincerely hope this isn't a permanent solution.

Stable kernels 2.6.27.27 and 2.6.30.2

kragil — Mon, 20 Jul 2009 13:47:35 +0000

Please release 2.6.27.28 12:34:56 7.8.9 (d.m.y)