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

    * Brian Gerst <brgerst@gmail.com> wrote:

    > On Mon, Feb 9, 2009 at 8:39 AM, 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?
    > >
    > > * 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.
    > >
    > > * math_emu register access was completely broken. Fixed.
    > >
    > > * 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.
    >
    > I had a patch a while back that would convert those function to take a
    > pointer to pt_regs instead of assuming that the struct was passed by
    > value. [...]

    Yes, that's the right solution. Getting a new call convention recognized
    is a 3 years timeframe project for a whole team of hackers. Adding a
    pointer is a 30 minutes project for one good kernel hacker ;)

    > [...] I'll take a stab at reworking it on top of this series.

    Cool!

    Ingo


    \
     
     \ /
      Last update: 2009-02-09 15:21    [W:0.032 / U:94.680 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site