Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1232476 > unrolled thread

Re: rwx mapping between ex_table and rodata

Started byKees Cook <keescook@chromium.org>
First post2015-09-25 00:30 +0200
Last post2015-10-02 09:20 +0200
Articles 14 — 5 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: rwx mapping between ex_table and rodata Kees Cook <keescook@chromium.org> - 2015-09-25 00:30 +0200
    Re: rwx mapping between ex_table and rodata Ingo Molnar <mingo@kernel.org> - 2015-09-25 09:30 +0200
    Re: rwx mapping between ex_table and rodata Ingo Molnar <mingo@kernel.org> - 2015-09-25 09:30 +0200
      Re: rwx mapping between ex_table and rodata Kees Cook <keescook@chromium.org> - 2015-09-26 18:50 +0200
      Re: rwx mapping between ex_table and rodata "H. Peter Anvin" <hpa@zytor.com> - 2015-09-28 23:20 +0200
        Re: rwx mapping between ex_table and rodata Kees Cook <keescook@chromium.org> - 2015-09-29 00:10 +0200
          Re: rwx mapping between ex_table and rodata "H. Peter Anvin" <hpa@zytor.com> - 2015-09-29 00:30 +0200
    Re: rwx mapping between ex_table and rodata Stephen Smalley <sds@tycho.nsa.gov> - 2015-09-28 16:20 +0200
      Re: rwx mapping between ex_table and rodata Kees Cook <keescook@chromium.org> - 2015-09-28 20:30 +0200
        Re: rwx mapping between ex_table and rodata Ingo Molnar <mingo@kernel.org> - 2015-10-01 09:20 +0200
        Re: rwx mapping between ex_table and rodata Thomas Gleixner <tglx@linutronix.de> - 2015-10-01 11:10 +0200
          Re: rwx mapping between ex_table and rodata Ingo Molnar <mingo@kernel.org> - 2015-10-01 11:20 +0200
            Re: rwx mapping between ex_table and rodata Kees Cook <keescook@chromium.org> - 2015-10-01 19:50 +0200
              Re: rwx mapping between ex_table and rodata Ingo Molnar <mingo@kernel.org> - 2015-10-02 09:20 +0200

#1232476 — Re: rwx mapping between ex_table and rodata

FromKees Cook <keescook@chromium.org>
Date2015-09-25 00:30 +0200
SubjectRe: rwx mapping between ex_table and rodata
Message-ID<qcnbz-7Zv-11@gated-at.bofh.it>
On Thu, Sep 24, 2015 at 1:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> Hi,
>
> With the attached config and 4.3-rc2 on x86_64, I see the following in /sys/kernel/debug/kernel_page_tables:
> ...
> ---[ High Kernel Mapping ]---
> 0xffffffff80000000-0xffffffff81000000          16M                               pmd
> 0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
> 0xffffffff81600000-0xffffffff81775000        1492K     ro                 GLB x  pte
> 0xffffffff81775000-0xffffffff81800000         556K     RW                 GLB x  pte
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
> 0xffffffff81a00000-0xffffffff81b43000        1292K     ro                 GLB NX pte
> 0xffffffff81b43000-0xffffffff82000000        4852K     RW                 GLB NX pte
> 0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
> 0xffffffff82200000-0xffffffffa0000000         478M                               pmd
> ...
>
> This region seems to be between the end of ex_table and the start of rodata,
> $ objdump -x vmlinux | sort
> ...
> ffffffff817728b0 g       __ex_table     0000000000000000 __start___ex_table
> ffffffff817728b0 l    d  __ex_table     0000000000000000 __ex_table
> ffffffff81774998 g       __ex_table     0000000000000000 __stop___ex_table
> ffffffff81800000 g       .rodata        0000000000000000 __start_rodata
> ffffffff81800000 l    d  .rodata        0000000000000000 .rodata
> ...
>
> $ readelf -a vmlinux
> ...
> Section Headers:
>   [Nr] Name              Type             Address           Offset
>        Size              EntSize          Flags  Link  Info  Align
> ...
>   [ 3] __ex_table        PROGBITS         ffffffff817728b0  009728b0
>        00000000000020e8  0000000000000000   A       0     0     8
>   [ 4] .rodata           PROGBITS         ffffffff81800000  00a00000
>        00000000002eefd2  0000000000000000   A       0     0     64
> ...
>
> I see a similar rwx mapping with the stock Fedora kernels (e.g. 4.1.6), so it isn't new to 4.3.

