Re: [PATCHSET x86/master] add stack protector support for x86_32

Ingo Molnar
2009-02-09T14:17:47Z

* 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