lkml.org 
[lkml]   [2009]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHSET x86/master] add stack protector support for x86_32

    * Tejun Heo <tj@kernel.org> wrote:

    > Hello,
    >
    > This patchset adds stack protector support for x86_32. The basics are
    > the same with x86_64 but there are some noticeable differences.
    >
    > * x86_32 uses %fs for percpu base. %gs is unused by the kernel and
    > managed lazily. %gs is used for userland TLS and loading %gs with
    > different value on kernel entry is known to cost quite a bit on some
    > chips.
    >
    > Lazy %gs handling is made optional and disabled if stack protector
    > is enabled. To do this, entry for %gs is added to pt_regs. This
    > adds one "pushl $0" to SAVE_ALL in entry_32.S when lazy %gs is on.
    > However, no overhead is added to common exit path and error_code
    > entry path shed a few instructions. I don't think there will be
    > noticeable overhead but then again it does add an instruction to a
    > very hot path. Would this be okay?

    Yeah, looks good.

    > * x86_32 doesn't support direct access to shadow part of %gs and
    > there's no swapgs, so GDT entry should be built for stack canary.
    >
    > GDT entry 28 is used for this. The boot cpu one is setup from
    > head_32.S. Others while setting up percpu areas.

    Yeah.

    > * math_emu register access was completely broken. Fixed.

    => i'll queue this up for mainline too as this breakage is independent
    of stackprotector.

    > * x86_32 exception handlers take register frame verbatim as struct
    > pt_regs. With -fstack-protector, gcc copies pt_regs into the
    > callee's stack frame to put it after the stack canary. Of course it
    > doesn't copy back (as the callee owns the argument) and any change
    > made to pt_regs is lost on return. This is currently worked around
    > by adding -fno-stack-protector to any file containing such
    > functions. We really need to teach gcc about the calling
    > convention.

    Or we could just push in struct pt_regs * ? Even if it's one more
    instruction that will avoid trouble not just with the canary but also
    with over-eager tail-call optimizations, etc.

    > This patchset contains the following eleven patches.

    Note, i sorted out the dependencies (it depended on x86/uaccess) and have
    put the commits into tip:core/percpu. I might not get around testing it
    today and pushing it out into tip:master, but i pushed out the core/percpu
    bits, should you queue up further changes.

    Ingo


    \
     
     \ /
      Last update: 2009-02-09 14:59    [W:4.170 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site