Kernel release status [LWN.net]

Kernel release status

Posted Sep 27, 2009 10:49 UTC (Sun) by nix (subscriber, #2304)
In reply to: Kernel release status by spender
Parent article: Kernel release status

That's interesting. I'd expect the behaviour you see with only
CONFIG_CC_STACKPROTECTOR enabled, as this only protects functions
containing large char arrays (not arrays of other types, not aggregates,
not pointers to them). But _ALL should change this, and the presence of
the aggregate 'struct perf_counter_attr attr' should then enable guard
generation for sys_perf_counter_open(). Yet it doesn't.

I wonder if there's something about SYSCALL_DEFINE*() that is blocking
stack protector... doesn't look like it, asmlinkage shouldn't do it. I'll
have to beat up GCC a bit and figure out what's going on...

(Log in to post comments)

Kernel release status

Posted Sep 27, 2009 12:52 UTC (Sun) by spender (subscriber, #23067) [Link]

CONFIG_CC_STACKPROTECTOR cannot be enabled alone anymore. See the link I pasted above where Ingo was talking about stackprotector_all being on by default because otherwise it wouldn't have stopped vmsplice (which it had nothing to do with).

I don't believe it has to do with SYSCALL_DEFINE, because I've found other syscalls that were protected (disassemble kernel/sys.o for example and you'll see that sys_prctl is protected).

But yes, there is definitely an important weakness/vulnerability in the stackprotector implementation (which must have been silently fixed in a newer gcc perhaps? for Ingo to have gotten his results). Nevertheless, this makes it quite a poor protection, and some mention should be made in the configure help about the ambiguous protection it provides depending on your compiler version (and give a recommended minimum compiler version that does what the feature actually claims).

-Brad