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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
