[PATCH] UBUNTU: SAUCE: [x86] implement cs-limit nx-emulation for ia32

[Kees Cook]

On Fri, May 01, 2009 at 10:05:53AM -0600, Tim Gardner wrote:
> Ick! This messes with some seriously core x86 stuff, though the concept
> seems straightforward.

It's pretty ugly to look at initially, I agree.  After having spent a good
deal of time looking at it, I'm convinced it's actually okay.

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

That's my understanding too.

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

In PAE mode, everything is disabled.  In fact, I improved on the original
RedHat patch to disable the specialized vma addressing when running NX:

+#ifdef CONFIG_X86_32
+       if (!nx_enabled && !(current->personality & READ_IMPLIES_EXEC)
+           && mmap_is_ia32())
+           mm->get_unmapped_exec_area = arch_get_unmapped_exec_area;
+#endif

As for get_unmapped_area vs get_unmapped_area_prot, this falls through
correctly in non-PAE.  For the stuff outside of the arch/x86 directory,
everything is compiled out for non-ia32.  In the case of PAE, since
the segment limit is disabled, the calls are quickly aborted (see
arch_add_exec_range).

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

This isn't possible because the CD only has room for 1 kernel, and since we
support so much old hardware, the non-PAE kernel must be used there.  I do
not see cjwatson changing his mind on this any time in the near future.

Additionally, we have hardware like UNR, lpia, etc, that continue to lack
PAE in their builds.

> Given that _most_ desktops/laptops will be running a PAE enabled kernel
> in Karmic, how important is this patch?

I do not believe "most" will be true, and it still leaves a large number of
unprotected people.  NX protection is probably the most powerful proactive
protection we have, and I've long wanted to get this hole fixed for
non-PAE:
https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-pae-desktop

I want to strongly push for both PAE-by-default and nx-emulation for the
non-PAE ia32 kernels, since I think we'll be living with those for a long
time to come.

If the impact on PAE kernels is seen as bad, perhaps I can rework the patch
to check for CONFIG_X86_PAE as well as CONFIG_X86_32?

-Kees

-- 
Kees Cook
Ubuntu Security Team