To me it looks like another alignment/padding issue like got fixed
before. The space between __ex_table and rodata is (seems?) unused, so
the default page table permissions end up being W+X. Can we fix the
default to be NX instead? It'll make these bugs stay gone.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1232625

FromIngo Molnar <mingo@kernel.org>
Date2015-09-25 09:30 +0200
Message-ID<qcvCa-32z-5@gated-at.bofh.it>
In reply to#1232476
* Kees Cook <keescook@chromium.org> wrote:

> On Thu, Sep 24, 2015 at 1:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > Hi,
> >
> > With the attached config and 4.3-rc2 on x86_64, I see the following in /sys/kernel/debug/kernel_page_tables:
> > ...
> > ---[ High Kernel Mapping ]---
> > 0xffffffff80000000-0xffffffff81000000          16M                               pmd
> > 0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
> > 0xffffffff81600000-0xffffffff81775000        1492K     ro                 GLB x  pte
> > 0xffffffff81775000-0xffffffff81800000         556K     RW                 GLB x  pte
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Btw., I think we should run this lookup automatically in late bootup, if 
CONFIG_X86_PTDUMP=y, and print a WARN()ing if there's any RWX permissions in the 
mappings.

That makes sure automated testing picks new bugs up.

Thanks,

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

[toc] | [prev] | [next] | [standalone]


#1232627

FromIngo Molnar <mingo@kernel.org>
Date2015-09-25 09:30 +0200
Message-ID<qcvCa-32z-9@gated-at.bofh.it>
In reply to#1232476
* Kees Cook <keescook@chromium.org> wrote:

> On Thu, Sep 24, 2015 at 1:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > Hi,
> >
> > With the attached config and 4.3-rc2 on x86_64, I see the following in /sys/kernel/debug/kernel_page_tables:
> > ...
> > ---[ High Kernel Mapping ]---
> > 0xffffffff80000000-0xffffffff81000000          16M                               pmd
> > 0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
> > 0xffffffff81600000-0xffffffff81775000        1492K     ro                 GLB x  pte
> > 0xffffffff81775000-0xffffffff81800000         556K     RW                 GLB x  pte
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
> > 0xffffffff81a00000-0xffffffff81b43000        1292K     ro                 GLB NX pte
> > 0xffffffff81b43000-0xffffffff82000000        4852K     RW                 GLB NX pte
> > 0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
> > 0xffffffff82200000-0xffffffffa0000000         478M                               pmd
> > ...
> >
> > This region seems to be between the end of ex_table and the start of rodata,
> > $ objdump -x vmlinux | sort
> > ...
> > ffffffff817728b0 g       __ex_table     0000000000000000 __start___ex_table
> > ffffffff817728b0 l    d  __ex_table     0000000000000000 __ex_table
> > ffffffff81774998 g       __ex_table     0000000000000000 __stop___ex_table
> > ffffffff81800000 g       .rodata        0000000000000000 __start_rodata
> > ffffffff81800000 l    d  .rodata        0000000000000000 .rodata
> > ...
> >
> > $ readelf -a vmlinux
> > ...
> > Section Headers:
> >   [Nr] Name              Type             Address           Offset
> >        Size              EntSize          Flags  Link  Info  Align
> > ...
> >   [ 3] __ex_table        PROGBITS         ffffffff817728b0  009728b0
> >        00000000000020e8  0000000000000000   A       0     0     8
> >   [ 4] .rodata           PROGBITS         ffffffff81800000  00a00000
> >        00000000002eefd2  0000000000000000   A       0     0     64
> > ...
> >
> > I see a similar rwx mapping with the stock Fedora kernels (e.g. 4.1.6), so it isn't new to 4.3.
> 
> To me it looks like another alignment/padding issue like got fixed
> before. The space between __ex_table and rodata is (seems?) unused, so
> the default page table permissions end up being W+X. Can we fix the
> default to be NX instead? It'll make these bugs stay gone.

