Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1648218 > unrolled thread
| Started by | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| First post | 2017-05-23 17:50 +0200 |
| Last post | 2017-05-24 08:30 +0200 |
| Articles | 6 — 3 participants |
Back to article view | Back to linux.kernel
[WARNING] x86/mm: Found insecure W+X mapping at address .. Thomas Gleixner <tglx@linutronix.de> - 2017-05-23 17:50 +0200
Re: [WARNING] x86/mm: Found insecure W+X mapping at address .. Kees Cook <keescook@chromium.org> - 2017-05-23 18:00 +0200
Re: [WARNING] x86/mm: Found insecure W+X mapping at address .. Thomas Gleixner <tglx@linutronix.de> - 2017-05-23 18:40 +0200
Re: [WARNING] x86/mm: Found insecure W+X mapping at address .. Thomas Gleixner <tglx@linutronix.de> - 2017-05-23 22:50 +0200
Re: [WARNING] x86/mm: Found insecure W+X mapping at address .. Steven Rostedt <rostedt@goodmis.org> - 2017-05-24 01:00 +0200
Re: [WARNING] x86/mm: Found insecure W+X mapping at address .. Thomas Gleixner <tglx@linutronix.de> - 2017-05-24 08:30 +0200
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-05-23 17:50 +0200 |
| Subject | [WARNING] x86/mm: Found insecure W+X mapping at address .. |
| Message-ID | <tKkem-58v-23@gated-at.bofh.it> |
As of 4.12-rc1 one of my machines triggers the insecure W+X mapping. It's consistenly 9 entries close to the beginning of the module space, before the first actual module starts. See below. Any ideas which avoid bisecting would be appreciated. Thanks, tglx ---[ Modules ]--- 0xffffffffc0000000-0xffffffffc017d000 1524K pte 0xffffffffc017d000-0xffffffffc017e000 4K RW GLB x pte 0xffffffffc017e000-0xffffffffc017f000 4K pte 0xffffffffc017f000-0xffffffffc0180000 4K RW GLB x pte 0xffffffffc0180000-0xffffffffc0181000 4K pte 0xffffffffc0181000-0xffffffffc0182000 4K RW GLB x pte 0xffffffffc0182000-0xffffffffc0183000 4K pte 0xffffffffc0183000-0xffffffffc0184000 4K RW GLB x pte 0xffffffffc0184000-0xffffffffc0185000 4K pte 0xffffffffc0185000-0xffffffffc0186000 4K RW GLB x pte 0xffffffffc0186000-0xffffffffc0187000 4K pte 0xffffffffc0187000-0xffffffffc0188000 4K RW GLB x pte 0xffffffffc0188000-0xffffffffc0189000 4K pte 0xffffffffc0189000-0xffffffffc018a000 4K RW GLB x pte 0xffffffffc018a000-0xffffffffc018b000 4K pte 0xffffffffc018b000-0xffffffffc018c000 4K RW GLB x pte 0xffffffffc018c000-0xffffffffc018d000 4K pte 0xffffffffc018d000-0xffffffffc018e000 4K RW GLB x pte First module starts here: 0xffffffffc018e000-0xffffffffc0191000 12K pte 0xffffffffc0191000-0xffffffffc0192000 4K ro GLB x pte ---[ Modules ]--- 0xffffffffc0000000-0xffffffffc0200000 2M pmd 0xffffffffc0200000-0xffffffffc02f8000 992K pte 0xffffffffc02f8000-0xffffffffc02f9000 4K RW GLB x pte 0xffffffffc02f9000-0xffffffffc02fa000 4K pte 0xffffffffc02fa000-0xffffffffc02fb000 4K RW GLB x pte 0xffffffffc02fb000-0xffffffffc02fc000 4K pte 0xffffffffc02fc000-0xffffffffc02fd000 4K RW GLB x pte 0xffffffffc02fd000-0xffffffffc02fe000 4K pte 0xffffffffc02fe000-0xffffffffc02ff000 4K RW GLB x pte 0xffffffffc02ff000-0xffffffffc0300000 4K pte 0xffffffffc0300000-0xffffffffc0301000 4K RW GLB x pte 0xffffffffc0301000-0xffffffffc0302000 4K pte 0xffffffffc0302000-0xffffffffc0303000 4K RW GLB x pte 0xffffffffc0303000-0xffffffffc0304000 4K pte 0xffffffffc0304000-0xffffffffc0305000 4K RW GLB x pte 0xffffffffc0305000-0xffffffffc0306000 4K pte 0xffffffffc0306000-0xffffffffc0307000 4K RW GLB x pte 0xffffffffc0307000-0xffffffffc0308000 4K pte 0xffffffffc0308000-0xffffffffc0309000 4K RW GLB x pte First module starts here: 0xffffffffc0309000-0xffffffffc030c000 12K pte 0xffffffffc030c000-0xffffffffc030d000 4K ro GLB x pte
[toc] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2017-05-23 18:00 +0200 |
| Message-ID | <tKko1-5cc-1@gated-at.bofh.it> |
| In reply to | #1648218 |
On Tue, May 23, 2017 at 8:40 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > As of 4.12-rc1 one of my machines triggers the insecure W+X mapping. > > It's consistenly 9 entries close to the beginning of the module space, > before the first actual module starts. See below. > > Any ideas which avoid bisecting would be appreciated. Is this the same as: https://lkml.org/lkml/2017/5/19/899 ? The location is very similar. -Kees > > Thanks, > > tglx > > ---[ Modules ]--- > 0xffffffffc0000000-0xffffffffc017d000 1524K pte > 0xffffffffc017d000-0xffffffffc017e000 4K RW GLB x pte > 0xffffffffc017e000-0xffffffffc017f000 4K pte > 0xffffffffc017f000-0xffffffffc0180000 4K RW GLB x pte > 0xffffffffc0180000-0xffffffffc0181000 4K pte > 0xffffffffc0181000-0xffffffffc0182000 4K RW GLB x pte > 0xffffffffc0182000-0xffffffffc0183000 4K pte > 0xffffffffc0183000-0xffffffffc0184000 4K RW GLB x pte > 0xffffffffc0184000-0xffffffffc0185000 4K pte > 0xffffffffc0185000-0xffffffffc0186000 4K RW GLB x pte > 0xffffffffc0186000-0xffffffffc0187000 4K pte > 0xffffffffc0187000-0xffffffffc0188000 4K RW GLB x pte > 0xffffffffc0188000-0xffffffffc0189000 4K pte > 0xffffffffc0189000-0xffffffffc018a000 4K RW GLB x pte > 0xffffffffc018a000-0xffffffffc018b000 4K pte > 0xffffffffc018b000-0xffffffffc018c000 4K RW GLB x pte > 0xffffffffc018c000-0xffffffffc018d000 4K pte > 0xffffffffc018d000-0xffffffffc018e000 4K RW GLB x pte > > First module starts here: > > 0xffffffffc018e000-0xffffffffc0191000 12K pte > 0xffffffffc0191000-0xffffffffc0192000 4K ro GLB x pte > > ---[ Modules ]--- > 0xffffffffc0000000-0xffffffffc0200000 2M pmd > 0xffffffffc0200000-0xffffffffc02f8000 992K pte > 0xffffffffc02f8000-0xffffffffc02f9000 4K RW GLB x pte > 0xffffffffc02f9000-0xffffffffc02fa000 4K pte > 0xffffffffc02fa000-0xffffffffc02fb000 4K RW GLB x pte > 0xffffffffc02fb000-0xffffffffc02fc000 4K pte > 0xffffffffc02fc000-0xffffffffc02fd000 4K RW GLB x pte > 0xffffffffc02fd000-0xffffffffc02fe000 4K pte > 0xffffffffc02fe000-0xffffffffc02ff000 4K RW GLB x pte > 0xffffffffc02ff000-0xffffffffc0300000 4K pte > 0xffffffffc0300000-0xffffffffc0301000 4K RW GLB x pte > 0xffffffffc0301000-0xffffffffc0302000 4K pte > 0xffffffffc0302000-0xffffffffc0303000 4K RW GLB x pte > 0xffffffffc0303000-0xffffffffc0304000 4K pte > 0xffffffffc0304000-0xffffffffc0305000 4K RW GLB x pte > 0xffffffffc0305000-0xffffffffc0306000 4K pte > 0xffffffffc0306000-0xffffffffc0307000 4K RW GLB x pte > 0xffffffffc0307000-0xffffffffc0308000 4K pte > 0xffffffffc0308000-0xffffffffc0309000 4K RW GLB x pte > > First module starts here: > > 0xffffffffc0309000-0xffffffffc030c000 12K pte > 0xffffffffc030c000-0xffffffffc030d000 4K ro GLB x pte -- Kees Cook Pixel Security
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-05-23 18:40 +0200 |
| Message-ID | <tKl0L-5Ft-35@gated-at.bofh.it> |
| In reply to | #1648220 |
On Tue, 23 May 2017, Kees Cook wrote: > On Tue, May 23, 2017 at 8:40 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > > As of 4.12-rc1 one of my machines triggers the insecure W+X mapping. > > > It's consistenly 9 entries close to the beginning of the module space, > > before the first actual module starts. See below. > > > > Any ideas which avoid bisecting would be appreciated. > > Is this the same as: > > https://lkml.org/lkml/2017/5/19/899 > > ? > > The location is very similar. CONFIG_KPROBES_SANITY_TEST=n does not make it go away, but I suspect it's something in that area, as I recently switched on all of these self tests. I'll dig into it later today. Need to walk the dogs first. Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-05-23 22:50 +0200 |
| Message-ID | <tKoUI-8uq-61@gated-at.bofh.it> |
| In reply to | #1648260 |
On Tue, 23 May 2017, Thomas Gleixner wrote: > On Tue, 23 May 2017, Kees Cook wrote: > > On Tue, May 23, 2017 at 8:40 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > > > As of 4.12-rc1 one of my machines triggers the insecure W+X mapping. > > > > > It's consistenly 9 entries close to the beginning of the module space, > > > before the first actual module starts. See below. > > > > > > Any ideas which avoid bisecting would be appreciated. > > > > Is this the same as: > > > > https://lkml.org/lkml/2017/5/19/899 > > > > ? > > > > The location is very similar. > > CONFIG_KPROBES_SANITY_TEST=n does not make it go away, but I suspect it's > something in that area, as I recently switched on all of these self tests. > > I'll dig into it later today. Need to walk the dogs first. It's not KPROBES, it's the new fangled ftrace trampoline code. I added a few printks. All the leaked W+X mappings are allocated via this callchain: [ 2.620465] module_alloc+0x8e/0xa0 [ 2.620764] ? __fentry__+0x10/0x10 [ 2.621049] arch_ftrace_update_trampoline+0x9f/0x220 [ 2.621453] ? ftrace_caller+0x64/0x64 [ 2.621754] ? __fentry__+0x10/0x10 [ 2.622047] ftrace_startup+0x90/0x200 [ 2.622352] register_ftrace_function+0x50/0x70 [ 2.622725] function_trace_init+0x6d/0xa0 [ 2.623057] trace_selftest_startup_function+0x63/0x4a8 [ 2.623477] run_tracer_selftest+0xfe/0x16c [ 2.623813] init_trace_selftests+0x5d/0x103 [ 2.624163] ? set_tracepoint_printk+0x3d/0x3d [ 2.624525] do_one_initcall+0x44/0x170 [ 2.624845] kernel_init_freeable+0x1ff/0x287 [ 2.625199] ? rest_init+0x140/0x140 [ 2.625491] kernel_init+0xe/0x110 [ 2.625775] ret_from_fork+0x2e/0x40 Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Steven Rostedt <rostedt@goodmis.org> |
|---|---|
| Date | 2017-05-24 01:00 +0200 |
| Message-ID | <tKqWu-1xx-7@gated-at.bofh.it> |
| In reply to | #1648626 |
On Tue, 23 May 2017 22:48:19 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote: > It's not KPROBES, it's the new fangled ftrace trampoline code. I > added a few printks. All the leaked W+X mappings are allocated via > this callchain: The trampoline code isn't new. But it has new users because of the introduction to synchronize_rcu_tasks(), and there was a bug I fixed in -rc2 that moved it down because the test was run before synchronize_rcu_tasks() was functional. Is this still a bug in rc2? -- Steve > > [ 2.620465] module_alloc+0x8e/0xa0 > [ 2.620764] ? __fentry__+0x10/0x10 > [ 2.621049] arch_ftrace_update_trampoline+0x9f/0x220 > [ 2.621453] ? ftrace_caller+0x64/0x64 > [ 2.621754] ? __fentry__+0x10/0x10 > [ 2.622047] ftrace_startup+0x90/0x200 > [ 2.622352] register_ftrace_function+0x50/0x70 > [ 2.622725] function_trace_init+0x6d/0xa0 > [ 2.623057] trace_selftest_startup_function+0x63/0x4a8 > [ 2.623477] run_tracer_selftest+0xfe/0x16c > [ 2.623813] init_trace_selftests+0x5d/0x103 > [ 2.624163] ? set_tracepoint_printk+0x3d/0x3d > [ 2.624525] do_one_initcall+0x44/0x170 > [ 2.624845] kernel_init_freeable+0x1ff/0x287 > [ 2.625199] ? rest_init+0x140/0x140 > [ 2.625491] kernel_init+0xe/0x110 > [ 2.625775] ret_from_fork+0x2e/0x40 > > Thanks, > > tglx
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-05-24 08:30 +0200 |
| Message-ID | <tKxXY-71C-17@gated-at.bofh.it> |
| In reply to | #1648993 |
On Tue, 23 May 2017, Steven Rostedt wrote: > On Tue, 23 May 2017 22:48:19 +0200 (CEST) > Thomas Gleixner <tglx@linutronix.de> wrote: > > > > It's not KPROBES, it's the new fangled ftrace trampoline code. I > > added a few printks. All the leaked W+X mappings are allocated via > > this callchain: > > The trampoline code isn't new. But it has new users because of the > introduction to synchronize_rcu_tasks(), and there was a bug I fixed in > -rc2 that moved it down because the test was run before > synchronize_rcu_tasks() was functional. > > Is this still a bug in rc2? Yes. Otherwise we wouldn't talking about. Thanks, tglx
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web