[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5613EAD5.2070405@tycho.nsa.gov>
Date: Tue, 6 Oct 2015 11:37:57 -0400
From: Stephen Smalley <sds@...ho.nsa.gov>
To: Ingo Molnar <mingo@...nel.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
keescook@...omium.org, Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andy Lutomirski <luto@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Denys Vlasenko <dvlasenk@...hat.com>,
Brian Gerst <brgerst@...il.com>
Subject: Re: [PATCH v2] x86/mm: warn on W+x mappings
On 10/06/2015 03:32 AM, Ingo Molnar wrote:
>
> * Stephen Smalley <sds@...ho.nsa.gov> wrote:
>
>> On 10/03/2015 07:27 AM, Ingo Molnar wrote:
>>>
>>> * Stephen Smalley <sds@...ho.nsa.gov> wrote:
>>>
>>>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
>>>> index 30564e2..f8b1573 100644
>>>> --- a/arch/x86/mm/init_64.c
>>>> +++ b/arch/x86/mm/init_64.c
>>>> @@ -1150,6 +1150,8 @@ void mark_rodata_ro(void)
>>>> free_init_pages("unused kernel",
>>>> (unsigned long) __va(__pa_symbol(rodata_end)),
>>>> (unsigned long) __va(__pa_symbol(_sdata)));
>>>> +
>>>> + debug_checkwx();
>>>
>>> Any reason to not do this on NX capable 32-bit kernels as well?
>>
>> Done in v3. However, I do see lots of W+X mappings there.
>
> Ha! That's a debug check plan gone very well! :)
>
>> [ 1.012796] WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x65d/0x840()
>> [ 1.012803] x86/mm: Found insecure W+X mapping at address f4a00000/0xf4a00000
>
> What does this range correspond to on your kernel?
>From dmesg:
[ 0.000000] virtual kernel memory layout:
fixmap : 0xffa96000 - 0xfffff000 (5540 kB)
pkmap : 0xff800000 - 0xffa00000 (2048 kB)
vmalloc : 0xf7ffe000 - 0xff7fe000 ( 120 MB)
lowmem : 0xc0000000 - 0xf77fe000 ( 887 MB)
.init : 0xc0dde000 - 0xc0e9d000 ( 764 kB)
.data : 0xc0aa2ba0 - 0xc0ddca00 (3303 kB)
.text : 0xc0400000 - 0xc0aa2ba0 (6794 kB)
/sys/kernel/debug/kernel_page_tables seems to have many such mappings,
even before the reported one under Kernel Mapping, plus one in the vmalloc() area:
---[ Kernel Mapping ]---
0xc0000000-0xc009b000 620K RW GLB NX pte
0xc009b000-0xc009c000 4K ro GLB NX pte
0xc009c000-0xc009d000 4K ro GLB x pte
0xc009d000-0xc0200000 1420K RW GLB NX pte
0xc0200000-0xc0400000 2M RW PSE GLB NX pmd
0xc0400000-0xc0a00000 6M ro PSE GLB x pmd
0xc0a00000-0xc0aa3000 652K ro GLB x pte
0xc0aa3000-0xc0d2a000 2588K ro GLB NX pte
0xc0d2a000-0xc1000000 2904K RW GLB NX pte
0xc1000000-0xe7000000 608M RW PSE GLB NX pmd
0xe7000000-0xe7027000 156K RW GLB x pte
0xe7027000-0xe7028000 4K ro GLB x pte
0xe7028000-0xe709b000 460K RW GLB x pte
0xe709b000-0xe709c000 4K ro GLB x pte
0xe709c000-0xe70b8000 112K RW GLB x pte
0xe70b8000-0xe70b9000 4K ro GLB x pte
0xe70b9000-0xe7108000 316K RW GLB x pte
0xe7108000-0xe710a000 8K ro GLB x pte
0xe710a000-0xe7127000 116K RW GLB x pte
0xe7127000-0xe712a000 12K ro GLB x pte
<many additional ones elided>
0xf2c5c000-0xf2c5d000 4K ro GLB x pte
0xf2c5d000-0xf2e00000 1676K RW GLB x pte
0xf2e00000-0xf4a00000 28M RW PSE GLB NX pmd
0xf4a00000-0xf4b28000 1184K RW GLB x pte
0xf4b28000-0xf4c00000 864K RW GLB NX pte
0xf4c00000-0xf5200000 6M RW PSE GLB x pmd
0xf5200000-0xf525d000 372K RW GLB x pte
0xf525d000-0xf525e000 4K ro GLB x pte
0xf525e000-0xf525f000 4K RW GLB x pte
0xf525f000-0xf5260000 4K ro GLB x pte
0xf5260000-0xf526a000 40K RW GLB x pte
0xf6400000-0xf658c000 1584K RW GLB NX pte
0xf658c000-0xf6600000 464K RW GLB x pte
0xf6600000-0xf7600000 16M RW PSE GLB NX pmd
0xf7600000-0xf77fe000 2040K RW GLB NX pte
0xf77fe000-0xf7800000 8K pte
0xf7800000-0xf7e00000 6M pmd
0xf7e00000-0xf7ffe000 2040K pte
---[ vmalloc() Area ]---
0xf7ffe000-0xf7fff000 4K RW GLB NX pte
0xf7fff000-0xf8000000 4K pte
0xf8000000-0xf8002000 8K RW GLB NX pte
...
0xf86f3000-0xf8800000 1076K pte
0xf8800000-0xf8a00000 2M RW PWT PSE GLB x pmd
0xf8a00000-0xf8b00000 1M RW PWT GLB NX pte
$ grep -c 'RW.*x' kernel_page_tables
114
There was also an earlier W+X mapping originally that I squelched via pci=nobios.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists