lkml.org 
[lkml]   [2008]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 00/15] x86_64: Optimize percpu accesses

* Eric W. Biederman <ebiederm@xmission.com> wrote:

> Arjan van de Ven <arjan@infradead.org> writes:
>
> > On Wed, 09 Jul 2008 13:00:19 -0700
> > ebiederm@xmission.com (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


\
 
 \ /
  Last update: 2008-07-09 23:03    [from the cache]
©2003-2011 Jasper Spaans