Re: [RFC 00/15] x86_64: Optimize percpu accesses

[Ingo Molnar]

* Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:

> Arjan van de Ven <arjan@xxxxxxxxxxxxx> writes:
> 
> > On Wed, 09 Jul 2008 13:00:19 -0700
> > ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote:
> >
> >> 
> >> I just took a quick look at how stack_protector works on x86_64.
> >> Unless there is some deep kernel magic that changes the segment
> >> register to %gs from the ABI specified %fs CC_STACKPROTECTOR is
> >> totally broken on x86_64.  We access our pda through %gs.
> >
> > and so does gcc in kernel mode.
> 
> Some gcc's in kernel mode.  The one I tested with doesn't.

yes - stackprotector enabled distros build with kernel mode enabled gcc.

> >> Further -fstack-protector-all only seems to detect against buffer 
> >> overflows and thus corruption of the stack.  Not stack overflows.  
> >> So it doesn't appear especially useful.
> >
> > stopping buffer overflows and other return address corruption is not 
> > useful? Excuse me?
> 
> Stopping buffer overflows and return address corruption is useful.  
> Simply catching and panic'ing the machine when the occur is less 
> useful. [...]

why? I personally prefer an informative panic in an overflow-suspect 
piece of code instead of a guest root on my machine.

I think you miss one of the fundamental security aspects here. The panic 
is not there just to inform the administrator - although it certainly 
has such a role.

It is mainly there to _deter_ attackers from experimenting with certain 
exploits.

For the more sophisticated attackers (not the script kiddies - the ones 
who can do serious economic harm) their exploits and their attack 
vectors are their main assets. They want their exploits to work on the 
next target as well, and they want to be as stealth as possible.

For a script kiddie crashing a box is not a big issue - they work with 
public exploits.

This means that the serious attempts will only use an attack if its 
effects are 100% deterministic - they wont risk something like a 50%/50% 
chance of a crash (or even a 10% chance of a crash). Some of the most 
sophisticated kernel exploits i've seen had like 80% of their code 
complexity in making sure that they dont crash the target box. They were 
more resilient code than a lot of kernel code we have.

> [...] We aren't perfect but we have a pretty good track record of 
> handling this with old fashioned methods.

That's your opinion. A valid counter point is that more layers of 
defense, in a fundamentally fragile area (buffers on the stack, return 
addresses), cannot hurt. If you've got a firewall that is only 10% busy 
even under peak load it's a valid option to spend some CPU cycles on 
preventive measures.

A firewall _itself_ is huge overhead already - so there's absolutely no 
valid technical reason to forbid a firewall from having something like 
stackprotector built into its kernel. (and into most of its userspace) 

We could have caught the vsplice exploit as well with stackprotector - 
but our security QA was not strong enough to keep it from slowly 
regressing. (without anyone noticing) That's fixed now in 
tip/core/stackprotector.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/