Yeah. Wanna send a patch for that?

Thanks,

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

[toc] | [prev] | [next] | [standalone]


#1233223

FromKees Cook <keescook@chromium.org>
Date2015-09-26 18:50 +0200
Message-ID<qd0PD-5Bg-17@gated-at.bofh.it>
In reply to#1232627
On Fri, Sep 25, 2015 at 12:22 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Kees Cook <keescook@chromium.org> wrote:
>
>> On Thu, Sep 24, 2015 at 1:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> > Hi,
>> >
>> > With the attached config and 4.3-rc2 on x86_64, I see the following in /sys/kernel/debug/kernel_page_tables:
>> > ...
>> > ---[ High Kernel Mapping ]---
>> > 0xffffffff80000000-0xffffffff81000000          16M                               pmd
>> > 0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
>> > 0xffffffff81600000-0xffffffff81775000        1492K     ro                 GLB x  pte
>> > 0xffffffff81775000-0xffffffff81800000         556K     RW                 GLB x  pte
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > 0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
>> > 0xffffffff81a00000-0xffffffff81b43000        1292K     ro                 GLB NX pte
>> > 0xffffffff81b43000-0xffffffff82000000        4852K     RW                 GLB NX pte
>> > 0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
>> > 0xffffffff82200000-0xffffffffa0000000         478M                               pmd
>> > ...
>> >
>> > This region seems to be between the end of ex_table and the start of rodata,
>> > $ objdump -x vmlinux | sort
>> > ...
>> > ffffffff817728b0 g       __ex_table     0000000000000000 __start___ex_table
>> > ffffffff817728b0 l    d  __ex_table     0000000000000000 __ex_table
>> > ffffffff81774998 g       __ex_table     0000000000000000 __stop___ex_table
>> > ffffffff81800000 g       .rodata        0000000000000000 __start_rodata
>> > ffffffff81800000 l    d  .rodata        0000000000000000 .rodata
>> > ...
>> >
>> > $ readelf -a vmlinux
>> > ...
>> > Section Headers:
>> >   [Nr] Name              Type             Address           Offset
>> >        Size              EntSize          Flags  Link  Info  Align
>> > ...
>> >   [ 3] __ex_table        PROGBITS         ffffffff817728b0  009728b0
>> >        00000000000020e8  0000000000000000   A       0     0     8
>> >   [ 4] .rodata           PROGBITS         ffffffff81800000  00a00000
>> >        00000000002eefd2  0000000000000000   A       0     0     64
>> > ...
>> >
>> > I see a similar rwx mapping with the stock Fedora kernels (e.g. 4.1.6), so it isn't new to 4.3.
>>
>> To me it looks like another alignment/padding issue like got fixed
>> before. The space between __ex_table and rodata is (seems?) unused, so
>> the default page table permissions end up being W+X. Can we fix the
>> default to be NX instead? It'll make these bugs stay gone.
>
> Yeah. Wanna send a patch for that?

I haven't found where that is actually happening. :( If anyone has
pointers, I can dig a bit more.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1234480

