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

Tim Gardner tim.gardner at canonical.com
Mon May 4 20:31:10 UTC 2009


Kees Cook wrote:
> 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
> 

OK - here goes:

https://bugs.edge.launchpad.net/ubuntu/karmic/+source/linux/+bug/369978/comments/3

-- 
Tim Gardner tim.gardner at canonical.com




More information about the kernel-team mailing list