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

From: Ingo Molnar
Date: Mon Feb 09 2009 - 08:56:24 EST



* 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?

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
--
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/