5 ms·

a) these are marginal optimizations, at best. b) because it violates C practice. My parsing library is written to distrust inputs so as to protect against buffe

a) these are marginal optimizations, at best. b) because it violates C practice. My parsing library is written to distrust inputs so as to protect against buffer exploits. Your compiler "optimizes" away my security check because some buggy code dereferences a null pointer - which actually works in this implementation. Great. Now you have "optimized" to create a security hole in the program by removing a single instruction that is actually free in many pipelined architectures. Wonderful. Thanks so much.

geofft 8y ago
> a) these are marginal optimizations, at best. The optimization isn't written in the form of "If you see this ridiculous code, make it less ridiculous." It's written in the form of "You can refactor repeated checks of presumed-non-aliased variables into a single check." Otherwise code like for (i = 0; i < *plen; i++) would involve dereferencing plen on every single loop, which for many applications is definitely not marginal! > some buggy code dereferences a null pointer - which actually works in this implementation. What implementation is this? (Are you mmapping at NULL, or writing for an architecture without an MMU, or something?) NULL doesn't have to be address zero. It's denoted by literal zero, in the C source, but it can be something totally different when translated to the machine. Can you arrange for some other address to generate a segfault, and tell your C compiler to use that as NULL? (I don't know how to do this with gcc, and I'd like to know how, honestly - it seems like a significant win for kernel security if NULL pointers in kernel code were an invalid kernelspace address and not an invalid userspace address.)
- cesarb 8y ago
  Many C programs assume that initializing a variable to all-bits-zero, through memset, calloc, the .bss section, or on the kernel the GFP_ZERO flag, will initialize all pointers within it to NULL. See also: http://austingroupbugs.net/view.php?id=940 http://austingroupbugs.net/view.php?id=940 ("all 0 bits should be a null pointer on POSIX systems").
- vyodaiken 8y ago
  Not correct. g(x){ ... if x is null panic otherwise x->v = n} can currently be optimized to x->v =n given f(){ ... y =x->v ... g(x) } because null dereferences are assumed impossible in some twisted interpretation of the standard. Imagine the effects with inlining and LTO. That's my issue, not perfectly ordinary standard value caching etc.

geofft 8y ago

> a) these are marginal optimizations, at best. The optimization isn't written in the form of "If you see this ridiculous code, make it less ridiculous." It's written in the form of "You can refactor repeated checks of presumed-non-aliased variables into a single check." Otherwise code like for (i = 0; i < *plen; i++) would involve dereferencing plen on every single loop, which for many applications is definitely not marginal! > some buggy code dereferences a null pointer - which actually works in this implementation. What implementation is this? (Are you mmapping at NULL, or writing for an architecture without an MMU, or something?) NULL doesn't have to be address zero. It's denoted by literal zero, in the C source, but it can be something totally different when translated to the machine. Can you arrange for some other address to generate a segfault, and tell your C compiler to use that as NULL? (I don't know how to do this with gcc, and I'd like to know how, honestly - it seems like a significant win for kernel security if NULL pointers in kernel code were an invalid kernelspace address and not an invalid userspace address.)

cesarb 8y ago
Many C programs assume that initializing a variable to all-bits-zero, through memset, calloc, the .bss section, or on the kernel the GFP_ZERO flag, will initialize all pointers within it to NULL. See also: http://austingroupbugs.net/view.php?id=940 http://austingroupbugs.net/view.php?id=940 ("all 0 bits should be a null pointer on POSIX systems").
vyodaiken 8y ago
Not correct. g(x){ ... if x is null panic otherwise x->v = n} can currently be optimized to x->v =n given f(){ ... y =x->v ... g(x) } because null dereferences are assumed impossible in some twisted interpretation of the standard. Imagine the effects with inlining and LTO. That's my issue, not perfectly ordinary standard value caching etc.