From"H. Peter Anvin" <hpa@zytor.com>
Date2015-09-28 23:20 +0200
Message-ID<qdO04-2Tc-43@gated-at.bofh.it>
In reply to#1232627
On 09/25/2015 12:22 AM, Ingo Molnar wrote:
>>
>> To me it looks like another alignment/padding issue like got fixed
>> before. The space between __ex_table and rodata is (seems?) unused, so
>> the default page table permissions end up being W+X. Can we fix the
>> default to be NX instead? It'll make these bugs stay gone.
> 
> Yeah. Wanna send a patch for that?
> 

At least in the high mapping space, the default should be no permissions
(not present), rather than just NX.

	-hpa


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

[toc] | [prev] | [next] | [standalone]


#1234543

FromKees Cook <keescook@chromium.org>
Date2015-09-29 00:10 +0200
Message-ID<qdOMq-43G-1@gated-at.bofh.it>
In reply to#1234480
On Mon, Sep 28, 2015 at 2:16 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 09/25/2015 12:22 AM, Ingo Molnar wrote:
>>>
>>> To me it looks like another alignment/padding issue like got fixed
>>> before. The space between __ex_table and rodata is (seems?) unused, so
>>> the default page table permissions end up being W+X. Can we fix the
>>> default to be NX instead? It'll make these bugs stay gone.
>>
>> Yeah. Wanna send a patch for that?
>>
>
> At least in the high mapping space, the default should be no permissions
> (not present), rather than just NX.

Do you mean "should be" as in, that's how it's coded now, or "should
be" in that we need to fix it? (If we need to fix it, where is that
"default"? I haven't been able to find it yet.)

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1234550

From"H. Peter Anvin" <hpa@zytor.com>
Date2015-09-29 00:30 +0200
Message-ID<qdP5L-4q2-7@gated-at.bofh.it>
In reply to#1234543
Need to fix.  Not sure where the rwx mapping comes from.

On September 28, 2015 3:05:33 PM PDT, Kees Cook <keescook@chromium.org> wrote:
>On Mon, Sep 28, 2015 at 2:16 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 09/25/2015 12:22 AM, Ingo Molnar wrote:
>>>>
>>>> To me it looks like another alignment/padding issue like got fixed
>>>> before. The space between __ex_table and rodata is (seems?) unused,
>so
>>>> the default page table permissions end up being W+X. Can we fix the
>>>> default to be NX instead? It'll make these bugs stay gone.
>>>
>>> Yeah. Wanna send a patch for that?
>>>
>>
>> At least in the high mapping space, the default should be no
>permissions
>> (not present), rather than just NX.
>
>Do you mean "should be" as in, that's how it's coded now, or "should
>be" in that we need to fix it? (If we need to fix it, where is that
>"default"? I haven't been able to find it yet.)
>
>-Kees

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1234192

FromStephen Smalley <sds@tycho.nsa.gov>
Date2015-09-28 16:20 +0200
Message-ID<qdHrA-1Q9-15@gated-at.bofh.it>
In reply to#1232476
On 09/24/2015 06:25 PM, Kees Cook wrote:
> On Thu, Sep 24, 2015 at 1:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> Hi,
>>
>> With the attached config and 4.3-rc2 on x86_64, I see the following in /sys/kernel/debug/kernel_page_tables:
>> ...
>> ---[ High Kernel Mapping ]---
>> 0xffffffff80000000-0xffffffff81000000          16M                               pmd
>> 0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
>> 0xffffffff81600000-0xffffffff81775000        1492K     ro                 GLB x  pte
>> 0xffffffff81775000-0xffffffff81800000         556K     RW                 GLB x  pte
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
>> 0xffffffff81a00000-0xffffffff81b43000        1292K     ro                 GLB NX pte
>> 0xffffffff81b43000-0xffffffff82000000        4852K     RW                 GLB NX pte
>> 0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
>> 0xffffffff82200000-0xffffffffa0000000         478M                               pmd
>> ...
>>
>> This region seems to be between the end of ex_table and the start of rodata,
>> $ objdump -x vmlinux | sort
>> ...
>> ffffffff817728b0 g       __ex_table     0000000000000000 __start___ex_table
>> ffffffff817728b0 l    d  __ex_table     0000000000000000 __ex_table
>> ffffffff81774998 g       __ex_table     0000000000000000 __stop___ex_table
>> ffffffff81800000 g       .rodata        0000000000000000 __start_rodata
>> ffffffff81800000 l    d  .rodata        0000000000000000 .rodata
>> ...
>>
>> $ readelf -a vmlinux
>> ...
>> Section Headers:
>>   [Nr] Name              Type             Address           Offset
>>        Size              EntSize          Flags  Link  Info  Align
>> ...
>>   [ 3] __ex_table        PROGBITS         ffffffff817728b0  009728b0
>>        00000000000020e8  0000000000000000   A       0     0     8
>>   [ 4] .rodata           PROGBITS         ffffffff81800000  00a00000
>>        00000000002eefd2  0000000000000000   A       0     0     64
>> ...
>>
>> I see a similar rwx mapping with the stock Fedora kernels (e.g. 4.1.6), so it isn't new to 4.3.
> 
> To me it looks like another alignment/padding issue like got fixed
> before. The space between __ex_table and rodata is (seems?) unused, so
> the default page table permissions end up being W+X. Can we fix the
> default to be NX instead? It'll make these bugs stay gone.

