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

[Brian Gerst]

On Mon, Feb 9, 2009 at 8:39 AM, Tejun Heo <tj@xxxxxxxxxx> 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.  I'll take a stab at reworking it on top of this series.

--
Brian Gerst
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/