[PATCH] UBUNTU: SAUCE: [x86] implement cs-limit nx-emulation for ia32
Tim Gardner
tim.gardner at canonical.com
Fri May 1 16:05:53 UTC 2009
Kees Cook wrote:
> This implements NX emulation via CS-limits. It closes a gap in security
> protections on ia32 kernels without PAE, and for ia32 hardware that lacks
> the NX feature.
>
> Upstream feels this NX emulation is not appropriate for mainline,
> and as such, RedHat has carried it in their kernels for a long time
> now. The approach is well-tested, though recent forward-porting
> may need additional testing.
>
> OriginalAuthor: Dave Jones <djones at redhat.com>, Solar Designer <solar at openwall.com>
> OriginalLocation: http://www.codemonkey.org.uk/projects/execshield/
> Bug: #369978
>
> Signed-off-by: Kees Cook <kees.cook at canonical.com>
Ick! This messes with some seriously core x86 stuff, though the concept
seems straightforward.
I noticed in the blurb about ExecSheild that Ingo claims there is no
measurable runtime impact. I assume that is because the user CS is
getting flushed on every task swap anyway (my knowledge of how Linux
manages user task state transitions is a bit rusty), and the only thing
this patch does (in essence) is change the segment length.
What kind of impact is this gonna have on PAE enabled kernels? It looks
like _all_ ia32 kernels will run at least some portion of this patch,
even though PAE kernels support the NX bit.
FYI - I'm going to propose at UDS that the 32 bit flavours for Karmic be
limited to -generic-nopae and -generic. I intend to drop the 32 bit PAE
enabled -server flavour altogether. I'd like to propose to the installer
folks that kernel capabilities be detected at install time and that the
appropriate kernel be installed according to CPU capabilities.
Given that _most_ desktops/laptops will be running a PAE enabled kernel
in Karmic, how important is this patch?
rtg
--
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team
mailing list