Not sure where that would get fixed (or the ramifications), but is there
a reason we can't just do the following to fix this particular case?

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 30564e2..df48430 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1132,7 +1132,7 @@ void mark_rodata_ro(void)
 	 * has been zapped already via cleanup_highmem().
 	 */
 	all_end = roundup((unsigned long)_brk_end, PMD_SIZE);
-	set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
+	set_memory_nx(text_end, (all_end - text_end) >> PAGE_SHIFT);
 
 	rodata_test();


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

[toc] | [prev] | [next] | [standalone]


#1234338

FromKees Cook <keescook@chromium.org>
Date2015-09-28 20:30 +0200
Message-ID<qdLlw-7nn-3@gated-at.bofh.it>
In reply to#1234192
On Mon, Sep 28, 2015 at 7:11 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 09/24/2015 06:25 PM, Kees Cook wrote:
>> On Thu, Sep 24, 2015 at 1:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>> Hi,
>>>
>>> With the attached config and 4.3-rc2 on x86_64, I see the following in /sys/kernel/debug/kernel_page_tables:
>>> ...
>>> ---[ High Kernel Mapping ]---
>>> 0xffffffff80000000-0xffffffff81000000          16M                               pmd
>>> 0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
>>> 0xffffffff81600000-0xffffffff81775000        1492K     ro                 GLB x  pte
>>> 0xffffffff81775000-0xffffffff81800000         556K     RW                 GLB x  pte
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
>>> 0xffffffff81a00000-0xffffffff81b43000        1292K     ro                 GLB NX pte
>>> 0xffffffff81b43000-0xffffffff82000000        4852K     RW                 GLB NX pte
>>> 0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
>>> 0xffffffff82200000-0xffffffffa0000000         478M                               pmd
>>> ...
>>>
>>> This region seems to be between the end of ex_table and the start of rodata,
>>> $ objdump -x vmlinux | sort
>>> ...
>>> ffffffff817728b0 g       __ex_table     0000000000000000 __start___ex_table
>>> ffffffff817728b0 l    d  __ex_table     0000000000000000 __ex_table
>>> ffffffff81774998 g       __ex_table     0000000000000000 __stop___ex_table
>>> ffffffff81800000 g       .rodata        0000000000000000 __start_rodata
>>> ffffffff81800000 l    d  .rodata        0000000000000000 .rodata
>>> ...
>>>
>>> $ readelf -a vmlinux
>>> ...
>>> Section Headers:
>>>   [Nr] Name              Type             Address           Offset
>>>        Size              EntSize          Flags  Link  Info  Align
>>> ...
>>>   [ 3] __ex_table        PROGBITS         ffffffff817728b0  009728b0
>>>        00000000000020e8  0000000000000000   A       0     0     8
>>>   [ 4] .rodata           PROGBITS         ffffffff81800000  00a00000
>>>        00000000002eefd2  0000000000000000   A       0     0     64
>>> ...
>>>
>>> I see a similar rwx mapping with the stock Fedora kernels (e.g. 4.1.6), so it isn't new to 4.3.
>>
>> To me it looks like another alignment/padding issue like got fixed
>> before. The space between __ex_table and rodata is (seems?) unused, so
>> the default page table permissions end up being W+X. Can we fix the
>> default to be NX instead? It'll make these bugs stay gone.
>
> Not sure where that would get fixed (or the ramifications), but is there
> a reason we can't just do the following to fix this particular case?
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 30564e2..df48430 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1132,7 +1132,7 @@ void mark_rodata_ro(void)
>          * has been zapped already via cleanup_highmem().
>          */
>         all_end = roundup((unsigned long)_brk_end, PMD_SIZE);
> -       set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
> +       set_memory_nx(text_end, (all_end - text_end) >> PAGE_SHIFT);
>
>         rodata_test();
>
>

