Re: [RFC] stack and heap are executable on x86_64

["H. Peter Anvin" <hpa@zytor.com>]

On 12/20/2012 07:00 PM, Kees Cook wrote:
>
> This change for pre-v3.5 creates a new exception table instead of
> trying to rewrite the old one. Since the tables are now relative,
> we can't actually set up an exception for things in stack and heap on
> x86_64 since the distance between the address and the table's .insn is
> more than INT_MAX. And if the table were moved into the stack or heap,
> then the fixup couldn't point back to the module's text segment. For
> v3.5 and later, I'm not sure what to do...
>
> So, mainly two things:
> - we need to fix the stack/heap markings.
> - it'd be nice to get test_nx back on its feet again.
>

I just looked at a /sys/kernel/debug/kernel_page_tables dump.... and 
there are a bunch of pages which are RWX:

0xffff880000000000-0xffff880000097000  604K RW             GLB x  pte
0xffff88000009d000-0xffff880000200000 1420K RW             GLB x  pte
0xffff880000200000-0xffff880001000000   14M RW         PSE GLB x  pmd
0xffff880001c00000-0xffff880035e00000  834M RW         PSE GLB x  pmd
0xffff880035e00000-0xffff880035ffe000 2040K RW             GLB x  pte
0xffff880036ff7000-0xffff880037000000   36K RW             GLB x  pte
0xffff880037000000-0xffff880040000000  144M RW         PSE GLB x  pmd
0xffffffff81c00000-0xffffffff81cea000  936K RW             GLB x  pte
0xffffffff81dfd000-0xffffffff81e00000   12K RW             GLB x  pte
0xffffffff81e00000-0xffffffff82000000    2M RW         PSE GLB x  pmd

One particular piece of idiocy is that we tied marking the pages 
executable into the PAT system, which means that if it is executable 
anywhere in the kernel it is executable everywhere.  That being said, I 
don't think that is the only thing at play here.

On the other hand... do we *ever* have a legitimate reason to run code 
below the -2G point?  If so we could/should probably mark those NX 
already at the higher paging levels...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.