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    [W:2.996 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site