That should work, yeah. I'd still like to find the default permissions
and make them W+nx, though. Regardless, let's get the above added.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1237078

FromIngo Molnar <mingo@kernel.org>
Date2015-10-01 09:20 +0200
Message-ID<qeGjO-58Q-59@gated-at.bofh.it>
In reply to#1234338
* Kees Cook <keescook@chromium.org> wrote:

> On Mon, Sep 28, 2015 at 7:11 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On 09/24/2015 06:25 PM, Kees Cook wrote:
> >> On Thu, Sep 24, 2015 at 1:26 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >>> Hi,
> >>>
> >>> With the attached config and 4.3-rc2 on x86_64, I see the following in /sys/kernel/debug/kernel_page_tables:
> >>> ...
> >>> ---[ High Kernel Mapping ]---
> >>> 0xffffffff80000000-0xffffffff81000000          16M                               pmd
> >>> 0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
> >>> 0xffffffff81600000-0xffffffff81775000        1492K     ro                 GLB x  pte
> >>> 0xffffffff81775000-0xffffffff81800000         556K     RW                 GLB x  pte
> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>> 0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
> >>> 0xffffffff81a00000-0xffffffff81b43000        1292K     ro                 GLB NX pte
> >>> 0xffffffff81b43000-0xffffffff82000000        4852K     RW                 GLB NX pte
> >>> 0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
> >>> 0xffffffff82200000-0xffffffffa0000000         478M                               pmd
> >>> ...
> >>>
> >>> This region seems to be between the end of ex_table and the start of rodata,
> >>> $ objdump -x vmlinux | sort
> >>> ...
> >>> ffffffff817728b0 g       __ex_table     0000000000000000 __start___ex_table
> >>> ffffffff817728b0 l    d  __ex_table     0000000000000000 __ex_table
> >>> ffffffff81774998 g       __ex_table     0000000000000000 __stop___ex_table
> >>> ffffffff81800000 g       .rodata        0000000000000000 __start_rodata
> >>> ffffffff81800000 l    d  .rodata        0000000000000000 .rodata
> >>> ...
> >>>
> >>> $ readelf -a vmlinux
> >>> ...
> >>> Section Headers:
> >>>   [Nr] Name              Type             Address           Offset
> >>>        Size              EntSize          Flags  Link  Info  Align
> >>> ...
> >>>   [ 3] __ex_table        PROGBITS         ffffffff817728b0  009728b0
> >>>        00000000000020e8  0000000000000000   A       0     0     8
> >>>   [ 4] .rodata           PROGBITS         ffffffff81800000  00a00000
> >>>        00000000002eefd2  0000000000000000   A       0     0     64
> >>> ...
> >>>
> >>> I see a similar rwx mapping with the stock Fedora kernels (e.g. 4.1.6), so it isn't new to 4.3.
> >>
> >> To me it looks like another alignment/padding issue like got fixed
> >> before. The space between __ex_table and rodata is (seems?) unused, so
> >> the default page table permissions end up being W+X. Can we fix the
> >> default to be NX instead? It'll make these bugs stay gone.
> >
> > Not sure where that would get fixed (or the ramifications), but is there
> > a reason we can't just do the following to fix this particular case?
> >
> > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> > index 30564e2..df48430 100644
> > --- a/arch/x86/mm/init_64.c
> > +++ b/arch/x86/mm/init_64.c
> > @@ -1132,7 +1132,7 @@ void mark_rodata_ro(void)
> >          * has been zapped already via cleanup_highmem().
> >          */
> >         all_end = roundup((unsigned long)_brk_end, PMD_SIZE);
> > -       set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
> > +       set_memory_nx(text_end, (all_end - text_end) >> PAGE_SHIFT);
> >
> >         rodata_test();
> >
> >
> 
> That should work, yeah. I'd still like to find the default permissions
> and make them W+nx, though. Regardless, let's get the above added.

