Messages in this thread | | | Date | Mon, 9 Feb 2009 14:55:57 +0100 | From | Ingo Molnar <> | Subject | Re: [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
| |