From: James Hogan <james.hogan@imgtec.com>
To: Kees Cook <keescook@chromium.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
Petr Mladek <pmladek@suse.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, <linux-metag@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: qemu:metag image runtime failure in -next due to 'kthread: allow to cancel kthread work'
Date: Mon, 19 Sep 2016 23:57:17 +0100 [thread overview]
Message-ID: <20160919225717.GO18931@jhogan-linux.le.imgtec.org> (raw)
In-Reply-To: <CAGXu5jL6J3PNkxMi7UXj7jPVr6AQuHeMb2mygL4Y9thyi5M2TA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4054 bytes --]
On Mon, Sep 19, 2016 at 02:51:54PM -0700, Kees Cook wrote:
> On Mon, Sep 19, 2016 at 2:37 PM, James Hogan <james.hogan@imgtec.com> wrote:
> > Okay, I just built x86_64 default defconfig (on ef98de028afd, half way
> > through the mm patches on linux-next from the other day where metag
> > stopped booting). Perhaps I'm missing some important config option to
> > enable the memory protection (if so I appologise).
> >
> > For metag:
> >
> > $ readelf -S drivers/tty/pty.o
> > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> > [51] .data..ro_after_i PROGBITS 00000000 00f0c0 00007c 00 WA 0 0 4
> >
> > $ readelf -S vmlinux.bust:
> > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> > [ 4] .rodata PROGBITS 40190000 194000 04c9c8 00 WA 0 0 64
> >
> > And x86_64:
> >
> > $ readelf -S drivers/tty/pty.o
> > [Nr] Name Type Address Offset
> > Size EntSize Flags Link Info Align
> > [18] .data..ro_after_i PROGBITS 0000000000000000 00001140
> > 00000000000000f8 0000000000000000 WA 0 0 64
> >
> > $ readelf -S vmlinux
> > [Nr] Name Type Address Offset
> > Size EntSize Flags Link Info Align
> > [ 4] .rodata PROGBITS ffffffff81a00000 00c00000
> > 00000000002663d0 0000000000000000 WA 0 0 4096
> >
> > Both have WA on that section in the object file and the final vmlinux
> > ELF too.
>
> Hm, very true, I never noticed that. Oddly, the LOAD flags don't pay
> any attention on x86:
>
> $ readelf -l vmlinux
>
> Elf file type is EXEC (Executable file)
> Entry point 0x1000000
> There are 5 program headers, starting at offset 64
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000200000 0xffffffff81000000 0x0000000001000000
> 0x0000000000fdc000 0x0000000000fdc000 R E 200000
> LOAD 0x0000000001200000 0xffffffff82000000 0x0000000002000000
> 0x0000000000155000 0x0000000000155000 RW 200000
> LOAD 0x0000000001400000 0x0000000000000000 0x0000000002155000
> 0x0000000000019488 0x0000000000019488 RW 200000
> LOAD 0x000000000156f000 0xffffffff8216f000 0x000000000216f000
> 0x0000000000122000 0x0000000000eb4000 RWE 200000
> NOTE 0x0000000000ca0248 0xffffffff81aa0248 0x0000000001aa0248
> 0x0000000000000024 0x0000000000000024 4
>
> Section to Segment mapping:
> Segment Sections...
> 00 .text .notes __ex_table .rodata __bug_table .pci_fixup
> .builtin_fw .tracedata __ksymtab __ksymtab_gpl __ksymtab_strings
> __param __modver
> 01 .data .vvar
> 02 .data..percpu
> 03 .init.text .altinstr_aux .init.data .x86_cpu_dev.init
> .altinstructions .altinstr_replacement .iommu_table .apicdrivers
> .exit.text .smp_locks .bss .brk
> 04 .notes
>
> The first load (containing .rodata) is "R E".
Aah, right, I think thats because the program headers are specified
explicitly in arch/x86/kernel/vmlinux.lds.S:
PHDRS {
text PT_LOAD FLAGS(5); /* R_E */
data PT_LOAD FLAGS(6); /* RW_ */
#ifdef CONFIG_X86_64
#ifdef CONFIG_SMP
percpu PT_LOAD FLAGS(6); /* RW_ */
#endif
init PT_LOAD FLAGS(7); /* RWE */
#endif
note PT_NOTE FLAGS(0); /* ___ */
}
The bit I was missing is that RO_DATA() is after .text, but before
.data, so counts as part of the PT_LOAD program header for text.
>
> But, the point is: the kernel is what sets up the permissions, so the
> flags are ignored anyway.
Indeed.
Thanks for your patience working through this stuff with me :)
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@imgtec.com>
To: Kees Cook <keescook@chromium.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
Petr Mladek <pmladek@suse.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>,
linux-metag@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: [kernel-hardening] Re: qemu:metag image runtime failure in -next due to 'kthread: allow to cancel kthread work'
Date: Mon, 19 Sep 2016 23:57:17 +0100 [thread overview]
Message-ID: <20160919225717.GO18931@jhogan-linux.le.imgtec.org> (raw)
In-Reply-To: <CAGXu5jL6J3PNkxMi7UXj7jPVr6AQuHeMb2mygL4Y9thyi5M2TA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4054 bytes --]
On Mon, Sep 19, 2016 at 02:51:54PM -0700, Kees Cook wrote:
> On Mon, Sep 19, 2016 at 2:37 PM, James Hogan <james.hogan@imgtec.com> wrote:
> > Okay, I just built x86_64 default defconfig (on ef98de028afd, half way
> > through the mm patches on linux-next from the other day where metag
> > stopped booting). Perhaps I'm missing some important config option to
> > enable the memory protection (if so I appologise).
> >
> > For metag:
> >
> > $ readelf -S drivers/tty/pty.o
> > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> > [51] .data..ro_after_i PROGBITS 00000000 00f0c0 00007c 00 WA 0 0 4
> >
> > $ readelf -S vmlinux.bust:
> > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> > [ 4] .rodata PROGBITS 40190000 194000 04c9c8 00 WA 0 0 64
> >
> > And x86_64:
> >
> > $ readelf -S drivers/tty/pty.o
> > [Nr] Name Type Address Offset
> > Size EntSize Flags Link Info Align
> > [18] .data..ro_after_i PROGBITS 0000000000000000 00001140
> > 00000000000000f8 0000000000000000 WA 0 0 64
> >
> > $ readelf -S vmlinux
> > [Nr] Name Type Address Offset
> > Size EntSize Flags Link Info Align
> > [ 4] .rodata PROGBITS ffffffff81a00000 00c00000
> > 00000000002663d0 0000000000000000 WA 0 0 4096
> >
> > Both have WA on that section in the object file and the final vmlinux
> > ELF too.
>
> Hm, very true, I never noticed that. Oddly, the LOAD flags don't pay
> any attention on x86:
>
> $ readelf -l vmlinux
>
> Elf file type is EXEC (Executable file)
> Entry point 0x1000000
> There are 5 program headers, starting at offset 64
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000200000 0xffffffff81000000 0x0000000001000000
> 0x0000000000fdc000 0x0000000000fdc000 R E 200000
> LOAD 0x0000000001200000 0xffffffff82000000 0x0000000002000000
> 0x0000000000155000 0x0000000000155000 RW 200000
> LOAD 0x0000000001400000 0x0000000000000000 0x0000000002155000
> 0x0000000000019488 0x0000000000019488 RW 200000
> LOAD 0x000000000156f000 0xffffffff8216f000 0x000000000216f000
> 0x0000000000122000 0x0000000000eb4000 RWE 200000
> NOTE 0x0000000000ca0248 0xffffffff81aa0248 0x0000000001aa0248
> 0x0000000000000024 0x0000000000000024 4
>
> Section to Segment mapping:
> Segment Sections...
> 00 .text .notes __ex_table .rodata __bug_table .pci_fixup
> .builtin_fw .tracedata __ksymtab __ksymtab_gpl __ksymtab_strings
> __param __modver
> 01 .data .vvar
> 02 .data..percpu
> 03 .init.text .altinstr_aux .init.data .x86_cpu_dev.init
> .altinstructions .altinstr_replacement .iommu_table .apicdrivers
> .exit.text .smp_locks .bss .brk
> 04 .notes
>
> The first load (containing .rodata) is "R E".
Aah, right, I think thats because the program headers are specified
explicitly in arch/x86/kernel/vmlinux.lds.S:
PHDRS {
text PT_LOAD FLAGS(5); /* R_E */
data PT_LOAD FLAGS(6); /* RW_ */
#ifdef CONFIG_X86_64
#ifdef CONFIG_SMP
percpu PT_LOAD FLAGS(6); /* RW_ */
#endif
init PT_LOAD FLAGS(7); /* RWE */
#endif
note PT_NOTE FLAGS(0); /* ___ */
}
The bit I was missing is that RO_DATA() is after .text, but before
.data, so counts as part of the PT_LOAD program header for text.
>
> But, the point is: the kernel is what sets up the permissions, so the
> flags are ignored anyway.
Indeed.
Thanks for your patience working through this stuff with me :)
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
To: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>,
Petr Mladek <pmladek-IBi9RG/b67k@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-metag-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org"
<kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org>
Subject: Re: qemu:metag image runtime failure in -next due to 'kthread: allow to cancel kthread work'
Date: Mon, 19 Sep 2016 23:57:17 +0100 [thread overview]
Message-ID: <20160919225717.GO18931@jhogan-linux.le.imgtec.org> (raw)
In-Reply-To: <CAGXu5jL6J3PNkxMi7UXj7jPVr6AQuHeMb2mygL4Y9thyi5M2TA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4083 bytes --]
On Mon, Sep 19, 2016 at 02:51:54PM -0700, Kees Cook wrote:
> On Mon, Sep 19, 2016 at 2:37 PM, James Hogan <james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org> wrote:
> > Okay, I just built x86_64 default defconfig (on ef98de028afd, half way
> > through the mm patches on linux-next from the other day where metag
> > stopped booting). Perhaps I'm missing some important config option to
> > enable the memory protection (if so I appologise).
> >
> > For metag:
> >
> > $ readelf -S drivers/tty/pty.o
> > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> > [51] .data..ro_after_i PROGBITS 00000000 00f0c0 00007c 00 WA 0 0 4
> >
> > $ readelf -S vmlinux.bust:
> > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> > [ 4] .rodata PROGBITS 40190000 194000 04c9c8 00 WA 0 0 64
> >
> > And x86_64:
> >
> > $ readelf -S drivers/tty/pty.o
> > [Nr] Name Type Address Offset
> > Size EntSize Flags Link Info Align
> > [18] .data..ro_after_i PROGBITS 0000000000000000 00001140
> > 00000000000000f8 0000000000000000 WA 0 0 64
> >
> > $ readelf -S vmlinux
> > [Nr] Name Type Address Offset
> > Size EntSize Flags Link Info Align
> > [ 4] .rodata PROGBITS ffffffff81a00000 00c00000
> > 00000000002663d0 0000000000000000 WA 0 0 4096
> >
> > Both have WA on that section in the object file and the final vmlinux
> > ELF too.
>
> Hm, very true, I never noticed that. Oddly, the LOAD flags don't pay
> any attention on x86:
>
> $ readelf -l vmlinux
>
> Elf file type is EXEC (Executable file)
> Entry point 0x1000000
> There are 5 program headers, starting at offset 64
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000200000 0xffffffff81000000 0x0000000001000000
> 0x0000000000fdc000 0x0000000000fdc000 R E 200000
> LOAD 0x0000000001200000 0xffffffff82000000 0x0000000002000000
> 0x0000000000155000 0x0000000000155000 RW 200000
> LOAD 0x0000000001400000 0x0000000000000000 0x0000000002155000
> 0x0000000000019488 0x0000000000019488 RW 200000
> LOAD 0x000000000156f000 0xffffffff8216f000 0x000000000216f000
> 0x0000000000122000 0x0000000000eb4000 RWE 200000
> NOTE 0x0000000000ca0248 0xffffffff81aa0248 0x0000000001aa0248
> 0x0000000000000024 0x0000000000000024 4
>
> Section to Segment mapping:
> Segment Sections...
> 00 .text .notes __ex_table .rodata __bug_table .pci_fixup
> .builtin_fw .tracedata __ksymtab __ksymtab_gpl __ksymtab_strings
> __param __modver
> 01 .data .vvar
> 02 .data..percpu
> 03 .init.text .altinstr_aux .init.data .x86_cpu_dev.init
> .altinstructions .altinstr_replacement .iommu_table .apicdrivers
> .exit.text .smp_locks .bss .brk
> 04 .notes
>
> The first load (containing .rodata) is "R E".
Aah, right, I think thats because the program headers are specified
explicitly in arch/x86/kernel/vmlinux.lds.S:
PHDRS {
text PT_LOAD FLAGS(5); /* R_E */
data PT_LOAD FLAGS(6); /* RW_ */
#ifdef CONFIG_X86_64
#ifdef CONFIG_SMP
percpu PT_LOAD FLAGS(6); /* RW_ */
#endif
init PT_LOAD FLAGS(7); /* RWE */
#endif
note PT_NOTE FLAGS(0); /* ___ */
}
The bit I was missing is that RO_DATA() is after .text, but before
.data, so counts as part of the PT_LOAD program header for text.
>
> But, the point is: the kernel is what sets up the permissions, so the
> flags are ignored anyway.
Indeed.
Thanks for your patience working through this stuff with me :)
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-09-19 22:57 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-16 20:38 qemu:metag image runtime failure in -next due to 'kthread: allow to cancel kthread work' Guenter Roeck
2016-09-16 21:27 ` James Hogan
2016-09-16 21:27 ` James Hogan
2016-09-16 21:37 ` Guenter Roeck
2016-09-16 21:37 ` Guenter Roeck
2016-09-16 23:32 ` James Hogan
2016-09-16 23:32 ` James Hogan
2016-09-16 23:32 ` [kernel-hardening] " James Hogan
2016-09-17 2:58 ` Kees Cook
2016-09-17 2:58 ` Kees Cook
2016-09-17 2:58 ` [kernel-hardening] " Kees Cook
2016-09-19 13:59 ` James Hogan
2016-09-19 13:59 ` James Hogan
2016-09-19 13:59 ` [kernel-hardening] " James Hogan
2016-09-19 19:53 ` Kees Cook
2016-09-19 19:53 ` [kernel-hardening] " Kees Cook
2016-09-19 21:37 ` James Hogan
2016-09-19 21:37 ` James Hogan
2016-09-19 21:37 ` [kernel-hardening] " James Hogan
2016-09-19 21:51 ` Kees Cook
2016-09-19 21:51 ` [kernel-hardening] " Kees Cook
2016-09-19 22:57 ` James Hogan [this message]
2016-09-19 22:57 ` James Hogan
2016-09-19 22:57 ` [kernel-hardening] " James Hogan
2016-09-19 23:19 ` Kees Cook
2016-09-19 23:19 ` Kees Cook
2016-09-19 23:19 ` [kernel-hardening] " Kees Cook
2016-09-19 14:55 ` James Hogan
2016-09-19 14:55 ` James Hogan
2016-09-19 14:55 ` [kernel-hardening] " James Hogan
2016-09-19 15:45 ` Guenter Roeck
2016-09-19 15:45 ` Guenter Roeck
2016-09-19 15:45 ` [kernel-hardening] " Guenter Roeck
2016-09-27 10:12 ` Petr Mladek
2016-09-27 10:12 ` Petr Mladek
2016-09-27 10:12 ` [kernel-hardening] " Petr Mladek
2016-09-27 10:19 ` James Hogan
2016-09-27 10:19 ` James Hogan
2016-09-27 10:19 ` [kernel-hardening] " James Hogan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160919225717.GO18931@jhogan-linux.le.imgtec.org \
--to=james.hogan@imgtec.com \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-metag@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mingo@kernel.org \
--cc=pmladek@suse.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.