Ok, could someone please send a changelogged, signed off patch for this?

Thanks,

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

[toc] | [prev] | [next] | [standalone]


#1237158

FromThomas Gleixner <tglx@linutronix.de>
Date2015-10-01 11:10 +0200
Message-ID<qeI2d-7Z7-1@gated-at.bofh.it>
In reply to#1234338
On Mon, 28 Sep 2015, Kees Cook wrote:
> > --- a/arch/x86/mm/init_64.c
> > +++ b/arch/x86/mm/init_64.c
> > @@ -1132,7 +1132,7 @@ void mark_rodata_ro(void)
> >          * has been zapped already via cleanup_highmem().
> >          */
> >         all_end = roundup((unsigned long)_brk_end, PMD_SIZE);
> > -       set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
> > +       set_memory_nx(text_end, (all_end - text_end) >> PAGE_SHIFT);
> >
> >         rodata_test();
> >
> >
> 
> That should work, yeah. I'd still like to find the default permissions
> and make them W+nx, though. Regardless, let's get the above added.

The default permissions are set at boot time when setting up the early
page tables. When we split them up later on we inherit the PTE bits
and then we do that _ro/nx cleanup after the overall layout has been
settled.

We can't make them W+nx in the early setup without shooting ourself in
the foot, because we only set up at the pud/pmd level.

Thanks,

	tglx


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

[toc] | [prev] | [next] | [standalone]


#1237166

FromIngo Molnar <mingo@kernel.org>
Date2015-10-01 11:20 +0200
Message-ID<qeIbU-8aj-9@gated-at.bofh.it>
In reply to#1237158
* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Mon, 28 Sep 2015, Kees Cook wrote:
> > > --- a/arch/x86/mm/init_64.c
> > > +++ b/arch/x86/mm/init_64.c
> > > @@ -1132,7 +1132,7 @@ void mark_rodata_ro(void)
> > >          * has been zapped already via cleanup_highmem().
> > >          */
> > >         all_end = roundup((unsigned long)_brk_end, PMD_SIZE);
> > > -       set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
> > > +       set_memory_nx(text_end, (all_end - text_end) >> PAGE_SHIFT);
> > >
> > >         rodata_test();
> > >
> > >
> > 
> > That should work, yeah. I'd still like to find the default permissions and 
> > make them W+nx, though. Regardless, let's get the above added.
> 
> The default permissions are set at boot time when setting up the early page 
> tables. When we split them up later on we inherit the PTE bits and then we do 
> that _ro/nx cleanup after the overall layout has been settled.
> 
> We can't make them W+nx in the early setup without shooting ourself in the foot, 
> because we only set up at the pud/pmd level.

So I think at minimum we should do a (debug) scan in late init, of the whole 
range, for any leftover WX permissions? That would have caught this bug. (and 
might catch other existing bugs that might occur with various configs/hw-layouts.)

Thanks,

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

[toc] | [prev] | [next] | [standalone]


#1237598

FromKees Cook <keescook@chromium.org>
Date2015-10-01 19:50 +0200
Message-ID<qeQ9s-39m-25@gated-at.bofh.it>
In reply to#1237166
On Thu, Oct 1, 2015 at 2:12 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> On Mon, 28 Sep 2015, Kees Cook wrote:
>> > > --- a/arch/x86/mm/init_64.c
>> > > +++ b/arch/x86/mm/init_64.c
>> > > @@ -1132,7 +1132,7 @@ void mark_rodata_ro(void)
>> > >          * has been zapped already via cleanup_highmem().
>> > >          */
>> > >         all_end = roundup((unsigned long)_brk_end, PMD_SIZE);
>> > > -       set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
>> > > +       set_memory_nx(text_end, (all_end - text_end) >> PAGE_SHIFT);
>> > >
>> > >         rodata_test();
>> > >
>> > >
>> >
>> > That should work, yeah. I'd still like to find the default permissions and
>> > make them W+nx, though. Regardless, let's get the above added.
>>
>> The default permissions are set at boot time when setting up the early page
>> tables. When we split them up later on we inherit the PTE bits and then we do
>> that _ro/nx cleanup after the overall layout has been settled.
>>
>> We can't make them W+nx in the early setup without shooting ourself in the foot,
>> because we only set up at the pud/pmd level.
>
> So I think at minimum we should do a (debug) scan in late init, of the whole
> range, for any leftover WX permissions? That would have caught this bug. (and
> might catch other existing bugs that might occur with various configs/hw-layouts.)

I think this would be great. I'd like to disassociate it from PTDUMP,
though, since that exposes kernel address to userspace. It'd be nice
to have the check without also the debugfs entry.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1237999

FromIngo Molnar <mingo@kernel.org>
Date2015-10-02 09:20 +0200
Message-ID<qf2Nk-4OQ-31@gated-at.bofh.it>
In reply to#1237598
* Kees Cook <keescook@chromium.org> wrote:

> On Thu, Oct 1, 2015 at 2:12 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> >> On Mon, 28 Sep 2015, Kees Cook wrote:
> >> > > --- a/arch/x86/mm/init_64.c
> >> > > +++ b/arch/x86/mm/init_64.c
> >> > > @@ -1132,7 +1132,7 @@ void mark_rodata_ro(void)
> >> > >          * has been zapped already via cleanup_highmem().
> >> > >          */
> >> > >         all_end = roundup((unsigned long)_brk_end, PMD_SIZE);
> >> > > -       set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
> >> > > +       set_memory_nx(text_end, (all_end - text_end) >> PAGE_SHIFT);
> >> > >
> >> > >         rodata_test();
> >> > >
> >> > >
> >> >
> >> > That should work, yeah. I'd still like to find the default permissions and
> >> > make them W+nx, though. Regardless, let's get the above added.
> >>
> >> The default permissions are set at boot time when setting up the early page
> >> tables. When we split them up later on we inherit the PTE bits and then we do
> >> that _ro/nx cleanup after the overall layout has been settled.
> >>
> >> We can't make them W+nx in the early setup without shooting ourself in the foot,
> >> because we only set up at the pud/pmd level.
> >
> > So I think at minimum we should do a (debug) scan in late init, of the whole
> > range, for any leftover WX permissions? That would have caught this bug. (and
> > might catch other existing bugs that might occur with various configs/hw-layouts.)
> 
> I think this would be great. I'd like to disassociate it from PTDUMP,
> though, since that exposes kernel address to userspace. It'd be nice
> to have the check without also the debugfs entry.

Yeah, so it could still use pretty much the same code, except no registry in 
/debug?

Thanks,

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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web