* 4.4-rc0: 5 W+X pages found @ 2015-11-15 7:00 Pavel Machek 2015-11-23 14:37 ` Mihai Donțu 2015-12-14 8:04 ` 4.4-rc5: ugly warn on: " Pavel Machek 0 siblings, 2 replies; 39+ messages in thread From: Pavel Machek @ 2015-11-15 7:00 UTC (permalink / raw) To: kernel list Hi! Kernel complains: [ 5.256044] ------------[ cut here ]------------ [ 5.259267] WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() [ 5.262668] x86/mm: Found insecure W+X mapping at address ffe69000/0xffe69000 [ 5.267109] Modules linked in: [ 5.271403] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #122 [ 5.275679] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011 [ 5.279957] 00000000 00000000 f5cffeac c42b9f18 f5cffed8 f5cffec8 c404062b 000000e1 [ 5.284387] c403ca9c f5cfff50 00000163 00000000 f5cffee0 c4040686 00000009 f5cffed8 [ 5.288815] c4d268ac f5cffef4 f5cfff1c c403ca9c c4d1f494 000000e1 c4d268ac ffe69000 [ 5.293314] Call Trace: [ 5.297602] [<c42b9f18>] dump_stack+0x41/0x59 [ 5.301864] [<c404062b>] warn_slowpath_common+0x6b/0xa0 [ 5.306054] [<c403ca9c>] ? note_page+0x5ec/0x790 [ 5.310209] [<c4040686>] warn_slowpath_fmt+0x26/0x30 [ 5.314358] [<c403ca9c>] note_page+0x5ec/0x790 [ 5.318440] [<c403cd8f>] ptdump_walk_pgd_level_core+0x14f/0x230 [ 5.322578] [<c403ce91>] ptdump_walk_pgd_level_checkwx+0x11/0x20 [ 5.326632] [<c4034ead>] mark_rodata_ro+0xcd/0xf0 [ 5.330625] [<c4a4aab7>] kernel_init+0x17/0xc0 [ 5.334585] [<c4a511c9>] ret_from_kernel_thread+0x21/0x38 [ 5.338585] [<c4a4aaa0>] ? rest_init+0xa0/0xa0 [ 5.342583] ---[ end trace bc9ac0874ad9a058 ]--- [ 5.346630] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages found. ...I'm not quite sure why it does backtrace, or how to debug this one... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc0: 5 W+X pages found 2015-11-15 7:00 4.4-rc0: 5 W+X pages found Pavel Machek @ 2015-11-23 14:37 ` Mihai Donțu 2015-12-08 21:19 ` Kees Cook 2015-12-14 8:04 ` 4.4-rc5: ugly warn on: " Pavel Machek 1 sibling, 1 reply; 39+ messages in thread From: Mihai Donțu @ 2015-11-23 14:37 UTC (permalink / raw) To: Pavel Machek; +Cc: linux-kernel, Kees Cook, Stephen Smalley On Sun, 15 Nov 2015 08:00:22 +0100 Pavel Machek wrote: > Kernel complains: > > [ 5.256044] ------------[ cut here ]------------ > [ 5.259267] WARNING: CPU: 0 PID: 1 at > arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() > [ 5.262668] x86/mm: Found insecure W+X mapping at address > ffe69000/0xffe69000 > [ 5.267109] Modules linked in: > [ 5.271403] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #122 > [ 5.275679] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > (2.19 ) 03/31/2011 > [ 5.279957] 00000000 00000000 f5cffeac c42b9f18 f5cffed8 f5cffec8 > c404062b 000000e1 > [ 5.284387] c403ca9c f5cfff50 00000163 00000000 f5cffee0 c4040686 > 00000009 f5cffed8 > [ 5.288815] c4d268ac f5cffef4 f5cfff1c c403ca9c c4d1f494 000000e1 > c4d268ac ffe69000 > [ 5.293314] Call Trace: > [ 5.297602] [<c42b9f18>] dump_stack+0x41/0x59 > [ 5.301864] [<c404062b>] warn_slowpath_common+0x6b/0xa0 > [ 5.306054] [<c403ca9c>] ? note_page+0x5ec/0x790 > [ 5.310209] [<c4040686>] warn_slowpath_fmt+0x26/0x30 > [ 5.314358] [<c403ca9c>] note_page+0x5ec/0x790 > [ 5.318440] [<c403cd8f>] ptdump_walk_pgd_level_core+0x14f/0x230 > [ 5.322578] [<c403ce91>] ptdump_walk_pgd_level_checkwx+0x11/0x20 > [ 5.326632] [<c4034ead>] mark_rodata_ro+0xcd/0xf0 > [ 5.330625] [<c4a4aab7>] kernel_init+0x17/0xc0 > [ 5.334585] [<c4a511c9>] ret_from_kernel_thread+0x21/0x38 > [ 5.338585] [<c4a4aaa0>] ? rest_init+0xa0/0xa0 > [ 5.342583] ---[ end trace bc9ac0874ad9a058 ]--- > [ 5.346630] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages > found. > > ...I'm not quite sure why it does backtrace, or how to debug this > one... That is a modest number. [ 2.493559] ------------[ cut here ]------------ [ 2.493563] WARNING: CPU: 2 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5e1/0x780() [ 2.493565] x86/mm: Found insecure W+X mapping at address ffff88000009d000/0xffff88000009d000 [ 2.493565] Modules linked in: [ 2.493568] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc2 #2 [ 2.493569] Hardware name: Dell Inc. Latitude E7440/07F3F4, BIOS A15 05/19/2015 [ 2.493570] 0000000000000000 00000000c03551f4 ffff88040c7cbd48 ffffffffaa54851c [ 2.493572] ffff88040c7cbd90 ffff88040c7cbd80 ffffffffaa13a662 ffff88040c7cbe90 [ 2.493573] 8000000000000163 0000000000000004 0000000000000000 0000000000000000 [ 2.493575] Call Trace: [ 2.493579] [<ffffffffaa54851c>] dump_stack+0x4e/0x82 [ 2.493582] [<ffffffffaa13a662>] warn_slowpath_common+0x82/0xc0 [ 2.493583] [<ffffffffaa13a6fc>] warn_slowpath_fmt+0x5c/0x80 [ 2.493585] [<ffffffffaa0a3f61>] note_page+0x5e1/0x780 [ 2.493587] [<ffffffffaa0a43c4>] ptdump_walk_pgd_level_core+0x2c4/0x3f0 [ 2.493588] [<ffffffffaa0a4527>] ptdump_walk_pgd_level_checkwx+0x17/0x20 [ 2.493591] [<ffffffffaa09ad0f>] mark_rodata_ro+0xef/0x100 [ 2.493594] [<ffffffffaae75d00>] ? rest_init+0x90/0x90 [ 2.493595] [<ffffffffaae75d1d>] kernel_init+0x1d/0xe0 [ 2.493596] [<ffffffffaae7c52f>] ret_from_fork+0x3f/0x70 [ 2.493598] [<ffffffffaae75d00>] ? rest_init+0x90/0x90 [ 2.493599] ---[ end trace e2aec56d15b94609 ]--- [ 2.498994] x86/mm: Checked W+X mappings: FAILED, 104640 W+X pages found. All the while I have: $ zgrep NX /proc/config.gz CONFIG_DEBUG_SET_MODULE_RONX=y I added to CC the people involved in pushing this feature to mainline, maybe they can point me to a possible cause. -- Mihai Donțu ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc0: 5 W+X pages found 2015-11-23 14:37 ` Mihai Donțu @ 2015-12-08 21:19 ` Kees Cook 2015-12-09 0:10 ` Dave Jones 2015-12-09 19:33 ` Mihai Donțu 0 siblings, 2 replies; 39+ messages in thread From: Kees Cook @ 2015-12-08 21:19 UTC (permalink / raw) To: Mihai Donțu; +Cc: Pavel Machek, LKML, Stephen Smalley On Mon, Nov 23, 2015 at 6:37 AM, Mihai Donțu <mihai.dontu@gmail.com> wrote: > On Sun, 15 Nov 2015 08:00:22 +0100 Pavel Machek wrote: >> Kernel complains: >> >> [ 5.256044] ------------[ cut here ]------------ >> [ 5.259267] WARNING: CPU: 0 PID: 1 at >> arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() >> [ 5.262668] x86/mm: Found insecure W+X mapping at address >> ffe69000/0xffe69000 >> [ 5.267109] Modules linked in: >> [ 5.271403] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #122 >> [ 5.275679] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW >> (2.19 ) 03/31/2011 >> [ 5.279957] 00000000 00000000 f5cffeac c42b9f18 f5cffed8 f5cffec8 >> c404062b 000000e1 >> [ 5.284387] c403ca9c f5cfff50 00000163 00000000 f5cffee0 c4040686 >> 00000009 f5cffed8 >> [ 5.288815] c4d268ac f5cffef4 f5cfff1c c403ca9c c4d1f494 000000e1 >> c4d268ac ffe69000 >> [ 5.293314] Call Trace: >> [ 5.297602] [<c42b9f18>] dump_stack+0x41/0x59 >> [ 5.301864] [<c404062b>] warn_slowpath_common+0x6b/0xa0 >> [ 5.306054] [<c403ca9c>] ? note_page+0x5ec/0x790 >> [ 5.310209] [<c4040686>] warn_slowpath_fmt+0x26/0x30 >> [ 5.314358] [<c403ca9c>] note_page+0x5ec/0x790 >> [ 5.318440] [<c403cd8f>] ptdump_walk_pgd_level_core+0x14f/0x230 >> [ 5.322578] [<c403ce91>] ptdump_walk_pgd_level_checkwx+0x11/0x20 >> [ 5.326632] [<c4034ead>] mark_rodata_ro+0xcd/0xf0 >> [ 5.330625] [<c4a4aab7>] kernel_init+0x17/0xc0 >> [ 5.334585] [<c4a511c9>] ret_from_kernel_thread+0x21/0x38 >> [ 5.338585] [<c4a4aaa0>] ? rest_init+0xa0/0xa0 >> [ 5.342583] ---[ end trace bc9ac0874ad9a058 ]--- >> [ 5.346630] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages >> found. >> >> ...I'm not quite sure why it does backtrace, or how to debug this >> one... > > That is a modest number. > > [ 2.493559] ------------[ cut here ]------------ > [ 2.493563] WARNING: CPU: 2 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5e1/0x780() > [ 2.493565] x86/mm: Found insecure W+X mapping at address ffff88000009d000/0xffff88000009d000 > [ 2.493565] Modules linked in: > [ 2.493568] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc2 #2 > [ 2.493569] Hardware name: Dell Inc. Latitude E7440/07F3F4, BIOS A15 05/19/2015 > [ 2.493570] 0000000000000000 00000000c03551f4 ffff88040c7cbd48 ffffffffaa54851c > [ 2.493572] ffff88040c7cbd90 ffff88040c7cbd80 ffffffffaa13a662 ffff88040c7cbe90 > [ 2.493573] 8000000000000163 0000000000000004 0000000000000000 0000000000000000 > [ 2.493575] Call Trace: > [ 2.493579] [<ffffffffaa54851c>] dump_stack+0x4e/0x82 > [ 2.493582] [<ffffffffaa13a662>] warn_slowpath_common+0x82/0xc0 > [ 2.493583] [<ffffffffaa13a6fc>] warn_slowpath_fmt+0x5c/0x80 > [ 2.493585] [<ffffffffaa0a3f61>] note_page+0x5e1/0x780 > [ 2.493587] [<ffffffffaa0a43c4>] ptdump_walk_pgd_level_core+0x2c4/0x3f0 > [ 2.493588] [<ffffffffaa0a4527>] ptdump_walk_pgd_level_checkwx+0x17/0x20 > [ 2.493591] [<ffffffffaa09ad0f>] mark_rodata_ro+0xef/0x100 > [ 2.493594] [<ffffffffaae75d00>] ? rest_init+0x90/0x90 > [ 2.493595] [<ffffffffaae75d1d>] kernel_init+0x1d/0xe0 > [ 2.493596] [<ffffffffaae7c52f>] ret_from_fork+0x3f/0x70 > [ 2.493598] [<ffffffffaae75d00>] ? rest_init+0x90/0x90 > [ 2.493599] ---[ end trace e2aec56d15b94609 ]--- > [ 2.498994] x86/mm: Checked W+X mappings: FAILED, 104640 W+X pages found. > > All the while I have: > > $ zgrep NX /proc/config.gz > CONFIG_DEBUG_SET_MODULE_RONX=y > > I added to CC the people involved in pushing this feature to mainline, > maybe they can point me to a possible cause. If you enable CONFIG_X86_PTDUMP, see if you can find out what exists in /sys/kernel/debug/kernel_page_tables at ffff88000009d000 ? -Kees -- Kees Cook Chrome OS & Brillo Security ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc0: 5 W+X pages found 2015-12-08 21:19 ` Kees Cook @ 2015-12-09 0:10 ` Dave Jones 2015-12-09 19:33 ` Mihai Donțu 1 sibling, 0 replies; 39+ messages in thread From: Dave Jones @ 2015-12-09 0:10 UTC (permalink / raw) To: Kees Cook; +Cc: Mihai Donțu, Pavel Machek, LKML, Stephen Smalley On Tue, Dec 08, 2015 at 01:19:32PM -0800, Kees Cook wrote: > On Mon, Nov 23, 2015 at 6:37 AM, Mihai Donțu <mihai.dontu@gmail.com> wrote: > > On Sun, 15 Nov 2015 08:00:22 +0100 Pavel Machek wrote: > >> Kernel complains: > >> > >> [ 5.256044] ------------[ cut here ]------------ > >> [ 5.259267] WARNING: CPU: 0 PID: 1 at > >> arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() > >> [ 5.262668] x86/mm: Found insecure W+X mapping at address > >> ffe69000/0xffe69000 > >> [ 5.267109] Modules linked in: > >> [ 5.271403] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #122 > >> [ 5.275679] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > >> (2.19 ) 03/31/2011 > >> [ 5.279957] 00000000 00000000 f5cffeac c42b9f18 f5cffed8 f5cffec8 > >> c404062b 000000e1 > >> [ 5.284387] c403ca9c f5cfff50 00000163 00000000 f5cffee0 c4040686 > >> 00000009 f5cffed8 > >> [ 5.288815] c4d268ac f5cffef4 f5cfff1c c403ca9c c4d1f494 000000e1 > >> c4d268ac ffe69000 > >> [ 5.293314] Call Trace: > >> [ 5.297602] [<c42b9f18>] dump_stack+0x41/0x59 > >> [ 5.301864] [<c404062b>] warn_slowpath_common+0x6b/0xa0 > >> [ 5.306054] [<c403ca9c>] ? note_page+0x5ec/0x790 > >> [ 5.310209] [<c4040686>] warn_slowpath_fmt+0x26/0x30 > >> [ 5.314358] [<c403ca9c>] note_page+0x5ec/0x790 > >> [ 5.318440] [<c403cd8f>] ptdump_walk_pgd_level_core+0x14f/0x230 > >> [ 5.322578] [<c403ce91>] ptdump_walk_pgd_level_checkwx+0x11/0x20 > >> [ 5.326632] [<c4034ead>] mark_rodata_ro+0xcd/0xf0 > >> [ 5.330625] [<c4a4aab7>] kernel_init+0x17/0xc0 > >> [ 5.334585] [<c4a511c9>] ret_from_kernel_thread+0x21/0x38 > >> [ 5.338585] [<c4a4aaa0>] ? rest_init+0xa0/0xa0 > >> [ 5.342583] ---[ end trace bc9ac0874ad9a058 ]--- > >> [ 5.346630] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages > >> found. > >> > >> ...I'm not quite sure why it does backtrace, or how to debug this > >> one... > > > > That is a modest number. > > > > [ 2.493559] ------------[ cut here ]------------ > > [ 2.493563] WARNING: CPU: 2 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5e1/0x780() > > [ 2.493565] x86/mm: Found insecure W+X mapping at address ffff88000009d000/0xffff88000009d000 > > [ 2.493565] Modules linked in: > > [ 2.493568] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc2 #2 > > [ 2.493569] Hardware name: Dell Inc. Latitude E7440/07F3F4, BIOS A15 05/19/2015 > > [ 2.493570] 0000000000000000 00000000c03551f4 ffff88040c7cbd48 ffffffffaa54851c > > [ 2.493572] ffff88040c7cbd90 ffff88040c7cbd80 ffffffffaa13a662 ffff88040c7cbe90 > > [ 2.493573] 8000000000000163 0000000000000004 0000000000000000 0000000000000000 > > [ 2.493575] Call Trace: > > [ 2.493579] [<ffffffffaa54851c>] dump_stack+0x4e/0x82 > > [ 2.493582] [<ffffffffaa13a662>] warn_slowpath_common+0x82/0xc0 > > [ 2.493583] [<ffffffffaa13a6fc>] warn_slowpath_fmt+0x5c/0x80 > > [ 2.493585] [<ffffffffaa0a3f61>] note_page+0x5e1/0x780 > > [ 2.493587] [<ffffffffaa0a43c4>] ptdump_walk_pgd_level_core+0x2c4/0x3f0 > > [ 2.493588] [<ffffffffaa0a4527>] ptdump_walk_pgd_level_checkwx+0x17/0x20 > > [ 2.493591] [<ffffffffaa09ad0f>] mark_rodata_ro+0xef/0x100 > > [ 2.493594] [<ffffffffaae75d00>] ? rest_init+0x90/0x90 > > [ 2.493595] [<ffffffffaae75d1d>] kernel_init+0x1d/0xe0 > > [ 2.493596] [<ffffffffaae7c52f>] ret_from_fork+0x3f/0x70 > > [ 2.493598] [<ffffffffaae75d00>] ? rest_init+0x90/0x90 > > [ 2.493599] ---[ end trace e2aec56d15b94609 ]--- > > [ 2.498994] x86/mm: Checked W+X mappings: FAILED, 104640 W+X pages found. > > > > All the while I have: > > > > $ zgrep NX /proc/config.gz > > CONFIG_DEBUG_SET_MODULE_RONX=y > > > > I added to CC the people involved in pushing this feature to mainline, > > maybe they can point me to a possible cause. > > If you enable CONFIG_X86_PTDUMP, see if you can find out what exists > in /sys/kernel/debug/kernel_page_tables at ffff88000009d000 ? Is this not likely the EFI stuff mentioned in commit 54727e6e950aacd14ec9cd4260e9fe498322828c ? I saw some patches that reorg'd a lot of the EFI memory code, but afaik they didn't get merged yet. sidenote: # cat /sys/kernel/debug/kernel_page_tables cat: /sys/kernel/debug/kernel_page_tables: Cannot allocate memory <sad trombone> Dave ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc0: 5 W+X pages found 2015-12-08 21:19 ` Kees Cook 2015-12-09 0:10 ` Dave Jones @ 2015-12-09 19:33 ` Mihai Donțu 1 sibling, 0 replies; 39+ messages in thread From: Mihai Donțu @ 2015-12-09 19:33 UTC (permalink / raw) To: Kees Cook; +Cc: Pavel Machek, LKML, Stephen Smalley On Tue, 8 Dec 2015 13:19:32 -0800 Kees Cook wrote: > On Mon, Nov 23, 2015 at 6:37 AM, Mihai Donțu wrote: > > On Sun, 15 Nov 2015 08:00:22 +0100 Pavel Machek wrote: > >> Kernel complains: > >> > >> [ 5.256044] ------------[ cut here ]------------ > >> [ 5.259267] WARNING: CPU: 0 PID: 1 at > >> arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() > >> [ 5.262668] x86/mm: Found insecure W+X mapping at address > >> ffe69000/0xffe69000 > >> [ 5.267109] Modules linked in: > >> [ 5.271403] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #122 > >> [ 5.275679] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > >> (2.19 ) 03/31/2011 > >> [ 5.279957] 00000000 00000000 f5cffeac c42b9f18 f5cffed8 f5cffec8 > >> c404062b 000000e1 > >> [ 5.284387] c403ca9c f5cfff50 00000163 00000000 f5cffee0 c4040686 > >> 00000009 f5cffed8 > >> [ 5.288815] c4d268ac f5cffef4 f5cfff1c c403ca9c c4d1f494 000000e1 > >> c4d268ac ffe69000 > >> [ 5.293314] Call Trace: > >> [ 5.297602] [<c42b9f18>] dump_stack+0x41/0x59 > >> [ 5.301864] [<c404062b>] warn_slowpath_common+0x6b/0xa0 > >> [ 5.306054] [<c403ca9c>] ? note_page+0x5ec/0x790 > >> [ 5.310209] [<c4040686>] warn_slowpath_fmt+0x26/0x30 > >> [ 5.314358] [<c403ca9c>] note_page+0x5ec/0x790 > >> [ 5.318440] [<c403cd8f>] ptdump_walk_pgd_level_core+0x14f/0x230 > >> [ 5.322578] [<c403ce91>] ptdump_walk_pgd_level_checkwx+0x11/0x20 > >> [ 5.326632] [<c4034ead>] mark_rodata_ro+0xcd/0xf0 > >> [ 5.330625] [<c4a4aab7>] kernel_init+0x17/0xc0 > >> [ 5.334585] [<c4a511c9>] ret_from_kernel_thread+0x21/0x38 > >> [ 5.338585] [<c4a4aaa0>] ? rest_init+0xa0/0xa0 > >> [ 5.342583] ---[ end trace bc9ac0874ad9a058 ]--- > >> [ 5.346630] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages > >> found. > >> > >> ...I'm not quite sure why it does backtrace, or how to debug this > >> one... > > > > That is a modest number. > > > > [ 2.493559] ------------[ cut here ]------------ > > [ 2.493563] WARNING: CPU: 2 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5e1/0x780() > > [ 2.493565] x86/mm: Found insecure W+X mapping at address ffff88000009d000/0xffff88000009d000 > > [ 2.493565] Modules linked in: > > [ 2.493568] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc2 #2 > > [ 2.493569] Hardware name: Dell Inc. Latitude E7440/07F3F4, BIOS A15 05/19/2015 > > [ 2.493570] 0000000000000000 00000000c03551f4 ffff88040c7cbd48 ffffffffaa54851c > > [ 2.493572] ffff88040c7cbd90 ffff88040c7cbd80 ffffffffaa13a662 ffff88040c7cbe90 > > [ 2.493573] 8000000000000163 0000000000000004 0000000000000000 0000000000000000 > > [ 2.493575] Call Trace: > > [ 2.493579] [<ffffffffaa54851c>] dump_stack+0x4e/0x82 > > [ 2.493582] [<ffffffffaa13a662>] warn_slowpath_common+0x82/0xc0 > > [ 2.493583] [<ffffffffaa13a6fc>] warn_slowpath_fmt+0x5c/0x80 > > [ 2.493585] [<ffffffffaa0a3f61>] note_page+0x5e1/0x780 > > [ 2.493587] [<ffffffffaa0a43c4>] ptdump_walk_pgd_level_core+0x2c4/0x3f0 > > [ 2.493588] [<ffffffffaa0a4527>] ptdump_walk_pgd_level_checkwx+0x17/0x20 > > [ 2.493591] [<ffffffffaa09ad0f>] mark_rodata_ro+0xef/0x100 > > [ 2.493594] [<ffffffffaae75d00>] ? rest_init+0x90/0x90 > > [ 2.493595] [<ffffffffaae75d1d>] kernel_init+0x1d/0xe0 > > [ 2.493596] [<ffffffffaae7c52f>] ret_from_fork+0x3f/0x70 > > [ 2.493598] [<ffffffffaae75d00>] ? rest_init+0x90/0x90 > > [ 2.493599] ---[ end trace e2aec56d15b94609 ]--- > > [ 2.498994] x86/mm: Checked W+X mappings: FAILED, 104640 W+X pages found. > > > > All the while I have: > > > > $ zgrep NX /proc/config.gz > > CONFIG_DEBUG_SET_MODULE_RONX=y > > > > I added to CC the people involved in pushing this feature to mainline, > > maybe they can point me to a possible cause. > > If you enable CONFIG_X86_PTDUMP, see if you can find out what exists > in /sys/kernel/debug/kernel_page_tables at ffff88000009d000 ? ---[ Low Kernel Mapping ]--- 0xffff880000000000-0xffff880000097000 604K RW GLB NX pte 0xffff880000097000-0xffff880000098000 4K ro GLB NX pte 0xffff880000098000-0xffff880000099000 4K ro GLB x pte 0xffff880000099000-0xffff88000009d000 16K RW GLB NX pte *0xffff88000009d000-0xffff88000009e000* 4K RW GLB x pte 0xffff88000009e000-0xffff880000200000 1416K RW GLB NX pte 0xffff880000200000-0xffff880029000000 654M RW PSE GLB NX pmd 0xffff880029000000-0xffff880029e00000 14M ro PSE GLB x pmd 0xffff880029e00000-0xffff880029e89000 548K ro GLB x pte 0xffff880029e89000-0xffff88002a000000 1500K RW GLB NX pte 0xffff88002a000000-0xffff88002a800000 8M ro PSE GLB x pmd 0xffff88002a800000-0xffff88002a8d0000 832K ro GLB x pte 0xffff88002a8d0000-0xffff88002aa00000 1216K RW GLB NX pte 0xffff88002aa00000-0xffff88002ae00000 4M RW PSE GLB x pmd 0xffff88002ae00000-0xffff88002ae9a000 616K RW GLB x pte 0xffff88002ae9a000-0xffff88002b000000 1432K RW GLB NX pte 0xffff88002b000000-0xffff880040000000 336M RW PSE GLB NX pmd 0xffff880040000000-0xffff8800c0000000 2G RW PSE GLB NX pud 0xffff8800c0000000-0xffff8800cc400000 196M RW PSE GLB NX pmd 0xffff8800cc400000-0xffff8800cc415000 84K RW GLB NX pte 0xffff8800cc415000-0xffff8800cc515000 1M RW GLB x pte 0xffff8800cc515000-0xffff8800cc600000 940K RW GLB NX pte 0xffff8800cc600000-0xffff8800cf200000 44M RW PSE GLB NX pmd 0xffff8800cf200000-0xffff8800cf2c9000 804K RW GLB NX pte 0xffff8800cf2c9000-0xffff8800cf2d0000 28K pte 0xffff8800cf2d0000-0xffff8800cf400000 1216K RW GLB x pte 0xffff8800cf400000-0xffff8800cf600000 2M RW PSE GLB x pmd 0xffff8800cf600000-0xffff8800cf800000 2M RW GLB x pte 0xffff8800cf800000-0xffff8800cfe00000 6M RW PSE GLB x pmd 0xffff8800cfe00000-0xffff8800cff0f000 1084K RW GLB x pte 0xffff8800cff0f000-0xffff8800d0000000 964K RW x pte 0xffff8800d0000000-0xffff8800d0200000 2M RW PSE x pmd 0xffff8800d0200000-0xffff8800d03f3000 1996K RW x pte 0xffff8800d03f3000-0xffff8800d0405000 72K RW GLB x pte 0xffff8800d0405000-0xffff8800d0600000 2028K RW GLB NX pte 0xffff8800d0600000-0xffff8800d1000000 10M RW PSE GLB NX pmd 0xffff8800d1000000-0xffff8800d1093000 588K RW GLB NX pte 0xffff8800d1093000-0xffff8800d1200000 1460K RW GLB x pte 0xffff8800d1200000-0xffff8800d1a00000 8M RW PSE GLB x pmd 0xffff8800d1a00000-0xffff8800d1bf1000 1988K RW GLB x pte 0xffff8800d1bf1000-0xffff8800d1c2b000 232K RW GLB NX pte 0xffff8800d1c2b000-0xffff8800d1c2c000 4K ro GLB NX pte 0xffff8800d1c2c000-0xffff8800d1c31000 20K RW GLB NX pte 0xffff8800d1c31000-0xffff8800d1c32000 4K ro GLB NX pte 0xffff8800d1c32000-0xffff8800d1d38000 1048K RW GLB NX pte 0xffff8800d1d38000-0xffff8800d1d39000 4K ro GLB NX pte 0xffff8800d1d39000-0xffff8800d1e5a000 1156K RW GLB NX pte 0xffff8800d1e5a000-0xffff8800d1f7d000 1164K RW GLB x pte 0xffff8800d1f7d000-0xffff8800d2028000 684K RW GLB NX pte 0xffff8800d2028000-0xffff8800d2184000 1392K RW GLB x pte 0xffff8800d2184000-0xffff8800d218f000 44K RW GLB NX pte 0xffff8800d218f000-0xffff8800d224c000 756K RW GLB x pte 0xffff8800d224c000-0xffff8800d2251000 20K RW GLB NX pte 0xffff8800d2251000-0xffff8800d2400000 1724K RW GLB x pte 0xffff8800d2400000-0xffff8800d2a00000 6M RW PSE GLB x pmd 0xffff8800d2a00000-0xffff8800d2a1c000 112K RW GLB x pte 0xffff8800d2a1c000-0xffff8800d2a22000 24K RW GLB NX pte 0xffff8800d2a22000-0xffff8800d2a37000 84K RW GLB x pte 0xffff8800d2a37000-0xffff8800d2a38000 4K RW GLB NX pte 0xffff8800d2a38000-0xffff8800d2a3d000 20K RW GLB x pte 0xffff8800d2a3d000-0xffff8800d2a4c000 60K RW GLB NX pte 0xffff8800d2a4c000-0xffff8800d2a4d000 4K RW GLB x pte 0xffff8800d2a4d000-0xffff8800d2a57000 40K RW GLB NX pte 0xffff8800d2a57000-0xffff8800d2a62000 44K RW GLB x pte 0xffff8800d2a62000-0xffff8800d2a6a000 32K RW GLB NX pte 0xffff8800d2a6a000-0xffff8800d2a73000 36K RW GLB x pte 0xffff8800d2a73000-0xffff8800d2a78000 20K RW GLB NX pte 0xffff8800d2a78000-0xffff8800d2c00000 1568K RW GLB x pte 0xffff8800d2c00000-0xffff8800d4000000 20M RW PSE GLB x pmd 0xffff8800d4000000-0xffff8800d4095000 596K RW GLB x pte 0xffff8800d4095000-0xffff8800d4096000 4K ro GLB x pte 0xffff8800d4096000-0xffff8800d4177000 900K RW GLB x pte 0xffff8800d4177000-0xffff8800d4178000 4K RW PCD GLB x pte 0xffff8800d4178000-0xffff8800d418c000 80K RW GLB x pte 0xffff8800d418c000-0xffff8800d418d000 4K RW PCD GLB x pte 0xffff8800d418d000-0xffff8800d42ac000 1148K RW GLB x pte 0xffff8800d42ac000-0xffff8800d42ad000 4K ro GLB x pte 0xffff8800d42ad000-0xffff8800d43ae000 1028K RW GLB x pte 0xffff8800d43ae000-0xffff8800d43af000 4K ro GLB x pte 0xffff8800d43af000-0xffff8800d45a3000 2000K RW GLB x pte 0xffff8800d45a3000-0xffff8800d45a4000 4K ro GLB x pte 0xffff8800d45a4000-0xffff8800d488d000 2980K RW GLB x pte 0xffff8800d488d000-0xffff8800d488e000 4K ro GLB x pte 0xffff8800d488e000-0xffff8800d4996000 1056K RW GLB x pte 0xffff8800d4996000-0xffff8800d4997000 4K ro GLB x pte 0xffff8800d4997000-0xffff8800d4a00000 420K RW GLB x pte 0xffff8800d4a00000-0xffff8800d5000000 6M RW PSE GLB x pmd 0xffff8800d5000000-0xffff8800d5800000 8M RW PSE GLB NX pmd 0xffff8800d5800000-0xffff8800d593b000 1260K RW GLB NX pte 0xffff8800d593b000-0xffff8800d5a00000 788K RW GLB x pte 0xffff8800d5a00000-0xffff8800d6000000 6M RW PSE GLB x pmd 0xffff8800d6000000-0xffff8800d7c00000 28M RW PSE GLB NX pmd 0xffff8800d7c00000-0xffff8800d7db4000 1744K RW GLB NX pte 0xffff8800d7db4000-0xffff8800d7e00000 304K RW x pte 0xffff8800d7e00000-0xffff8800d8000000 2M RW PSE x pmd 0xffff8800d8000000-0xffff8800d8600000 6M RW PSE GLB NX pmd 0xffff8800d8600000-0xffff8800d8759000 1380K RW GLB NX pte 0xffff8800d8759000-0xffff8800d8800000 668K RW x pte 0xffff8800d8800000-0xffff8800d8e00000 6M RW PSE GLB NX pmd 0xffff8800d8e00000-0xffff8800d8faa000 1704K RW GLB NX pte 0xffff8800d8faa000-0xffff8800d9000000 344K pte 0xffff8800d9000000-0xffff8800da600000 22M RW PSE GLB NX pmd 0xffff8800da600000-0xffff8800da71c000 1136K RW GLB NX pte 0xffff8800da71c000-0xffff8800da800000 912K pte 0xffff8800da800000-0xffff8800db800000 16M RW PSE GLB NX pmd 0xffff8800db800000-0xffff8800db847000 284K RW GLB NX pte 0xffff8800db847000-0xffff8800db848000 4K ro GLB NX pte 0xffff8800db848000-0xffff8800db88c000 272K RW GLB NX pte 0xffff8800db88c000-0xffff8800db88d000 4K ro GLB NX pte 0xffff8800db88d000-0xffff8800dba00000 1484K RW GLB NX pte 0xffff8800dba00000-0xffff8800dbc00000 2M RW PSE GLB NX pmd 0xffff8800dbc00000-0xffff8800dbcfc000 1008K RW GLB NX pte 0xffff8800dbcfc000-0xffff8800dbe00000 1040K pte 0xffff8800dbe00000-0xffff8800dd000000 18M pmd 0xffff8800dd000000-0xffff8800df200000 34M RW PCD PSE x pmd 0xffff8800df200000-0xffff8800f8000000 398M pmd 0xffff8800f8000000-0xffff8800fc000000 64M RW PCD PSE x pmd 0xffff8800fc000000-0xffff8800fec00000 44M pmd 0xffff8800fec00000-0xffff8800fec01000 4K RW PCD x pte 0xffff8800fec01000-0xffff8800fed00000 1020K pte 0xffff8800fed00000-0xffff8800fed04000 16K RW PCD x pte 0xffff8800fed04000-0xffff8800fed1c000 96K pte 0xffff8800fed1c000-0xffff8800fed20000 16K RW PCD x pte 0xffff8800fed20000-0xffff8800fee00000 896K pte 0xffff8800fee00000-0xffff8800fee01000 4K RW PCD x pte 0xffff8800fee01000-0xffff8800ff000000 2044K pte 0xffff8800ff000000-0xffff880100000000 16M RW PCD PSE x pmd 0xffff880100000000-0xffff8803c0000000 11G RW PSE GLB NX pud 0xffff8803c0000000-0xffff8803e6c00000 620M RW PSE GLB NX pmd 0xffff8803e6c00000-0xffff8803e6c5a000 360K RW GLB NX pte 0xffff8803e6c5a000-0xffff8803e6c5b000 4K ro GLB NX pte 0xffff8803e6c5b000-0xffff8803e6e00000 1684K RW GLB NX pte 0xffff8803e6e00000-0xffff8803eb400000 70M RW PSE GLB NX pmd 0xffff8803eb400000-0xffff8803eb600000 2M RW GLB NX pte 0xffff8803eb600000-0xffff8803ed800000 34M RW PSE GLB NX pmd 0xffff8803ed800000-0xffff8803ed8dd000 884K RW GLB NX pte 0xffff8803ed8dd000-0xffff8803ed8de000 4K ro GLB NX pte 0xffff8803ed8de000-0xffff8803eda00000 1160K RW GLB NX pte 0xffff8803eda00000-0xffff8803ffc00000 290M RW PSE GLB NX pmd 0xffff8803ffc00000-0xffff8803ffcf7000 988K RW GLB NX pte 0xffff8803ffcf7000-0xffff8803ffcf8000 4K ro GLB NX pte 0xffff8803ffcf8000-0xffff8803ffe01000 1060K RW GLB NX pte 0xffff8803ffe01000-0xffff8803ffe02000 4K ro GLB NX pte 0xffff8803ffe02000-0xffff8803ffe14000 72K RW GLB NX pte 0xffff8803ffe14000-0xffff8803ffe15000 4K ro GLB NX pte 0xffff8803ffe15000-0xffff880400000000 1964K RW GLB NX pte 0xffff880400000000-0xffff880401000000 16M RW PSE GLB NX pmd 0xffff880401000000-0xffff880401306000 3096K RW GLB NX pte 0xffff880401306000-0xffff880401307000 4K ro GLB NX pte 0xffff880401307000-0xffff880401400000 996K RW GLB NX pte 0xffff880401400000-0xffff880407c00000 104M RW PSE GLB NX pmd 0xffff880407c00000-0xffff880407c62000 392K RW GLB NX pte 0xffff880407c62000-0xffff880407c64000 8K ro GLB NX pte 0xffff880407c64000-0xffff880407c79000 84K RW GLB NX pte 0xffff880407c79000-0xffff880407c7a000 4K ro GLB NX pte 0xffff880407c7a000-0xffff880407c9e000 144K RW GLB NX pte 0xffff880407c9e000-0xffff880407ca0000 8K ro GLB NX pte 0xffff880407ca0000-0xffff880407cd8000 224K RW GLB NX pte 0xffff880407cd8000-0xffff880407cda000 8K ro GLB NX pte 0xffff880407cda000-0xffff880407d2e000 336K RW GLB NX pte 0xffff880407d2e000-0xffff880407d30000 8K ro GLB NX pte 0xffff880407d30000-0xffff880407dd7000 668K RW GLB NX pte 0xffff880407dd7000-0xffff880407dd8000 4K ro GLB NX pte 0xffff880407dd8000-0xffff880407e3e000 408K RW GLB NX pte 0xffff880407e3e000-0xffff880407e3f000 4K ro GLB NX pte 0xffff880407e3f000-0xffff880407e40000 4K RW GLB NX pte 0xffff880407e40000-0xffff880407e42000 8K ro GLB NX pte 0xffff880407e42000-0xffff880407e5e000 112K RW GLB NX pte 0xffff880407e5e000-0xffff880407e60000 8K ro GLB NX pte 0xffff880407e60000-0xffff880407e7a000 104K RW GLB NX pte 0xffff880407e7a000-0xffff880407e7c000 8K ro GLB NX pte 0xffff880407e7c000-0xffff880407eed000 452K RW GLB NX pte 0xffff880407eed000-0xffff880407eee000 4K ro GLB NX pte 0xffff880407eee000-0xffff880407eef000 4K RW GLB NX pte 0xffff880407eef000-0xffff880407ef0000 4K ro GLB NX pte 0xffff880407ef0000-0xffff880407f18000 160K RW GLB NX pte 0xffff880407f18000-0xffff880407f1a000 8K ro GLB NX pte 0xffff880407f1a000-0xffff8804081d7000 2804K RW GLB NX pte 0xffff8804081d7000-0xffff8804081d8000 4K ro GLB NX pte 0xffff8804081d8000-0xffff8804081ff000 156K RW GLB NX pte 0xffff8804081ff000-0xffff880408202000 12K ro GLB NX pte 0xffff880408202000-0xffff880408268000 408K RW GLB NX pte 0xffff880408268000-0xffff88040826a000 8K ro GLB NX pte 0xffff88040826a000-0xffff8804082e3000 484K RW GLB NX pte 0xffff8804082e3000-0xffff8804082e4000 4K ro GLB NX pte 0xffff8804082e4000-0xffff8804082e9000 20K RW GLB NX pte 0xffff8804082e9000-0xffff8804082eb000 8K ro GLB NX pte 0xffff8804082eb000-0xffff880408310000 148K RW GLB NX pte 0xffff880408310000-0xffff880408312000 8K ro GLB NX pte 0xffff880408312000-0xffff880408338000 152K RW GLB NX pte 0xffff880408338000-0xffff88040833a000 8K ro GLB NX pte 0xffff88040833a000-0xffff880408351000 92K RW GLB NX pte 0xffff880408351000-0xffff880408352000 4K ro GLB NX pte 0xffff880408352000-0xffff88040835e000 48K RW GLB NX pte 0xffff88040835e000-0xffff88040835f000 4K ro GLB NX pte 0xffff88040835f000-0xffff88040837e000 124K RW GLB NX pte 0xffff88040837e000-0xffff880408380000 8K ro GLB NX pte 0xffff880408380000-0xffff8804083f2000 456K RW GLB NX pte 0xffff8804083f2000-0xffff8804083f4000 8K ro GLB NX pte 0xffff8804083f4000-0xffff880408400000 48K RW GLB NX pte 0xffff880408400000-0xffff880408e00000 10M RW PSE GLB NX pmd 0xffff880408e00000-0xffff880408e78000 480K RW GLB NX pte 0xffff880408e78000-0xffff880408e79000 4K ro GLB NX pte 0xffff880408e79000-0xffff880409000000 1564K RW GLB NX pte 0xffff880409000000-0xffff88040a200000 18M RW PSE GLB NX pmd 0xffff88040a200000-0xffff88040a3a4000 1680K RW GLB NX pte 0xffff88040a3a4000-0xffff88040a3a5000 4K ro GLB NX pte 0xffff88040a3a5000-0xffff88040a3d2000 180K RW GLB NX pte 0xffff88040a3d2000-0xffff88040a3d3000 4K ro GLB NX pte 0xffff88040a3d3000-0xffff88040a429000 344K RW GLB NX pte 0xffff88040a429000-0xffff88040a42a000 4K ro GLB NX pte 0xffff88040a42a000-0xffff88040a42d000 12K RW GLB NX pte 0xffff88040a42d000-0xffff88040a42e000 4K ro GLB NX pte 0xffff88040a42e000-0xffff88040a43a000 48K RW GLB NX pte 0xffff88040a43a000-0xffff88040a43c000 8K ro GLB NX pte 0xffff88040a43c000-0xffff88040a444000 32K RW GLB NX pte 0xffff88040a444000-0xffff88040a446000 8K ro GLB NX pte 0xffff88040a446000-0xffff88040a4b0000 424K RW GLB NX pte 0xffff88040a4b0000-0xffff88040a4b1000 4K ro GLB NX pte 0xffff88040a4b1000-0xffff88040a4c3000 72K RW GLB NX pte 0xffff88040a4c3000-0xffff88040a4c4000 4K ro GLB NX pte 0xffff88040a4c4000-0xffff88040a528000 400K RW GLB NX pte 0xffff88040a528000-0xffff88040a529000 4K ro GLB NX pte 0xffff88040a529000-0xffff88040a598000 444K RW GLB NX pte 0xffff88040a598000-0xffff88040a599000 4K ro GLB NX pte 0xffff88040a599000-0xffff88040a59e000 20K RW GLB NX pte 0xffff88040a59e000-0xffff88040a5a0000 8K ro GLB NX pte 0xffff88040a5a0000-0xffff88040a5c0000 128K RW GLB NX pte 0xffff88040a5c0000-0xffff88040a5c1000 4K ro GLB NX pte 0xffff88040a5c1000-0xffff88040a5d4000 76K RW GLB NX pte 0xffff88040a5d4000-0xffff88040a5d5000 4K ro GLB NX pte 0xffff88040a5d5000-0xffff88040a715000 1280K RW GLB NX pte 0xffff88040a715000-0xffff88040a716000 4K ro GLB NX pte 0xffff88040a716000-0xffff88040a800000 936K RW GLB NX pte 0xffff88040a800000-0xffff88040ac00000 4M RW PSE GLB NX pmd 0xffff88040ac00000-0xffff88040ac77000 476K RW GLB NX pte 0xffff88040ac77000-0xffff88040ac78000 4K ro GLB NX pte 0xffff88040ac78000-0xffff88040acae000 216K RW GLB NX pte 0xffff88040acae000-0xffff88040acb0000 8K ro GLB NX pte 0xffff88040acb0000-0xffff88040acb2000 8K RW GLB NX pte 0xffff88040acb2000-0xffff88040acb4000 8K ro GLB NX pte 0xffff88040acb4000-0xffff88040accc000 96K RW GLB NX pte 0xffff88040accc000-0xffff88040acce000 8K ro GLB NX pte 0xffff88040acce000-0xffff88040ace0000 72K RW GLB NX pte 0xffff88040ace0000-0xffff88040ace2000 8K ro GLB NX pte 0xffff88040ace2000-0xffff88040ad65000 524K RW GLB NX pte 0xffff88040ad65000-0xffff88040ad66000 4K ro GLB NX pte 0xffff88040ad66000-0xffff88040adbe000 352K RW GLB NX pte 0xffff88040adbe000-0xffff88040adc0000 8K ro GLB NX pte 0xffff88040adc0000-0xffff88040addd000 116K RW GLB NX pte 0xffff88040addd000-0xffff88040adde000 4K ro GLB NX pte 0xffff88040adde000-0xffff88040b000000 2184K RW GLB NX pte 0xffff88040b000000-0xffff88040c200000 18M RW PSE GLB NX pmd 0xffff88040c200000-0xffff88040c3ae000 1720K RW GLB NX pte 0xffff88040c3ae000-0xffff88040c3af000 4K ro GLB NX pte 0xffff88040c3af000-0xffff88040c400000 324K RW GLB NX pte 0xffff88040c400000-0xffff88041ee00000 298M RW PSE GLB NX pmd 0xffff88041ee00000-0xffff880440000000 530M pmd 0xffff880440000000-0xffff888000000000 495G pud 0xffff888000000000-0xffffc90000000000 66048G pgd -- Mihai Donțu ^ permalink raw reply [flat|nested] 39+ messages in thread
* 4.4-rc5: ugly warn on: 5 W+X pages found 2015-11-15 7:00 4.4-rc0: 5 W+X pages found Pavel Machek 2015-11-23 14:37 ` Mihai Donțu @ 2015-12-14 8:04 ` Pavel Machek 2015-12-14 8:58 ` Borislav Petkov 2015-12-14 12:29 ` Pavel Machek 1 sibling, 2 replies; 39+ messages in thread From: Pavel Machek @ 2015-12-14 8:04 UTC (permalink / raw) To: kernel list, sds, luto, arjan, bp, brgerst, dvlasenk, hpa, torvalds, efault, peterz, tglx Hi! > Kernel complains: And now, we are at -rc5, and kernel still complains... ...with a back trace, which is clearly completely useless, and just there to make it scary and make people report. Problem is... noone cares for the reports. (-rc0 version below). Can we get rid of that WARN_ON? If you do care about reports, please add email address those can be reported to. If you don't... just drop it. Hardware is thinkpad x60. Pavel [ 3.267542] NX-protecting the kernel data: 5764k [ 3.278325] ------------[ cut here ]------------ [ 3.282060] WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() [ 3.285993] x86/mm: Found insecure W+X mapping at address ffe69000/0xffe69000 [ 3.289991] Modules linked in: [ 3.293995] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc5+ #132 [ 3.298178] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011 [ 3.304343] 00000001 00000000 f5cffeac c42ba698 f5cffed8 f5cffec8 c404059b 000000e1 [ 3.308840] c403cb9c f5cfff50 00000163 00000000 f5cffee0 c40405f6 00000009 f5cffed8 [ 3.313419] c4d3347c f5cffef4 f5cfff1c c403cb9c c4d2c08c 000000e1 c4d3347c ffe69000 [ 3.317935] Call Trace: [ 3.322395] [<c42ba698>] dump_stack+0x41/0x59 [ 3.326787] [<c404059b>] warn_slowpath_common+0x6b/0xa0 [ 3.331171] [<c403cb9c>] ? note_page+0x5ec/0x790 [ 3.335522] [<c40405f6>] warn_slowpath_fmt+0x26/0x30 [ 3.339839] [<c403cb9c>] note_page+0x5ec/0x790 [ 3.344154] [<c403ce9f>] ptdump_walk_pgd_level_core+0x15f/0x240 [ 3.348440] [<c403cfa1>] ptdump_walk_pgd_level_checkwx+0x11/0x20 [ 3.352611] [<c4034fdd>] mark_rodata_ro+0xcd/0xf0 [ 3.356677] [<c4a55c97>] kernel_init+0x17/0xc0 [ 3.360702] [<c4a5c409>] ret_from_kernel_thread+0x21/0x38 [ 3.364739] [<c4a55c80>] ? rest_init+0xa0/0xa0 [ 3.368709] ---[ end trace 7121849c40f4a5ba ]--- [ 3.372716] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages found. > [ 5.256044] ------------[ cut here ]------------ > [ 5.259267] WARNING: CPU: 0 PID: 1 at > arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() > [ 5.262668] x86/mm: Found insecure W+X mapping at address > ffe69000/0xffe69000 > [ 5.267109] Modules linked in: > [ 5.271403] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #122 > [ 5.275679] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > (2.19 ) 03/31/2011 > [ 5.279957] 00000000 00000000 f5cffeac c42b9f18 f5cffed8 f5cffec8 > c404062b 000000e1 > [ 5.284387] c403ca9c f5cfff50 00000163 00000000 f5cffee0 c4040686 > 00000009 f5cffed8 > [ 5.288815] c4d268ac f5cffef4 f5cfff1c c403ca9c c4d1f494 000000e1 > c4d268ac ffe69000 > [ 5.293314] Call Trace: > [ 5.297602] [<c42b9f18>] dump_stack+0x41/0x59 > [ 5.301864] [<c404062b>] warn_slowpath_common+0x6b/0xa0 > [ 5.306054] [<c403ca9c>] ? note_page+0x5ec/0x790 > [ 5.310209] [<c4040686>] warn_slowpath_fmt+0x26/0x30 > [ 5.314358] [<c403ca9c>] note_page+0x5ec/0x790 > [ 5.318440] [<c403cd8f>] ptdump_walk_pgd_level_core+0x14f/0x230 > [ 5.322578] [<c403ce91>] ptdump_walk_pgd_level_checkwx+0x11/0x20 > [ 5.326632] [<c4034ead>] mark_rodata_ro+0xcd/0xf0 > [ 5.330625] [<c4a4aab7>] kernel_init+0x17/0xc0 > [ 5.334585] [<c4a511c9>] ret_from_kernel_thread+0x21/0x38 > [ 5.338585] [<c4a4aaa0>] ? rest_init+0xa0/0xa0 > [ 5.342583] ---[ end trace bc9ac0874ad9a058 ]--- > [ 5.346630] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages > found. > > ...I'm not quite sure why it does backtrace, or how to debug this > one... > > Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 8:04 ` 4.4-rc5: ugly warn on: " Pavel Machek @ 2015-12-14 8:58 ` Borislav Petkov 2015-12-14 9:07 ` Pavel Machek 2015-12-14 12:29 ` Pavel Machek 1 sibling, 1 reply; 39+ messages in thread From: Borislav Petkov @ 2015-12-14 8:58 UTC (permalink / raw) To: Pavel Machek Cc: kernel list, sds, luto, arjan, brgerst, dvlasenk, hpa, torvalds, efault, peterz, tglx On Mon, Dec 14, 2015 at 09:04:03AM +0100, Pavel Machek wrote: > Hi! > > > Kernel complains: > > And now, we are at -rc5, and kernel still complains... You can disable CONFIG_DEBUG_WX in your .config: 54727e6e950a ("x86: don't make DEBUG_WX default to 'y' even with DEBUG_RODATA") -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 8:58 ` Borislav Petkov @ 2015-12-14 9:07 ` Pavel Machek 2015-12-14 9:15 ` Borislav Petkov 2015-12-14 19:18 ` Linus Torvalds 0 siblings, 2 replies; 39+ messages in thread From: Pavel Machek @ 2015-12-14 9:07 UTC (permalink / raw) To: Borislav Petkov Cc: kernel list, sds, luto, arjan, brgerst, dvlasenk, hpa, torvalds, efault, peterz, tglx On Mon 2015-12-14 09:58:03, Borislav Petkov wrote: > On Mon, Dec 14, 2015 at 09:04:03AM +0100, Pavel Machek wrote: > > Hi! > > > > > Kernel complains: > > > > And now, we are at -rc5, and kernel still complains... > > You can disable CONFIG_DEBUG_WX in your .config: > > 54727e6e950a ("x86: don't make DEBUG_WX default to 'y' even with DEBUG_RODATA") I know. But either someone cares, and it should be fixes, or noone cares, and the check should be removed. Backtrace should be removed in any case, as it is useless. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 9:07 ` Pavel Machek @ 2015-12-14 9:15 ` Borislav Petkov 2015-12-14 19:18 ` Linus Torvalds 1 sibling, 0 replies; 39+ messages in thread From: Borislav Petkov @ 2015-12-14 9:15 UTC (permalink / raw) To: Pavel Machek Cc: kernel list, sds, luto, arjan, brgerst, dvlasenk, hpa, torvalds, efault, peterz, tglx On Mon, Dec 14, 2015 at 10:07:26AM +0100, Pavel Machek wrote: > I know. But either someone cares, and it should be fixes, or noone > cares, and the check should be removed. Someone cares. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 9:07 ` Pavel Machek 2015-12-14 9:15 ` Borislav Petkov @ 2015-12-14 19:18 ` Linus Torvalds 2015-12-14 20:26 ` Pavel Machek 1 sibling, 1 reply; 39+ messages in thread From: Linus Torvalds @ 2015-12-14 19:18 UTC (permalink / raw) To: Pavel Machek Cc: Borislav Petkov, kernel list, Stephen Smalley, Andy Lutomirski, Arjan van de Ven, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Mon, Dec 14, 2015 at 1:07 AM, Pavel Machek <pavel@ucw.cz> wrote: > > I know. But either someone cares, and it should be fixes, or noone > cares, and the check should be removed. Someone cares, and it should be scheduled to be fixed for 4.5. The EFI mapping changes that were required to avoid the warning were much too big and late to make 4.4. So for now, don't enable CONFIG_DEBUG_WX for now. Unless you want to actively debug the EFI mapping changes, that is. Which I heartily recommend people doing. (The patches are in Matt Fleming's tree at git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git efi-pgtable and I think they are also merged in the -tip tree for next, but I haven't double-checked) Linus ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 19:18 ` Linus Torvalds @ 2015-12-14 20:26 ` Pavel Machek 2015-12-14 21:02 ` Andy Lutomirski 0 siblings, 1 reply; 39+ messages in thread From: Pavel Machek @ 2015-12-14 20:26 UTC (permalink / raw) To: Linus Torvalds Cc: Borislav Petkov, kernel list, Stephen Smalley, Andy Lutomirski, Arjan van de Ven, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner Hi! > > I know. But either someone cares, and it should be fixes, or noone > > cares, and the check should be removed. > > Someone cares, and it should be scheduled to be fixed for 4.5. The EFI > mapping changes that were required to avoid the warning were much too > big and late to make 4.4. > > So for now, don't enable CONFIG_DEBUG_WX for now. Unless you want to > actively debug the EFI mapping changes, that is. Which I heartily > recommend people doing. Ok, good, except... This is thinkpad X60. Good old BIOS. It should have no EFI. pavel@duo:~$ dmesg | grep EFI pavel@duo:~$ >From the messages I got: > [ 3.285993] x86/mm: Found insecure W+X mapping at address > ffe69000/0xffe69000 ---[ Persisent kmap() Area ]--- 0xffc00000-0xffd28000 1184K pte 0xffd28000-0xffddd000 724K RW GLB NX pte 0xffddd000-0xffe69000 560K pte 0xffe69000-0xffe6e000 20K RW GLB x pte 0xffe6e000-0xffe6f000 4K pte ---[ Fixmap Area ]--- That is not EFI, right? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 20:26 ` Pavel Machek @ 2015-12-14 21:02 ` Andy Lutomirski 2015-12-14 21:24 ` Arjan van de Ven 0 siblings, 1 reply; 39+ messages in thread From: Andy Lutomirski @ 2015-12-14 21:02 UTC (permalink / raw) To: Pavel Machek Cc: Linus Torvalds, Borislav Petkov, kernel list, Stephen Smalley, Arjan van de Ven, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Mon, Dec 14, 2015 at 12:26 PM, Pavel Machek <pavel@ucw.cz> wrote: > Hi! > >> > I know. But either someone cares, and it should be fixes, or noone >> > cares, and the check should be removed. >> >> Someone cares, and it should be scheduled to be fixed for 4.5. The EFI >> mapping changes that were required to avoid the warning were much too >> big and late to make 4.4. >> >> So for now, don't enable CONFIG_DEBUG_WX for now. Unless you want to >> actively debug the EFI mapping changes, that is. Which I heartily >> recommend people doing. > > Ok, good, except... This is thinkpad X60. Good old BIOS. It should > have no EFI. > > pavel@duo:~$ dmesg | grep EFI > pavel@duo:~$ > > From the messages I got: > >> [ 3.285993] x86/mm: Found insecure W+X mapping at address >> ffe69000/0xffe69000 > > ---[ Persisent kmap() Area ]--- > 0xffc00000-0xffd28000 1184K pte > 0xffd28000-0xffddd000 724K RW GLB NX pte > 0xffddd000-0xffe69000 560K pte > 0xffe69000-0xffe6e000 20K RW GLB x pte > 0xffe6e000-0xffe6f000 4K pte > ---[ Fixmap Area ]--- > > That is not EFI, right? That's weird. The only API to do that seems to be manually setting kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is kmap_prot a variable on x86 at all? It has exactly one writer, and that's the code that initializes it in the first place. Shouldn't we #define kmap_prot _PAGE_KERNEL? --Andy ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 21:02 ` Andy Lutomirski @ 2015-12-14 21:24 ` Arjan van de Ven 2015-12-14 22:25 ` Andy Lutomirski 2015-12-15 7:56 ` Pavel Machek 0 siblings, 2 replies; 39+ messages in thread From: Arjan van de Ven @ 2015-12-14 21:24 UTC (permalink / raw) To: Andy Lutomirski, Pavel Machek Cc: Linus Torvalds, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner > That's weird. The only API to do that seems to be manually setting > kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is > kmap_prot a variable on x86 at all? It has exactly one writer, and > that's the code that initializes it in the first place. Shouldn't we > #define kmap_prot _PAGE_KERNEL? iirc it changes based on runtime detection of NX capability ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 21:24 ` Arjan van de Ven @ 2015-12-14 22:25 ` Andy Lutomirski 2015-12-15 9:40 ` Pavel Machek 2015-12-15 7:56 ` Pavel Machek 1 sibling, 1 reply; 39+ messages in thread From: Andy Lutomirski @ 2015-12-14 22:25 UTC (permalink / raw) To: Arjan van de Ven Cc: Pavel Machek, Linus Torvalds, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Mon, Dec 14, 2015 at 1:24 PM, Arjan van de Ven <arjan@linux.intel.com> wrote: > >> That's weird. The only API to do that seems to be manually setting >> kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is >> kmap_prot a variable on x86 at all? It has exactly one writer, and >> that's the code that initializes it in the first place. Shouldn't we >> #define kmap_prot _PAGE_KERNEL? > > > iirc it changes based on runtime detection of NX capability > Maybe it did, but if it still does, I can't find the code. What *does* change is __supported_pte_mask. If we're willing to make disable_nx work a little less well, we could try to initialize __supported_pte_mask from the very beginning. (We currently seem to detect and enable NX even before we enable paging.) I suspect that Pavel is seeing a kmap mapping left over from so early that it didn't have NX set (killed by massage_pgprot). Borislav, could we do that? (Why do we have disable_nx at all? I suspect it was for debugging a long, long time ago.) Alternatively, we could go through and set NX everywhere after we decide we have NX, but that seems rather error-prone. --Andy -- Andy Lutomirski AMA Capital Management, LLC ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 22:25 ` Andy Lutomirski @ 2015-12-15 9:40 ` Pavel Machek 2015-12-15 17:45 ` Linus Torvalds 0 siblings, 1 reply; 39+ messages in thread From: Pavel Machek @ 2015-12-15 9:40 UTC (permalink / raw) To: Andy Lutomirski Cc: Arjan van de Ven, Linus Torvalds, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Mon 2015-12-14 14:25:10, Andy Lutomirski wrote: > On Mon, Dec 14, 2015 at 1:24 PM, Arjan van de Ven <arjan@linux.intel.com> wrote: > > > >> That's weird. The only API to do that seems to be manually setting > >> kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is > >> kmap_prot a variable on x86 at all? It has exactly one writer, and > >> that's the code that initializes it in the first place. Shouldn't we > >> #define kmap_prot _PAGE_KERNEL? > > > > > > iirc it changes based on runtime detection of NX capability > > > > Maybe it did, but if it still does, I can't find the code. > > What *does* change is __supported_pte_mask. If we're willing to make > disable_nx work a little less well, we could try to initialize > __supported_pte_mask from the very beginning. (We currently seem to > detect and enable NX even before we enable paging.) I suspect that > Pavel is seeing a kmap mapping left over from so early that it didn't > have NX set (killed by massage_pgprot). I tried applying: [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling paging but I still get [ 2.685402] ------------[ cut here ]------------ [ 2.688649] WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_ page+0x5ec/0x790() [ 2.691897] x86/mm: Found insecure W+X mapping at address ffe69000/0xffe69000 [ 2.695090] Modules linked in: Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 9:40 ` Pavel Machek @ 2015-12-15 17:45 ` Linus Torvalds 2015-12-15 18:30 ` Borislav Petkov ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Linus Torvalds @ 2015-12-15 17:45 UTC (permalink / raw) To: Pavel Machek Cc: Andy Lutomirski, Arjan van de Ven, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Tue, Dec 15, 2015 at 1:40 AM, Pavel Machek <pavel@ucw.cz> wrote: > > I tried applying: > > [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling > paging > > but I still get > > [ 2.691897] x86/mm: Found insecure W+X mapping at address ffe69000/0xffe69000 This may be an insane suggestion, but how about we try to detect when that entry gets set, rather than after the fact. Something really brute-force like diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 6ec0c8b2e9df..538c9bb239b9 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -337,6 +337,13 @@ static inline pmd_t pmd_clear_soft_dirty(pmd_t pmd) #endif /* CONFIG_HAVE_ARCH_SOFT_DIRTY */ +static inline int kernel_write_execute_prot(pgprotval_t protval) +{ + return !(protval & _PAGE_USER) && + !(protval & _PAGE_NX) && + (protval & _PAGE_RW); +} + /* * Mask out unsupported bits in a present pgprot. Non-present pgprots * can use those bits for other purposes, so leave them be. @@ -345,8 +352,10 @@ static inline pgprotval_t massage_pgprot(pgprot_t pgprot) { pgprotval_t protval = pgprot_val(pgprot); - if (protval & _PAGE_PRESENT) + if (protval & _PAGE_PRESENT) { protval &= __supported_pte_mask; + WARN_ON_ONCE(kernel_write_execute_prot(protval)); + } return protval; } or similar? The above is entirely untested. Maybe it doesn't compile. Or boot. Or work. Linus ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 17:45 ` Linus Torvalds @ 2015-12-15 18:30 ` Borislav Petkov 2015-12-15 19:06 ` Linus Torvalds 2015-12-15 18:40 ` Andy Lutomirski 2015-12-15 20:58 ` Pavel Machek 2 siblings, 1 reply; 39+ messages in thread From: Borislav Petkov @ 2015-12-15 18:30 UTC (permalink / raw) To: Linus Torvalds Cc: Pavel Machek, Andy Lutomirski, Arjan van de Ven, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Tue, Dec 15, 2015 at 09:45:40AM -0800, Linus Torvalds wrote: > On Tue, Dec 15, 2015 at 1:40 AM, Pavel Machek <pavel@ucw.cz> wrote: > > > > I tried applying: > > > > [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling > > paging > > > > but I still get > > > > [ 2.691897] x86/mm: Found insecure W+X mapping at address ffe69000/0xffe69000 > > This may be an insane suggestion, but how about we try to detect when > that entry gets set, rather than after the fact. > > Something really brute-force like > > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h > index 6ec0c8b2e9df..538c9bb239b9 100644 > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -337,6 +337,13 @@ static inline pmd_t pmd_clear_soft_dirty(pmd_t pmd) > > #endif /* CONFIG_HAVE_ARCH_SOFT_DIRTY */ > > +static inline int kernel_write_execute_prot(pgprotval_t protval) > +{ > + return !(protval & _PAGE_USER) && > + !(protval & _PAGE_NX) && Shouldn't this be without a "!"? AFAIU, we want _PAGE_NX | _PAGE_RW? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 18:30 ` Borislav Petkov @ 2015-12-15 19:06 ` Linus Torvalds 2015-12-15 19:15 ` Borislav Petkov 0 siblings, 1 reply; 39+ messages in thread From: Linus Torvalds @ 2015-12-15 19:06 UTC (permalink / raw) To: Borislav Petkov Cc: Pavel Machek, Andy Lutomirski, Arjan van de Ven, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Tue, Dec 15, 2015 at 10:30 AM, Borislav Petkov <bp@alien8.de> wrote: > On Tue, Dec 15, 2015 at 09:45:40AM -0800, Linus Torvalds wrote: >> >> +static inline int kernel_write_execute_prot(pgprotval_t protval) >> +{ >> + return !(protval & _PAGE_USER) && >> + !(protval & _PAGE_NX) && > > Shouldn't this be without a "!"? AFAIU, we want _PAGE_NX | _PAGE_RW? We want to *warn* about PAGE_RW without PAGE_NX. No? Linus ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 19:06 ` Linus Torvalds @ 2015-12-15 19:15 ` Borislav Petkov 0 siblings, 0 replies; 39+ messages in thread From: Borislav Petkov @ 2015-12-15 19:15 UTC (permalink / raw) To: Linus Torvalds Cc: Pavel Machek, Andy Lutomirski, Arjan van de Ven, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Tue, Dec 15, 2015 at 11:06:38AM -0800, Linus Torvalds wrote: > We want to *warn* about PAGE_RW without PAGE_NX. No? Ah yes, we do: note_page: ... if (st->check_wx && (pr & _PAGE_RW) && !(pr & _PAGE_NX)) { I got confused, sorry. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 17:45 ` Linus Torvalds 2015-12-15 18:30 ` Borislav Petkov @ 2015-12-15 18:40 ` Andy Lutomirski 2015-12-15 19:08 ` Linus Torvalds 2015-12-15 20:58 ` Pavel Machek 2 siblings, 1 reply; 39+ messages in thread From: Andy Lutomirski @ 2015-12-15 18:40 UTC (permalink / raw) To: Linus Torvalds Cc: Pavel Machek, Arjan van de Ven, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Tue, Dec 15, 2015 at 9:45 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Dec 15, 2015 at 1:40 AM, Pavel Machek <pavel@ucw.cz> wrote: >> >> I tried applying: >> >> [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling >> paging >> >> but I still get >> >> [ 2.691897] x86/mm: Found insecure W+X mapping at address ffe69000/0xffe69000 > > This may be an insane suggestion, but how about we try to detect when > that entry gets set, rather than after the fact. > > Something really brute-force like > > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h > index 6ec0c8b2e9df..538c9bb239b9 100644 > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -337,6 +337,13 @@ static inline pmd_t pmd_clear_soft_dirty(pmd_t pmd) > > #endif /* CONFIG_HAVE_ARCH_SOFT_DIRTY */ > > +static inline int kernel_write_execute_prot(pgprotval_t protval) > +{ > + return !(protval & _PAGE_USER) && > + !(protval & _PAGE_NX) && > + (protval & _PAGE_RW); > +} > + > /* > * Mask out unsupported bits in a present pgprot. Non-present pgprots > * can use those bits for other purposes, so leave them be. > @@ -345,8 +352,10 @@ static inline pgprotval_t massage_pgprot(pgprot_t pgprot) > { > pgprotval_t protval = pgprot_val(pgprot); > > - if (protval & _PAGE_PRESENT) > + if (protval & _PAGE_PRESENT) { > protval &= __supported_pte_mask; > + WARN_ON_ONCE(kernel_write_execute_prot(protval)); Shouldn't we switch those two lines? Arguably trying to set rwx permissions on !PAE is a bug even if it makes no difference, whereas setting rw- and getting rwx because we don't have NX support on the platform or kernel build doesn't indicate a bug. Anyway, I still think that we should apply my patches for 4.5 because I think they're cleanups, but apparently I guessed wrong as to what was causing Pavel's issue. But your patch would help diagnose it. --Andy ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 18:40 ` Andy Lutomirski @ 2015-12-15 19:08 ` Linus Torvalds 0 siblings, 0 replies; 39+ messages in thread From: Linus Torvalds @ 2015-12-15 19:08 UTC (permalink / raw) To: Andy Lutomirski Cc: Pavel Machek, Arjan van de Ven, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Tue, Dec 15, 2015 at 10:40 AM, Andy Lutomirski <luto@amacapital.net> wrote: > > Shouldn't we switch those two lines? No. This is for debugging Pavel's issue. If somehow the __supported_pte_mask ends up having NX clear again (memory scribble, whatever), we very explicitly would want to catch that. I'm *not* suggesting this as a generic patch to be applied anywhere else. That patch is meant to debug Pavel's particular setup, and nothing else. Linus ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 17:45 ` Linus Torvalds 2015-12-15 18:30 ` Borislav Petkov 2015-12-15 18:40 ` Andy Lutomirski @ 2015-12-15 20:58 ` Pavel Machek 2015-12-15 21:12 ` 4.4.-rc5: lguest causes " Pavel Machek 2015-12-15 21:33 ` 4.4-rc5: " Borislav Petkov 2 siblings, 2 replies; 39+ messages in thread From: Pavel Machek @ 2015-12-15 20:58 UTC (permalink / raw) To: Linus Torvalds Cc: Andy Lutomirski, Arjan van de Ven, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner Hi! > > I tried applying: > > > > [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling > > paging > > > > but I still get > > > > [ 2.691897] x86/mm: Found insecure W+X mapping at address ffe69000/0xffe69000 > > This may be an insane suggestion, but how about we try to detect when > that entry gets set, rather than after the fact. > > Something really brute-force like > > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h > index 6ec0c8b2e9df..538c9bb239b9 100644 > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -337,6 +337,13 @@ static inline pmd_t pmd_clear_soft_dirty(pmd_t pmd) > > #endif /* CONFIG_HAVE_ARCH_SOFT_DIRTY */ > > +static inline int kernel_write_execute_prot(pgprotval_t protval) > +{ > + return !(protval & _PAGE_USER) && > + !(protval & _PAGE_NX) && > + (protval & _PAGE_RW); > +} ... > + if (protval & _PAGE_PRESENT) { > protval &= __supported_pte_mask; > + WARN_ON_ONCE(kernel_write_execute_prot(protval)); > + } > > return protval; > } > > or similar? > > The above is entirely untested. Maybe it doesn't compile. Or > boot. Or work. Well, with two extra spaces at each line, it does not apply :-). I applied it by hand, and the output is: [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 000000000 mask F80000000 write-back [ 0.000000] 1 base 080000000 mask FC0000000 write-back [ 0.000000] 2 base 0BF700000 mask FFFF00000 uncachable [ 0.000000] 3 base 0BF800000 mask FFF800000 uncachable [ 0.000000] 4 disabled [ 0.000000] 5 disabled [ 0.000000] 6 disabled [ 0.000000] 7 disabled [ 0.000000] x86/PAT: PAT not supported by CPU. [ 0.000000] initial memory mapped: [mem 0x00000000-0x05bfffff] [ 0.000000] Base memory trampoline at [c009b000] 9b000 size 16384 [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: CPU: 0 PID: 0 at ./arch/x86/include/asm/pgtable.h:357 kernel_physical_mapping_init+0x 256/0x395() [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-rc5+ #137 [ 0.000000] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011 [ 0.000000] 00000000 00000000 c4e63e90 c42baaf8 00000000 c4e63eac c404066b 00000165 [ 0.000000] c4f134da 00000000 00000000 00000000 c4e63ebc c404070f 00000009 00000000 [ 0.000000] c4e63f18 c4f134da c4e63f00 00000000 00000000 00000000 00000000 00000000 [ 0.000000] Call Trace: [ 0.000000] [<c42baaf8>] dump_stack+0x41/0x59 [ 0.000000] [<c404066b>] warn_slowpath_common+0x6b/0xa0 [ 0.000000] [<c4f134da>] ? kernel_physical_mapping_init+0x256/0x395 [ 0.000000] [<c404070f>] warn_slowpath_null+0xf/0x20 [ 0.000000] [<c4f134da>] kernel_physical_mapping_init+0x256/0x395 [ 0.000000] [<c4a4de21>] init_memory_mapping+0x191/0x300 [ 0.000000] [<c4f12d96>] init_mem_mapping+0xe7/0x1f3 [ 0.000000] [<c4f12d96>] ? init_mem_mapping+0xe7/0x1f3 [ 0.000000] [<c4f065ef>] setup_arch+0x659/0x8ca [ 0.000000] [<c4f0480e>] start_kernel+0xbb/0x360 [ 0.000000] [<c4f042d4>] i386_start_kernel+0x82/0x86 [ 0.000000] ---[ end trace e117245cd61feaf1 ]--- [ 0.000000] BRK [0x0566a000, 0x0566afff] PGTABLE [ 0.000000] BRK [0x0566b000, 0x0566bfff] PGTABLE [ 0.000000] BRK [0x0566c000, 0x0566cfff] PGTABLE I'll take a look if I can figure out what it means... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* 4.4.-rc5: lguest causes ugly warn on: 5 W+X pages found 2015-12-15 20:58 ` Pavel Machek @ 2015-12-15 21:12 ` Pavel Machek 2015-12-16 2:24 ` Rusty Russell 2015-12-15 21:33 ` 4.4-rc5: " Borislav Petkov 1 sibling, 1 reply; 39+ messages in thread From: Pavel Machek @ 2015-12-15 21:12 UTC (permalink / raw) To: Linus Torvalds, rusty Cc: Andy Lutomirski, Arjan van de Ven, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner Hi! > > or similar? > > > > The above is entirely untested. Maybe it doesn't compile. Or > > boot. Or work. > > Well, with two extra spaces at each line, it does not apply :-). > > I applied it by hand, and the output is: > > [ 0.000000] MTRR variable ranges enabled: ...> [ 0.000000] BRK [0x0566c000, 0x0566cfff] PGTABLE > > I'll take a look if I can figure out what it means... Wait, there's more in the log. [ 1.952146] Bluetooth: HCI UART protocol H4 registered [ 1.954335] Bluetooth: HCI UART protocol BCSP registered [ 1.956750] usbcore: registered new interface driver btusb [ 1.958953] ------------[ cut here ]------------ [ 1.961149] WARNING: CPU: 1 PID: 1 at ./arch/x86/include/asm/pgtable.h:357 vmap_page_range_noflush+0x1f0/0x280() [ 1.963511] Modules linked in: [ 1.965849] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.4.0-rc5+ #137 [ 1.968230] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011 [ 1.970593] 00000001 00000000 f5cffe64 c42baaf8 00000000 f5cffe80 c404066b 00000165 [ 1.973103] c40fbe70 00000163 00000000 00000000 f5cffe90 c404070f 00000009 00000000 [ 1.975670] f5cffee0 c40fbe70 c4f88348 00000000 ffe6dfff ffe6e000 c4f8a018 ffe6dfff [ 1.978304] Call Trace: [ 1.980882] [<c42baaf8>] dump_stack+0x41/0x59 [ 1.983464] [<c404066b>] warn_slowpath_common+0x6b/0xa0 [ 1.986053] [<c40fbe70>] ? vmap_page_range_noflush+0x1f0/0x280 [ 1.988625] [<c404070f>] warn_slowpath_null+0xf/0x20 [ 1.991154] [<c40fbe70>] vmap_page_range_noflush+0x1f0/0x280 [ 1.993676] [<c40fbf2b>] map_vm_area+0x2b/0x40 [ 1.996153] [<c4f2c795>] init+0xf8/0x1a4 [ 1.998591] [<c4f2c69d>] ? edac_init+0x67/0x67 [ 2.001014] [<c4000442>] do_one_initcall+0xc2/0x1c0 [ 2.003391] [<c4f044e3>] ? initcall_blacklist+0x97/0x97 [ 2.005815] [<c4f044e3>] ? initcall_blacklist+0x97/0x97 [ 2.008161] [<c4051546>] ? __usermodehelper_set_disable_depth+0x36/0x40 [ 2.010518] [<c407d4a6>] ? up_write+0x16/0x40 [ 2.012817] [<c4f04ba3>] kernel_init_freeable+0xf0/0x16d [ 2.015078] [<c4f04ba3>] ? kernel_init_freeable+0xf0/0x16d [ 2.017386] [<c4a4d9c8>] kernel_init+0x8/0xc0 [ 2.019661] [<c4a54149>] ret_from_kernel_thread+0x21/0x38 [ 2.021932] [<c4a4d9c0>] ? rest_init+0xa0/0xa0 [ 2.024168] ---[ end trace e117245cd61feaf2 ]--- [ 2.026383] lguest: mapped switcher at ffe69000 [ 2.028958] sdhci: Secure Digital Host Controller Interface driver ...which I don't understand; did not we say warn on _once_? ... Um. But I think we have a winner: "lguest: mapped switcher at ffe69000". Rusty, does the switcher need to be W+X? And yes, I have lguest enabled, not sure why. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4.-rc5: lguest causes ugly warn on: 5 W+X pages found 2015-12-15 21:12 ` 4.4.-rc5: lguest causes " Pavel Machek @ 2015-12-16 2:24 ` Rusty Russell 2015-12-16 8:10 ` Pavel Machek 0 siblings, 1 reply; 39+ messages in thread From: Rusty Russell @ 2015-12-16 2:24 UTC (permalink / raw) To: Pavel Machek, Linus Torvalds Cc: Andy Lutomirski, Arjan van de Ven, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner Pavel Machek <pavel@ucw.cz> writes: > Hi! > >> > or similar? >> > >> > The above is entirely untested. Maybe it doesn't compile. Or >> > boot. Or work. >> >> Well, with two extra spaces at each line, it does not apply :-). >> >> I applied it by hand, and the output is: >> >> [ 0.000000] MTRR variable ranges enabled: > ...> [ 0.000000] BRK [0x0566c000, 0x0566cfff] PGTABLE >> >> I'll take a look if I can figure out what it means... > > Wait, there's more in the log. > > [ 1.952146] Bluetooth: HCI UART protocol H4 registered > [ 1.954335] Bluetooth: HCI UART protocol BCSP registered > [ 1.956750] usbcore: registered new interface driver btusb > [ 1.958953] ------------[ cut here ]------------ > [ 1.961149] WARNING: CPU: 1 PID: 1 at > ./arch/x86/include/asm/pgtable.h:357 > vmap_page_range_noflush+0x1f0/0x280() > [ 1.963511] Modules linked in: > [ 1.965849] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W > 4.4.0-rc5+ #137 > [ 1.968230] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > (2.19 ) 03/31/2011 > [ 1.970593] 00000001 00000000 f5cffe64 c42baaf8 00000000 f5cffe80 > c404066b 00000165 > [ 1.973103] c40fbe70 00000163 00000000 00000000 f5cffe90 c404070f > 00000009 00000000 > [ 1.975670] f5cffee0 c40fbe70 c4f88348 00000000 ffe6dfff ffe6e000 > c4f8a018 ffe6dfff > [ 1.978304] Call Trace: > [ 1.980882] [<c42baaf8>] dump_stack+0x41/0x59 > [ 1.983464] [<c404066b>] warn_slowpath_common+0x6b/0xa0 > [ 1.986053] [<c40fbe70>] ? vmap_page_range_noflush+0x1f0/0x280 > [ 1.988625] [<c404070f>] warn_slowpath_null+0xf/0x20 > [ 1.991154] [<c40fbe70>] vmap_page_range_noflush+0x1f0/0x280 > [ 1.993676] [<c40fbf2b>] map_vm_area+0x2b/0x40 > [ 1.996153] [<c4f2c795>] init+0xf8/0x1a4 > [ 1.998591] [<c4f2c69d>] ? edac_init+0x67/0x67 > [ 2.001014] [<c4000442>] do_one_initcall+0xc2/0x1c0 > [ 2.003391] [<c4f044e3>] ? initcall_blacklist+0x97/0x97 > [ 2.005815] [<c4f044e3>] ? initcall_blacklist+0x97/0x97 > [ 2.008161] [<c4051546>] ? > __usermodehelper_set_disable_depth+0x36/0x40 > [ 2.010518] [<c407d4a6>] ? up_write+0x16/0x40 > [ 2.012817] [<c4f04ba3>] kernel_init_freeable+0xf0/0x16d > [ 2.015078] [<c4f04ba3>] ? kernel_init_freeable+0xf0/0x16d > [ 2.017386] [<c4a4d9c8>] kernel_init+0x8/0xc0 > [ 2.019661] [<c4a54149>] ret_from_kernel_thread+0x21/0x38 > [ 2.021932] [<c4a4d9c0>] ? rest_init+0xa0/0xa0 > [ 2.024168] ---[ end trace e117245cd61feaf2 ]--- > [ 2.026383] lguest: mapped switcher at ffe69000 > [ 2.028958] sdhci: Secure Digital Host Controller Interface driver > > ...which I don't understand; did not we say warn on _once_? > ... Um. But I think we have a winner: "lguest: mapped switcher at > ffe69000". > > Rusty, does the switcher need to be W+X? > > And yes, I have lguest enabled, not sure why. No. The layout is "<text page> <per-cpu-stack-pages>..." and I lazily did that as a single map_vm_area(switcher_vma, PAGE_KERNEL_EXEC, lg_switcher_pages); This boots, does it solve the problem? Thanks! Rusty. From: Rusty Russell <rusty@rustcorp.com.au> Subject: lguest: map switcher text R/O. Pavel noted that lguest maps the switcher code executable and read-write. This is a bad idea for any kernel text, but particularly for text mapped at a fixed address. Create two vmas, one for the text (PAGE_KERNEL_RX) and another for the stacks (PAGE_KERNEL). Use VM_NO_GUARD to map them adjacent (as expected by the rest of the code). Reported-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff --git a/arch/x86/include/asm/lguest.h b/arch/x86/include/asm/lguest.h index 3bbc07a57a31..73d0c9b92087 100644 --- a/arch/x86/include/asm/lguest.h +++ b/arch/x86/include/asm/lguest.h @@ -12,7 +12,9 @@ #define GUEST_PL 1 /* Page for Switcher text itself, then two pages per cpu */ -#define TOTAL_SWITCHER_PAGES (1 + 2 * nr_cpu_ids) +#define SWITCHER_TEXT_PAGES (1) +#define SWITCHER_STACK_PAGES (2 * nr_cpu_ids) +#define TOTAL_SWITCHER_PAGES (SWITCHER_TEXT_PAGES + SWITCHER_STACK_PAGES) /* Where we map the Switcher, in both Host and Guest. */ extern unsigned long switcher_addr; diff --git a/drivers/lguest/core.c b/drivers/lguest/core.c index 312ffd3d0017..021915baef35 100644 --- a/drivers/lguest/core.c +++ b/drivers/lguest/core.c @@ -22,7 +22,8 @@ unsigned long switcher_addr; struct page **lg_switcher_pages; -static struct vm_struct *switcher_vma; +static struct vm_struct *switcher_text_vma; +static struct vm_struct *switcher_stacks_vma; /* This One Big lock protects all inter-guest data structures. */ DEFINE_MUTEX(lguest_lock); @@ -83,54 +84,80 @@ static __init int map_switcher(void) } /* + * Copy in the compiled-in Switcher code (from x86/switcher_32.S). + * It goes in the first page, which we map in momentarily. + */ + memcpy(kmap(lg_switcher_pages[0]), start_switcher_text, + end_switcher_text - start_switcher_text); + kunmap(lg_switcher_pages[0]); + + /* * We place the Switcher underneath the fixmap area, which is the * highest virtual address we can get. This is important, since we * tell the Guest it can't access this memory, so we want its ceiling * as high as possible. */ - switcher_addr = FIXADDR_START - (TOTAL_SWITCHER_PAGES+1)*PAGE_SIZE; + switcher_addr = FIXADDR_START - TOTAL_SWITCHER_PAGES*PAGE_SIZE; /* - * Now we reserve the "virtual memory area" we want. We might - * not get it in theory, but in practice it's worked so far. - * The end address needs +1 because __get_vm_area allocates an - * extra guard page, so we need space for that. + * Now we reserve the "virtual memory area"s we want. We might + * not get them in theory, but in practice it's worked so far. + * + * We want the switcher text to be read-only and executable, and + * the stacks to be read-write and non-executable. */ - switcher_vma = __get_vm_area(TOTAL_SWITCHER_PAGES * PAGE_SIZE, - VM_ALLOC, switcher_addr, switcher_addr - + (TOTAL_SWITCHER_PAGES+1) * PAGE_SIZE); - if (!switcher_vma) { + switcher_text_vma = __get_vm_area(PAGE_SIZE, VM_ALLOC|VM_NO_GUARD, + switcher_addr, + switcher_addr + PAGE_SIZE); + + if (!switcher_text_vma) { err = -ENOMEM; printk("lguest: could not map switcher pages high\n"); goto free_pages; } + switcher_stacks_vma = __get_vm_area(SWITCHER_STACK_PAGES * PAGE_SIZE, + VM_ALLOC|VM_NO_GUARD, + switcher_addr + PAGE_SIZE, + switcher_addr + TOTAL_SWITCHER_PAGES * PAGE_SIZE); + if (!switcher_stacks_vma) { + err = -ENOMEM; + printk("lguest: could not map switcher pages high\n"); + goto free_text_vma; + } + /* * This code actually sets up the pages we've allocated to appear at * switcher_addr. map_vm_area() takes the vma we allocated above, the - * kind of pages we're mapping (kernel pages), and a pointer to our - * array of struct pages. + * kind of pages we're mapping (kernel text pages and kernel writable + * pages respectively), and a pointer to our array of struct pages. */ - err = map_vm_area(switcher_vma, PAGE_KERNEL_EXEC, lg_switcher_pages); + err = map_vm_area(switcher_text_vma, PAGE_KERNEL_RX, lg_switcher_pages); + if (err) { + printk("lguest: text map_vm_area failed: %i\n", err); + goto free_vmas; + } + + err = map_vm_area(switcher_stacks_vma, PAGE_KERNEL, + lg_switcher_pages + SWITCHER_TEXT_PAGES); if (err) { - printk("lguest: map_vm_area failed: %i\n", err); - goto free_vma; + printk("lguest: stacks map_vm_area failed: %i\n", err); + goto free_vmas; } /* * Now the Switcher is mapped at the right address, we can't fail! - * Copy in the compiled-in Switcher code (from x86/switcher_32.S). */ - memcpy(switcher_vma->addr, start_switcher_text, - end_switcher_text - start_switcher_text); - printk(KERN_INFO "lguest: mapped switcher at %p\n", - switcher_vma->addr); + switcher_text_vma->addr); /* And we succeeded... */ return 0; -free_vma: - vunmap(switcher_vma->addr); +free_vmas: + /* Undoes map_vm_area and __get_vm_area */ + vunmap(switcher_stacks_vma->addr); +free_text_vma: + vunmap(switcher_text_vma->addr); free_pages: i = TOTAL_SWITCHER_PAGES; free_some_pages: @@ -148,7 +175,8 @@ static void unmap_switcher(void) unsigned int i; /* vunmap() undoes *both* map_vm_area() and __get_vm_area(). */ - vunmap(switcher_vma->addr); + vunmap(switcher_text_vma->addr); + vunmap(switcher_stacks_vma->addr); /* Now we just need to free the pages we copied the switcher into */ for (i = 0; i < TOTAL_SWITCHER_PAGES; i++) __free_pages(lg_switcher_pages[i], 0); ^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: 4.4.-rc5: lguest causes ugly warn on: 5 W+X pages found 2015-12-16 2:24 ` Rusty Russell @ 2015-12-16 8:10 ` Pavel Machek 0 siblings, 0 replies; 39+ messages in thread From: Pavel Machek @ 2015-12-16 8:10 UTC (permalink / raw) To: Rusty Russell Cc: Linus Torvalds, Andy Lutomirski, Arjan van de Ven, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner Hi! > > Rusty, does the switcher need to be W+X? > > > > And yes, I have lguest enabled, not sure why. > > No. The layout is "<text page> <per-cpu-stack-pages>..." and I lazily > did that as a single > map_vm_area(switcher_vma, PAGE_KERNEL_EXEC, lg_switcher_pages); > > This boots, does it solve the problem? Let me see. Note that I'm not actually using lguest. git complains about trailing whitespace in the patch. Otherwise... yes, this helps. "no W+X pages found". Tested-by: Pavel Machek <pavel@ucw.cz> Thanks, Pavel > Reported-by: Pavel Machek <pavel@ucw.cz> > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > > diff --git a/arch/x86/include/asm/lguest.h b/arch/x86/include/asm/lguest.h > index 3bbc07a57a31..73d0c9b92087 100644 > --- a/arch/x86/include/asm/lguest.h > +++ b/arch/x86/include/asm/lguest.h > @@ -12,7 +12,9 @@ > #define GUEST_PL 1 > > /* Page for Switcher text itself, then two pages per cpu */ > -#define TOTAL_SWITCHER_PAGES (1 + 2 * nr_cpu_ids) > +#define SWITCHER_TEXT_PAGES (1) > +#define SWITCHER_STACK_PAGES (2 * nr_cpu_ids) > +#define TOTAL_SWITCHER_PAGES (SWITCHER_TEXT_PAGES + SWITCHER_STACK_PAGES) > > /* Where we map the Switcher, in both Host and Guest. */ > extern unsigned long switcher_addr; > diff --git a/drivers/lguest/core.c b/drivers/lguest/core.c > index 312ffd3d0017..021915baef35 100644 > --- a/drivers/lguest/core.c > +++ b/drivers/lguest/core.c > @@ -22,7 +22,8 @@ > > unsigned long switcher_addr; > struct page **lg_switcher_pages; > -static struct vm_struct *switcher_vma; > +static struct vm_struct *switcher_text_vma; > +static struct vm_struct *switcher_stacks_vma; > > /* This One Big lock protects all inter-guest data structures. */ > DEFINE_MUTEX(lguest_lock); > @@ -83,54 +84,80 @@ static __init int map_switcher(void) > } > > /* > + * Copy in the compiled-in Switcher code (from x86/switcher_32.S). > + * It goes in the first page, which we map in momentarily. > + */ > + memcpy(kmap(lg_switcher_pages[0]), start_switcher_text, > + end_switcher_text - start_switcher_text); > + kunmap(lg_switcher_pages[0]); > + > + /* > * We place the Switcher underneath the fixmap area, which is the > * highest virtual address we can get. This is important, since we > * tell the Guest it can't access this memory, so we want its ceiling > * as high as possible. > */ > - switcher_addr = FIXADDR_START - (TOTAL_SWITCHER_PAGES+1)*PAGE_SIZE; > + switcher_addr = FIXADDR_START - TOTAL_SWITCHER_PAGES*PAGE_SIZE; > > /* > - * Now we reserve the "virtual memory area" we want. We might > - * not get it in theory, but in practice it's worked so far. > - * The end address needs +1 because __get_vm_area allocates an > - * extra guard page, so we need space for that. > + * Now we reserve the "virtual memory area"s we want. We might > + * not get them in theory, but in practice it's worked so far. > + * > + * We want the switcher text to be read-only and executable, and > + * the stacks to be read-write and non-executable. > */ > - switcher_vma = __get_vm_area(TOTAL_SWITCHER_PAGES * PAGE_SIZE, > - VM_ALLOC, switcher_addr, switcher_addr > - + (TOTAL_SWITCHER_PAGES+1) * PAGE_SIZE); > - if (!switcher_vma) { > + switcher_text_vma = __get_vm_area(PAGE_SIZE, VM_ALLOC|VM_NO_GUARD, > + switcher_addr, > + switcher_addr + PAGE_SIZE); > + > + if (!switcher_text_vma) { > err = -ENOMEM; > printk("lguest: could not map switcher pages high\n"); > goto free_pages; > } > > + switcher_stacks_vma = __get_vm_area(SWITCHER_STACK_PAGES * PAGE_SIZE, > + VM_ALLOC|VM_NO_GUARD, > + switcher_addr + PAGE_SIZE, > + switcher_addr + TOTAL_SWITCHER_PAGES * PAGE_SIZE); > + if (!switcher_stacks_vma) { > + err = -ENOMEM; > + printk("lguest: could not map switcher pages high\n"); > + goto free_text_vma; > + } > + > /* > * This code actually sets up the pages we've allocated to appear at > * switcher_addr. map_vm_area() takes the vma we allocated above, the > - * kind of pages we're mapping (kernel pages), and a pointer to our > - * array of struct pages. > + * kind of pages we're mapping (kernel text pages and kernel writable > + * pages respectively), and a pointer to our array of struct pages. > */ > - err = map_vm_area(switcher_vma, PAGE_KERNEL_EXEC, lg_switcher_pages); > + err = map_vm_area(switcher_text_vma, PAGE_KERNEL_RX, lg_switcher_pages); > + if (err) { > + printk("lguest: text map_vm_area failed: %i\n", err); > + goto free_vmas; > + } > + > + err = map_vm_area(switcher_stacks_vma, PAGE_KERNEL, > + lg_switcher_pages + SWITCHER_TEXT_PAGES); > if (err) { > - printk("lguest: map_vm_area failed: %i\n", err); > - goto free_vma; > + printk("lguest: stacks map_vm_area failed: %i\n", err); > + goto free_vmas; > } > > /* > * Now the Switcher is mapped at the right address, we can't fail! > - * Copy in the compiled-in Switcher code (from x86/switcher_32.S). > */ > - memcpy(switcher_vma->addr, start_switcher_text, > - end_switcher_text - start_switcher_text); > - > printk(KERN_INFO "lguest: mapped switcher at %p\n", > - switcher_vma->addr); > + switcher_text_vma->addr); > /* And we succeeded... */ > return 0; > > -free_vma: > - vunmap(switcher_vma->addr); > +free_vmas: > + /* Undoes map_vm_area and __get_vm_area */ > + vunmap(switcher_stacks_vma->addr); > +free_text_vma: > + vunmap(switcher_text_vma->addr); > free_pages: > i = TOTAL_SWITCHER_PAGES; > free_some_pages: > @@ -148,7 +175,8 @@ static void unmap_switcher(void) > unsigned int i; > > /* vunmap() undoes *both* map_vm_area() and __get_vm_area(). */ > - vunmap(switcher_vma->addr); > + vunmap(switcher_text_vma->addr); > + vunmap(switcher_stacks_vma->addr); > /* Now we just need to free the pages we copied the switcher into */ > for (i = 0; i < TOTAL_SWITCHER_PAGES; i++) > __free_pages(lg_switcher_pages[i], 0); -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 20:58 ` Pavel Machek 2015-12-15 21:12 ` 4.4.-rc5: lguest causes " Pavel Machek @ 2015-12-15 21:33 ` Borislav Petkov 2015-12-15 22:07 ` Pavel Machek 1 sibling, 1 reply; 39+ messages in thread From: Borislav Petkov @ 2015-12-15 21:33 UTC (permalink / raw) To: Pavel Machek, Linus Torvalds Cc: Andy Lutomirski, Arjan van de Ven, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Tue, Dec 15, 2015 at 09:58:35PM +0100, Pavel Machek wrote: > [ 0.000000] Base memory trampoline at [c009b000] 9b000 size 16384 > [ 0.000000] ------------[ cut here ]------------ > [ 0.000000] WARNING: CPU: 0 PID: 0 at > ./arch/x86/include/asm/pgtable.h:357 kernel_physical_mapping_init+0x > 256/0x395() > [ 0.000000] Modules linked in: > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-rc5+ #137 > [ 0.000000] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > (2.19 ) 03/31/2011 > [ 0.000000] 00000000 00000000 c4e63e90 c42baaf8 00000000 c4e63eac > c404066b 00000165 > [ 0.000000] c4f134da 00000000 00000000 00000000 c4e63ebc c404070f > 00000009 00000000 > [ 0.000000] c4e63f18 c4f134da c4e63f00 00000000 00000000 00000000 > 00000000 00000000 > [ 0.000000] Call Trace: > [ 0.000000] [<c42baaf8>] dump_stack+0x41/0x59 > [ 0.000000] [<c404066b>] warn_slowpath_common+0x6b/0xa0 > [ 0.000000] [<c4f134da>] ? > kernel_physical_mapping_init+0x256/0x395 > [ 0.000000] [<c404070f>] warn_slowpath_null+0xf/0x20 > [ 0.000000] [<c4f134da>] kernel_physical_mapping_init+0x256/0x395 > [ 0.000000] [<c4a4de21>] init_memory_mapping+0x191/0x300 > [ 0.000000] [<c4f12d96>] init_mem_mapping+0xe7/0x1f3 Looks like the ISA range to me: init_mem_mapping: ... /* the ISA range is always mapped regardless of memory holes */ init_memory_mapping(0, ISA_END_ADDRESS); Does that kernel_physical_mapping_init() even pay attention to __supported_pte_mask and thus _PAGE_NX? I don't see it. Hmm, not really: pgprot_t init_prot = __pgprot(PTE_IDENT_ATTR | _PAGE_PSE); ... prot = PAGE_KERNEL_LARGE_EXEC; ... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 21:33 ` 4.4-rc5: " Borislav Petkov @ 2015-12-15 22:07 ` Pavel Machek 2015-12-15 22:15 ` Borislav Petkov 0 siblings, 1 reply; 39+ messages in thread From: Pavel Machek @ 2015-12-15 22:07 UTC (permalink / raw) To: Borislav Petkov Cc: Linus Torvalds, Andy Lutomirski, Arjan van de Ven, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Tue 2015-12-15 22:33:59, Borislav Petkov wrote: > On Tue, Dec 15, 2015 at 09:58:35PM +0100, Pavel Machek wrote: > > [ 0.000000] Base memory trampoline at [c009b000] 9b000 size 16384 > > [ 0.000000] ------------[ cut here ]------------ > > [ 0.000000] WARNING: CPU: 0 PID: 0 at > > ./arch/x86/include/asm/pgtable.h:357 kernel_physical_mapping_init+0x > > 256/0x395() > > [ 0.000000] Modules linked in: > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-rc5+ #137 > > [ 0.000000] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > > (2.19 ) 03/31/2011 > > [ 0.000000] 00000000 00000000 c4e63e90 c42baaf8 00000000 c4e63eac > > c404066b 00000165 > > [ 0.000000] c4f134da 00000000 00000000 00000000 c4e63ebc c404070f > > 00000009 00000000 > > [ 0.000000] c4e63f18 c4f134da c4e63f00 00000000 00000000 00000000 > > 00000000 00000000 > > [ 0.000000] Call Trace: > > [ 0.000000] [<c42baaf8>] dump_stack+0x41/0x59 > > [ 0.000000] [<c404066b>] warn_slowpath_common+0x6b/0xa0 > > [ 0.000000] [<c4f134da>] ? > > kernel_physical_mapping_init+0x256/0x395 > > [ 0.000000] [<c404070f>] warn_slowpath_null+0xf/0x20 > > [ 0.000000] [<c4f134da>] kernel_physical_mapping_init+0x256/0x395 > > [ 0.000000] [<c4a4de21>] init_memory_mapping+0x191/0x300 > > [ 0.000000] [<c4f12d96>] init_mem_mapping+0xe7/0x1f3 > > Looks like the ISA range to me: > > init_mem_mapping: > > ... > > /* the ISA range is always mapped regardless of memory holes */ > init_memory_mapping(0, ISA_END_ADDRESS); > > Does that kernel_physical_mapping_init() even pay attention to > __supported_pte_mask and thus _PAGE_NX? I don't see it. Mystery solved, and prize goes to the lguest. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 22:07 ` Pavel Machek @ 2015-12-15 22:15 ` Borislav Petkov 0 siblings, 0 replies; 39+ messages in thread From: Borislav Petkov @ 2015-12-15 22:15 UTC (permalink / raw) To: Pavel Machek Cc: Linus Torvalds, Andy Lutomirski, Arjan van de Ven, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Tue, Dec 15, 2015 at 11:07:09PM +0100, Pavel Machek wrote: > Mystery solved, and prize goes to the lguest. But that splat has nowhere lguest in it. Are you saying, you don't see any more splats if you disable lguest? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 21:24 ` Arjan van de Ven 2015-12-14 22:25 ` Andy Lutomirski @ 2015-12-15 7:56 ` Pavel Machek 2015-12-15 8:09 ` [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Andy Lutomirski 2015-12-15 13:26 ` 4.4-rc5: ugly warn on: 5 W+X pages found Arjan van de Ven 1 sibling, 2 replies; 39+ messages in thread From: Pavel Machek @ 2015-12-15 7:56 UTC (permalink / raw) To: Arjan van de Ven Cc: Andy Lutomirski, Linus Torvalds, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote: > > >That's weird. The only API to do that seems to be manually setting > >kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is > >kmap_prot a variable on x86 at all? It has exactly one writer, and > >that's the code that initializes it in the first place. Shouldn't we > >#define kmap_prot _PAGE_KERNEL? > > iirc it changes based on runtime detection of NX capability Huh. Is it possible that core duo is so old that it has no NX? processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU T2400 @ 1.83GHz stepping : 8 microcode : 0x39 ... wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm dtherm No, it lists nx in flags. Linus asked me about trying without CONFIG_EFI. I should have no EFI here, but I'll try it. I turned off CONFIG_EFI, but CONFIG_UEFI_CPER can't seem to be disabled easily. Still: [ 3.269750] WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() [ 3.271999] x86/mm: Found insecure W+X mapping at address ffe69000/0xffe69000 pavel@duo:~$ zcat /proc/config.gz | grep EFI # CONFIG_EFI_PARTITION is not set # CONFIG_EFI is not set CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y CONFIG_UEFI_CPER=y pavel@duo:~$ Ok, I managed to turn off even CONFIG_UEFI_CPER after some fight, but result is the same. (Hmm... I'll probably regret it, but... I guess config.gz does contain some information useful for the attacker. How long till some "hardened distro" chmods it to 600?) Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup 2015-12-15 7:56 ` Pavel Machek @ 2015-12-15 8:09 ` Andy Lutomirski 2015-12-15 8:09 ` [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling paging Andy Lutomirski ` (2 more replies) 2015-12-15 13:26 ` 4.4-rc5: ugly warn on: 5 W+X pages found Arjan van de Ven 1 sibling, 3 replies; 39+ messages in thread From: Andy Lutomirski @ 2015-12-15 8:09 UTC (permalink / raw) To: Pavel Machek, x86 Cc: Arjan van de Ven, Linus Torvalds, Borislav Petkov, linux-kernel, Stephen Smalley, Brian Gerst, Denys Vlasenko, hpa, Mike Galbraith, Peter Zijlstra, Andy Lutomirski The fixlet might help with some WX warnings. The kmap cleanup is just a cleanup. This is very lightly tested. Andy Lutomirski (2): x86_32/mm: Set NX in __supported_pte_mask before enabling paging x86/mm: Make kmap_prot into a #define arch/x86/include/asm/fixmap.h | 2 +- arch/x86/kernel/head_32.S | 6 ++++++ arch/x86/mm/init_32.c | 3 --- arch/x86/mm/setup_nx.c | 5 ++--- 4 files changed, 9 insertions(+), 7 deletions(-) -- 2.5.0 ^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling paging 2015-12-15 8:09 ` [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Andy Lutomirski @ 2015-12-15 8:09 ` Andy Lutomirski 2015-12-15 8:09 ` [PATCH 2/2] x86/mm: Make kmap_prot into a #define Andy Lutomirski 2016-01-19 9:26 ` [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Ingo Molnar 2 siblings, 0 replies; 39+ messages in thread From: Andy Lutomirski @ 2015-12-15 8:09 UTC (permalink / raw) To: Pavel Machek, x86 Cc: Arjan van de Ven, Linus Torvalds, Borislav Petkov, linux-kernel, Stephen Smalley, Brian Gerst, Denys Vlasenko, hpa, Mike Galbraith, Peter Zijlstra, Andy Lutomirski There's a short window in which very early mappings can end up with NX clear because they are created before we've noticed that we have NX. It turns out that we detect NX very early, so there's no need to defer __supported_pte_mask setup. Signed-off-by: Andy Lutomirski <luto@kernel.org> --- arch/x86/kernel/head_32.S | 6 ++++++ arch/x86/mm/setup_nx.c | 5 ++--- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index 6bc9ae24b6d2..57fc3f8c85fd 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -389,6 +389,12 @@ default_entry: /* Make changes effective */ wrmsr + /* + * And make sure that all the mappings we set up have NX set from + * the beginning. + */ + orl $(1 << (_PAGE_BIT_NX - 32)), pa(__supported_pte_mask + 4) + enable_paging: /* diff --git a/arch/x86/mm/setup_nx.c b/arch/x86/mm/setup_nx.c index 90555bf60aa4..5095ecb0719c 100644 --- a/arch/x86/mm/setup_nx.c +++ b/arch/x86/mm/setup_nx.c @@ -31,9 +31,8 @@ early_param("noexec", noexec_setup); void x86_configure_nx(void) { - if (cpu_has_nx && !disable_nx) - __supported_pte_mask |= _PAGE_NX; - else + /* If disable_nx is set, clear NX on all new mappings going forward. */ + if (disable_nx) __supported_pte_mask &= ~_PAGE_NX; } -- 2.5.0 ^ permalink raw reply related [flat|nested] 39+ messages in thread
* [PATCH 2/2] x86/mm: Make kmap_prot into a #define 2015-12-15 8:09 ` [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Andy Lutomirski 2015-12-15 8:09 ` [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling paging Andy Lutomirski @ 2015-12-15 8:09 ` Andy Lutomirski 2016-01-19 9:26 ` [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Ingo Molnar 2 siblings, 0 replies; 39+ messages in thread From: Andy Lutomirski @ 2015-12-15 8:09 UTC (permalink / raw) To: Pavel Machek, x86 Cc: Arjan van de Ven, Linus Torvalds, Borislav Petkov, linux-kernel, Stephen Smalley, Brian Gerst, Denys Vlasenko, hpa, Mike Galbraith, Peter Zijlstra, Andy Lutomirski The value (once we initialize it) is a foregone conclusion. Make it a #define to save a tiny amount of text and data size and to make it more comprehensible. Signed-off-by: Andy Lutomirski <luto@kernel.org> --- arch/x86/include/asm/fixmap.h | 2 +- arch/x86/mm/init_32.c | 3 --- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h index 32c60a02ec80..ce941b7e7900 100644 --- a/arch/x86/include/asm/fixmap.h +++ b/arch/x86/include/asm/fixmap.h @@ -142,7 +142,7 @@ extern void reserve_top_address(unsigned long reserve); extern int fixmaps_set; extern pte_t *kmap_pte; -extern pgprot_t kmap_prot; +#define kmap_prot PAGE_KERNEL extern pte_t *pkmap_page_table; void __native_set_fixmap(enum fixed_addresses idx, pte_t pte); diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c index cb4ef3de61f9..a4bb1c7ab65e 100644 --- a/arch/x86/mm/init_32.c +++ b/arch/x86/mm/init_32.c @@ -388,7 +388,6 @@ repeat: } pte_t *kmap_pte; -pgprot_t kmap_prot; static inline pte_t *kmap_get_fixmap_pte(unsigned long vaddr) { @@ -405,8 +404,6 @@ static void __init kmap_init(void) */ kmap_vstart = __fix_to_virt(FIX_KMAP_BEGIN); kmap_pte = kmap_get_fixmap_pte(kmap_vstart); - - kmap_prot = PAGE_KERNEL; } #ifdef CONFIG_HIGHMEM -- 2.5.0 ^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup 2015-12-15 8:09 ` [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Andy Lutomirski 2015-12-15 8:09 ` [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling paging Andy Lutomirski 2015-12-15 8:09 ` [PATCH 2/2] x86/mm: Make kmap_prot into a #define Andy Lutomirski @ 2016-01-19 9:26 ` Ingo Molnar 2016-01-19 19:44 ` Andy Lutomirski 2 siblings, 1 reply; 39+ messages in thread From: Ingo Molnar @ 2016-01-19 9:26 UTC (permalink / raw) To: Andy Lutomirski Cc: Pavel Machek, x86, Arjan van de Ven, Linus Torvalds, Borislav Petkov, linux-kernel, Stephen Smalley, Brian Gerst, Denys Vlasenko, hpa, Mike Galbraith, Peter Zijlstra * Andy Lutomirski <luto@kernel.org> wrote: > The fixlet might help with some WX warnings. The kmap cleanup is > just a cleanup. > > This is very lightly tested. > > Andy Lutomirski (2): > x86_32/mm: Set NX in __supported_pte_mask before enabling paging > x86/mm: Make kmap_prot into a #define > > arch/x86/include/asm/fixmap.h | 2 +- > arch/x86/kernel/head_32.S | 6 ++++++ > arch/x86/mm/init_32.c | 3 --- > arch/x86/mm/setup_nx.c | 5 ++--- > 4 files changed, 9 insertions(+), 7 deletions(-) Noticed this older submission, but the first patch does not apply anymore. Or does it have other dependencies? Thanks, Ingo ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup 2016-01-19 9:26 ` [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Ingo Molnar @ 2016-01-19 19:44 ` Andy Lutomirski 0 siblings, 0 replies; 39+ messages in thread From: Andy Lutomirski @ 2016-01-19 19:44 UTC (permalink / raw) To: Ingo Molnar Cc: Andy Lutomirski, Pavel Machek, X86 ML, Arjan van de Ven, Linus Torvalds, Borislav Petkov, linux-kernel, Stephen Smalley, Brian Gerst, Denys Vlasenko, H. Peter Anvin, Mike Galbraith, Peter Zijlstra On Tue, Jan 19, 2016 at 1:26 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * Andy Lutomirski <luto@kernel.org> wrote: > >> The fixlet might help with some WX warnings. The kmap cleanup is >> just a cleanup. >> >> This is very lightly tested. >> >> Andy Lutomirski (2): >> x86_32/mm: Set NX in __supported_pte_mask before enabling paging >> x86/mm: Make kmap_prot into a #define >> >> arch/x86/include/asm/fixmap.h | 2 +- >> arch/x86/kernel/head_32.S | 6 ++++++ >> arch/x86/mm/init_32.c | 3 --- >> arch/x86/mm/setup_nx.c | 5 ++--- >> 4 files changed, 9 insertions(+), 7 deletions(-) > > Noticed this older submission, but the first patch does not apply anymore. Or does > it have other dependencies? > It conflicts with Boris's cpu_has_xyz cleanup. I'll resend. --Andy ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 7:56 ` Pavel Machek 2015-12-15 8:09 ` [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Andy Lutomirski @ 2015-12-15 13:26 ` Arjan van de Ven 2015-12-15 14:08 ` Pavel Machek 1 sibling, 1 reply; 39+ messages in thread From: Arjan van de Ven @ 2015-12-15 13:26 UTC (permalink / raw) To: Pavel Machek Cc: Andy Lutomirski, Linus Torvalds, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On 12/14/2015 11:56 PM, Pavel Machek wrote: > On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote: >> >>> That's weird. The only API to do that seems to be manually setting >>> kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is >>> kmap_prot a variable on x86 at all? It has exactly one writer, and >>> that's the code that initializes it in the first place. Shouldn't we >>> #define kmap_prot _PAGE_KERNEL? >> >> iirc it changes based on runtime detection of NX capability > > Huh. Is it possible that core duo is so old that it has no NX? really stupid question I guess, but is PAE on ? (64 bit pagetables are required for NX) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 13:26 ` 4.4-rc5: ugly warn on: 5 W+X pages found Arjan van de Ven @ 2015-12-15 14:08 ` Pavel Machek 2015-12-15 16:28 ` H. Peter Anvin 0 siblings, 1 reply; 39+ messages in thread From: Pavel Machek @ 2015-12-15 14:08 UTC (permalink / raw) To: Arjan van de Ven Cc: Andy Lutomirski, Linus Torvalds, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Peter Anvin, Mike Galbraith, Peter Zijlstra, Thomas Gleixner [-- Attachment #1: Type: text/plain, Size: 1300 bytes --] On Tue 2015-12-15 05:26:00, Arjan van de Ven wrote: > On 12/14/2015 11:56 PM, Pavel Machek wrote: > >On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote: > >> > >>>That's weird. The only API to do that seems to be manually setting > >>>kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is > >>>kmap_prot a variable on x86 at all? It has exactly one writer, and > >>>that's the code that initializes it in the first place. Shouldn't we > >>>#define kmap_prot _PAGE_KERNEL? > >> > >>iirc it changes based on runtime detection of NX capability > > > >Huh. Is it possible that core duo is so old that it has no NX? > > really stupid question I guess, but is PAE on ? > (64 bit pagetables are required for NX) > CONFIG_X86_PAE=y pavel@duo:/data/l/linux$ cat /proc/cpuinfo | grep pae flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm dtherm But it still says: address sizes : 32 bits physical, 32 bits virtual I thought pae would be 36bit virtual? I'm attaching /proc/config.gz.. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 24398 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 14:08 ` Pavel Machek @ 2015-12-15 16:28 ` H. Peter Anvin 2015-12-15 17:45 ` Pavel Machek 0 siblings, 1 reply; 39+ messages in thread From: H. Peter Anvin @ 2015-12-15 16:28 UTC (permalink / raw) To: Pavel Machek, Arjan van de Ven Cc: Andy Lutomirski, Linus Torvalds, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Mike Galbraith, Peter Zijlstra, Thomas Gleixner On 12/15/15 06:08, Pavel Machek wrote: > > But it still says: > > address sizes : 32 bits physical, 32 bits virtual > > I thought pae would be 36bit virtual? > It should be unless the CPU reports otherwise, which your CPU probably does (a CPUID dump might be useful.) -hpa ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-15 16:28 ` H. Peter Anvin @ 2015-12-15 17:45 ` Pavel Machek 0 siblings, 0 replies; 39+ messages in thread From: Pavel Machek @ 2015-12-15 17:45 UTC (permalink / raw) To: H. Peter Anvin Cc: Arjan van de Ven, Andy Lutomirski, Linus Torvalds, Borislav Petkov, kernel list, Stephen Smalley, Brian Gerst, Denys Vlasenko, Mike Galbraith, Peter Zijlstra, Thomas Gleixner [-- Attachment #1: Type: text/plain, Size: 519 bytes --] On Tue 2015-12-15 08:28:12, H. Peter Anvin wrote: > On 12/15/15 06:08, Pavel Machek wrote: > > > > But it still says: > > > > address sizes : 32 bits physical, 32 bits virtual > > > > I thought pae would be 36bit virtual? > > > > It should be unless the CPU reports otherwise, which your CPU probably > does (a CPUID dump might be useful.) Ok, here you go :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: delme.cpuinfo --] [-- Type: text/plain, Size: 26970 bytes --] CPU 0: vendor_id = "GenuineIntel" version information (1/eax): processor type = primary processor (0) family = Intel Pentium Pro/II/III/Celeron/Core/Core 2/Atom, AMD Athlon/Duron, Cyrix M2, VIA C3 (6) model = 0xe (14) stepping id = 0x8 (8) extended family = 0x0 (0) extended model = 0x0 (0) (simple synth) = Intel Core Solo (Yonah C0) / Core Duo (Yonah C0) / Xeon Processor LV (Sossaman C0) / Celeron (Yonah C0), 65nm miscellaneous (1/ebx): process local APIC physical ID = 0x0 (0) cpu count = 0x2 (2) CLFLUSH line size = 0x8 (8) brand index = 0x0 (0) brand id = 0x00 (0): unknown feature information (1/edx): x87 FPU on chip = true virtual-8086 mode enhancement = true debugging extensions = true page size extensions = true time stamp counter = true RDMSR and WRMSR support = true physical address extensions = true machine check exception = true CMPXCHG8B inst. = true APIC on chip = true SYSENTER and SYSEXIT = true memory type range registers = true PTE global bit = true machine check architecture = true conditional move/compare instruction = true page attribute table = true page size extension = false processor serial number = false CLFLUSH instruction = true debug store = true thermal monitor and clock ctrl = true MMX Technology = true FXSAVE/FXRSTOR = true SSE extensions = true SSE2 extensions = true self snoop = true hyper-threading / multi-core supported = true therm. monitor = true IA64 = false pending break event = true feature information (1/ecx): PNI/SSE3: Prescott New Instructions = true PCLMULDQ instruction = false 64-bit debug store = false MONITOR/MWAIT = true CPL-qualified debug store = false VMX: virtual machine extensions = true SMX: safer mode extensions = false Enhanced Intel SpeedStep Technology = true thermal monitor 2 = true SSSE3 extensions = false context ID: adaptive or shared L1 data = false FMA instruction = false CMPXCHG16B instruction = false xTPR disable = true perfmon and debug = true process context identifiers = false direct cache access = false SSE4.1 extensions = false SSE4.2 extensions = false extended xAPIC support = false MOVBE instruction = false POPCNT instruction = false time stamp counter deadline = false AES instruction = false XSAVE/XSTOR states = false OS-enabled XSAVE/XSTOR = false AVX: advanced vector extensions = false F16C half-precision convert instruction = false RDRAND instruction = false hypervisor guest status = false cache and TLB information (2): 0xb0: instruction TLB: 4K, 4-way, 128 entries 0xb3: data TLB: 4K, 4-way, 128 entries 0x02: instruction TLB: 4M pages, 4-way, 2 entries 0xf0: 64 byte prefetching 0x7d: L2 cache: 2M, 8-way, sectored, 64 byte lines 0x30: L1 cache: 32K, 8-way, 64 byte lines 0x04: data TLB: 4M pages, 4-way, 8 entries 0x2c: L1 data cache: 32K, 8-way, 64 byte lines processor serial number: 0000-06E8-0000-0000-0000-0000 deterministic cache parameters (4): --- cache 0 --- cache type = data cache (1) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false extra threads sharing this cache = 0x0 (0) extra processor cores on this die = 0x1 (1) system coherency line size = 0x3f (63) physical line partitions = 0x0 (0) ways of associativity = 0x7 (7) WBINVD/INVD behavior on lower caches = true inclusive to lower caches = false complex cache indexing = false number of sets - 1 (s) = 63 --- cache 1 --- cache type = instruction cache (2) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false extra threads sharing this cache = 0x0 (0) extra processor cores on this die = 0x1 (1) system coherency line size = 0x3f (63) physical line partitions = 0x0 (0) ways of associativity = 0x7 (7) WBINVD/INVD behavior on lower caches = true inclusive to lower caches = false complex cache indexing = false number of sets - 1 (s) = 63 --- cache 2 --- cache type = unified cache (3) cache level = 0x2 (2) self-initializing cache level = true fully associative cache = false extra threads sharing this cache = 0x1 (1) extra processor cores on this die = 0x1 (1) system coherency line size = 0x3f (63) physical line partitions = 0x0 (0) ways of associativity = 0x7 (7) WBINVD/INVD behavior on lower caches = true inclusive to lower caches = false complex cache indexing = false number of sets - 1 (s) = 4095 MONITOR/MWAIT (5): smallest monitor-line size (bytes) = 0x40 (64) largest monitor-line size (bytes) = 0x40 (64) enum of Monitor-MWAIT exts supported = true supports intrs as break-event for MWAIT = true number of C0 sub C-states using MWAIT = 0x0 (0) number of C1 sub C-states using MWAIT = 0x2 (2) number of C2 sub C-states using MWAIT = 0x2 (2) number of C3 sub C-states using MWAIT = 0x2 (2) number of C4 sub C-states using MWAIT = 0x2 (2) number of C5 sub C-states using MWAIT = 0x0 (0) number of C6 sub C-states using MWAIT = 0x0 (0) number of C7 sub C-states using MWAIT = 0x0 (0) Thermal and Power Management Features (6): digital thermometer = true Intel Turbo Boost Technology = false ARAT always running APIC timer = false PLN power limit notification = false ECMD extended clock modulation duty = false PTM package thermal management = false digital thermometer thresholds = 0x2 (2) ACNT/MCNT supported performance measure = true ACNT2 available = false performance-energy bias capability = false extended feature flags (7): FSGSBASE instructions = false IA32_TSC_ADJUST MSR supported = false BMI instruction = false HLE hardware lock elision = false AVX2: advanced vector extensions 2 = false SMEP supervisor mode exec protection = false BMI2 instructions = false enhanced REP MOVSB/STOSB = false INVPCID instruction = false RTM: restricted transactional memory = false QM: quality of service monitoring = false deprecated FPU CS/DS = false intel memory protection extensions = false AVX512F: AVX-512 foundation instructions = false RDSEED instruction = false ADX instructions = false SMAP: supervisor mode access prevention = false Intel processor trace = false AVX512PF: prefetch instructions = false AVX512ER: exponent & reciprocal instrs = false AVX512CD: conflict detection instrs = false SHA instructions = false PREFETCHWT1 = false Direct Cache Access Parameters (9): PLATFORM_DCA_CAP MSR bits = 0 Architecture Performance Monitoring Features (0xa/eax): version ID = 0x1 (1) number of counters per logical processor = 0x2 (2) bit width of counter = 0x28 (40) length of EBX bit vector = 0x7 (7) Architecture Performance Monitoring Features (0xa/ebx): core cycle event not available = false instruction retired event not available = false reference cycles event not available = false last-level cache ref event not available = false last-level cache miss event not avail = false branch inst retired event not available = false branch mispred retired event not avail = false Architecture Performance Monitoring Features (0xa/edx): number of fixed counters = 0x0 (0) bit width of fixed counters = 0x0 (0) extended feature flags (0x80000001/edx): SYSCALL and SYSRET instructions = false execution disable = true 1-GB large page support = false RDTSCP = false 64-bit extensions technology available = false Intel feature flags (0x80000001/ecx): LAHF/SAHF supported in 64-bit mode = false LZCNT advanced bit manipulation = false 3DNow! PREFETCH/PREFETCHW instructions = false brand = "Genuine Intel(R) CPU T2400 @ 1.83GHz" L1 TLB/cache information: 2M/4M pages & L1 TLB (0x80000005/eax): instruction # entries = 0x0 (0) instruction associativity = 0x0 (0) data # entries = 0x0 (0) data associativity = 0x0 (0) L1 TLB/cache information: 4K pages & L1 TLB (0x80000005/ebx): instruction # entries = 0x0 (0) instruction associativity = 0x0 (0) data # entries = 0x0 (0) data associativity = 0x0 (0) L1 data cache information (0x80000005/ecx): line size (bytes) = 0x0 (0) lines per tag = 0x0 (0) associativity = 0x0 (0) size (Kb) = 0x0 (0) L1 instruction cache information (0x80000005/edx): line size (bytes) = 0x0 (0) lines per tag = 0x0 (0) associativity = 0x0 (0) size (Kb) = 0x0 (0) L2 TLB/cache information: 2M/4M pages & L2 TLB (0x80000006/eax): instruction # entries = 0x0 (0) instruction associativity = L2 off (0) data # entries = 0x0 (0) data associativity = L2 off (0) L2 TLB/cache information: 4K pages & L2 TLB (0x80000006/ebx): instruction # entries = 0x0 (0) instruction associativity = L2 off (0) data # entries = 0x0 (0) data associativity = L2 off (0) L2 unified cache information (0x80000006/ecx): line size (bytes) = 0x40 (64) lines per tag = 0x0 (0) associativity = 8-way (6) size (Kb) = 0x800 (2048) L3 cache information (0x80000006/edx): line size (bytes) = 0x0 (0) lines per tag = 0x0 (0) associativity = L2 off (0) size (in 512Kb units) = 0x0 (0) Advanced Power Management Features (0x80000007/edx): temperature sensing diode = false frequency ID (FID) control = false voltage ID (VID) control = false thermal trip (TTP) = false thermal monitor (TM) = false software thermal control (STC) = false 100 MHz multiplier control = false hardware P-State control = false TscInvariant = false Physical Address and Linear Address Size (0x80000008/eax): maximum physical address bits = 0x20 (32) maximum linear (virtual) address bits = 0x20 (32) maximum guest physical address bits = 0x0 (0) Logical CPU cores (0x80000008/ecx): number of CPU cores - 1 = 0x0 (0) ApicIdCoreIdSize = 0x0 (0) (multi-processing synth): multi-core (c=2) (multi-processing method): Intel leaf 1/4 (APIC widths synth): CORE_width=1 SMT_width=0 (APIC synth): PKG_ID=0 CORE_ID=0 SMT_ID=0 (synth) = Intel Core Duo (Yonah C0), 65nm CPU 1: vendor_id = "GenuineIntel" version information (1/eax): processor type = primary processor (0) family = Intel Pentium Pro/II/III/Celeron/Core/Core 2/Atom, AMD Athlon/Duron, Cyrix M2, VIA C3 (6) model = 0xe (14) stepping id = 0x8 (8) extended family = 0x0 (0) extended model = 0x0 (0) (simple synth) = Intel Core Solo (Yonah C0) / Core Duo (Yonah C0) / Xeon Processor LV (Sossaman C0) / Celeron (Yonah C0), 65nm miscellaneous (1/ebx): process local APIC physical ID = 0x1 (1) cpu count = 0x2 (2) CLFLUSH line size = 0x8 (8) brand index = 0x0 (0) brand id = 0x00 (0): unknown feature information (1/edx): x87 FPU on chip = true virtual-8086 mode enhancement = true debugging extensions = true page size extensions = true time stamp counter = true RDMSR and WRMSR support = true physical address extensions = true machine check exception = true CMPXCHG8B inst. = true APIC on chip = true SYSENTER and SYSEXIT = true memory type range registers = true PTE global bit = true machine check architecture = true conditional move/compare instruction = true page attribute table = true page size extension = false processor serial number = false CLFLUSH instruction = true debug store = true thermal monitor and clock ctrl = true MMX Technology = true FXSAVE/FXRSTOR = true SSE extensions = true SSE2 extensions = true self snoop = true hyper-threading / multi-core supported = true therm. monitor = true IA64 = false pending break event = true feature information (1/ecx): PNI/SSE3: Prescott New Instructions = true PCLMULDQ instruction = false 64-bit debug store = false MONITOR/MWAIT = true CPL-qualified debug store = false VMX: virtual machine extensions = true SMX: safer mode extensions = false Enhanced Intel SpeedStep Technology = true thermal monitor 2 = true SSSE3 extensions = false context ID: adaptive or shared L1 data = false FMA instruction = false CMPXCHG16B instruction = false xTPR disable = true perfmon and debug = true process context identifiers = false direct cache access = false SSE4.1 extensions = false SSE4.2 extensions = false extended xAPIC support = false MOVBE instruction = false POPCNT instruction = false time stamp counter deadline = false AES instruction = false XSAVE/XSTOR states = false OS-enabled XSAVE/XSTOR = false AVX: advanced vector extensions = false F16C half-precision convert instruction = false RDRAND instruction = false hypervisor guest status = false cache and TLB information (2): 0xb0: instruction TLB: 4K, 4-way, 128 entries 0xb3: data TLB: 4K, 4-way, 128 entries 0x02: instruction TLB: 4M pages, 4-way, 2 entries 0xf0: 64 byte prefetching 0x7d: L2 cache: 2M, 8-way, sectored, 64 byte lines 0x30: L1 cache: 32K, 8-way, 64 byte lines 0x04: data TLB: 4M pages, 4-way, 8 entries 0x2c: L1 data cache: 32K, 8-way, 64 byte lines processor serial number: 0000-06E8-0000-0000-0000-0000 deterministic cache parameters (4): --- cache 0 --- cache type = data cache (1) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false extra threads sharing this cache = 0x0 (0) extra processor cores on this die = 0x1 (1) system coherency line size = 0x3f (63) physical line partitions = 0x0 (0) ways of associativity = 0x7 (7) WBINVD/INVD behavior on lower caches = true inclusive to lower caches = false complex cache indexing = false number of sets - 1 (s) = 63 --- cache 1 --- cache type = instruction cache (2) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false extra threads sharing this cache = 0x0 (0) extra processor cores on this die = 0x1 (1) system coherency line size = 0x3f (63) physical line partitions = 0x0 (0) ways of associativity = 0x7 (7) WBINVD/INVD behavior on lower caches = true inclusive to lower caches = false complex cache indexing = false number of sets - 1 (s) = 63 --- cache 2 --- cache type = unified cache (3) cache level = 0x2 (2) self-initializing cache level = true fully associative cache = false extra threads sharing this cache = 0x1 (1) extra processor cores on this die = 0x1 (1) system coherency line size = 0x3f (63) physical line partitions = 0x0 (0) ways of associativity = 0x7 (7) WBINVD/INVD behavior on lower caches = true inclusive to lower caches = false complex cache indexing = false number of sets - 1 (s) = 4095 MONITOR/MWAIT (5): smallest monitor-line size (bytes) = 0x40 (64) largest monitor-line size (bytes) = 0x40 (64) enum of Monitor-MWAIT exts supported = true supports intrs as break-event for MWAIT = true number of C0 sub C-states using MWAIT = 0x0 (0) number of C1 sub C-states using MWAIT = 0x2 (2) number of C2 sub C-states using MWAIT = 0x2 (2) number of C3 sub C-states using MWAIT = 0x2 (2) number of C4 sub C-states using MWAIT = 0x2 (2) number of C5 sub C-states using MWAIT = 0x0 (0) number of C6 sub C-states using MWAIT = 0x0 (0) number of C7 sub C-states using MWAIT = 0x0 (0) Thermal and Power Management Features (6): digital thermometer = true Intel Turbo Boost Technology = false ARAT always running APIC timer = false PLN power limit notification = false ECMD extended clock modulation duty = false PTM package thermal management = false digital thermometer thresholds = 0x2 (2) ACNT/MCNT supported performance measure = true ACNT2 available = false performance-energy bias capability = false extended feature flags (7): FSGSBASE instructions = false IA32_TSC_ADJUST MSR supported = false BMI instruction = false HLE hardware lock elision = false AVX2: advanced vector extensions 2 = false SMEP supervisor mode exec protection = false BMI2 instructions = false enhanced REP MOVSB/STOSB = false INVPCID instruction = false RTM: restricted transactional memory = false QM: quality of service monitoring = false deprecated FPU CS/DS = false intel memory protection extensions = false AVX512F: AVX-512 foundation instructions = false RDSEED instruction = false ADX instructions = false SMAP: supervisor mode access prevention = false Intel processor trace = false AVX512PF: prefetch instructions = false AVX512ER: exponent & reciprocal instrs = false AVX512CD: conflict detection instrs = false SHA instructions = false PREFETCHWT1 = false Direct Cache Access Parameters (9): PLATFORM_DCA_CAP MSR bits = 0 Architecture Performance Monitoring Features (0xa/eax): version ID = 0x1 (1) number of counters per logical processor = 0x2 (2) bit width of counter = 0x28 (40) length of EBX bit vector = 0x7 (7) Architecture Performance Monitoring Features (0xa/ebx): core cycle event not available = false instruction retired event not available = false reference cycles event not available = false last-level cache ref event not available = false last-level cache miss event not avail = false branch inst retired event not available = false branch mispred retired event not avail = false Architecture Performance Monitoring Features (0xa/edx): number of fixed counters = 0x0 (0) bit width of fixed counters = 0x0 (0) extended feature flags (0x80000001/edx): SYSCALL and SYSRET instructions = false execution disable = true 1-GB large page support = false RDTSCP = false 64-bit extensions technology available = false Intel feature flags (0x80000001/ecx): LAHF/SAHF supported in 64-bit mode = false LZCNT advanced bit manipulation = false 3DNow! PREFETCH/PREFETCHW instructions = false brand = "Genuine Intel(R) CPU T2400 @ 1.83GHz" L1 TLB/cache information: 2M/4M pages & L1 TLB (0x80000005/eax): instruction # entries = 0x0 (0) instruction associativity = 0x0 (0) data # entries = 0x0 (0) data associativity = 0x0 (0) L1 TLB/cache information: 4K pages & L1 TLB (0x80000005/ebx): instruction # entries = 0x0 (0) instruction associativity = 0x0 (0) data # entries = 0x0 (0) data associativity = 0x0 (0) L1 data cache information (0x80000005/ecx): line size (bytes) = 0x0 (0) lines per tag = 0x0 (0) associativity = 0x0 (0) size (Kb) = 0x0 (0) L1 instruction cache information (0x80000005/edx): line size (bytes) = 0x0 (0) lines per tag = 0x0 (0) associativity = 0x0 (0) size (Kb) = 0x0 (0) L2 TLB/cache information: 2M/4M pages & L2 TLB (0x80000006/eax): instruction # entries = 0x0 (0) instruction associativity = L2 off (0) data # entries = 0x0 (0) data associativity = L2 off (0) L2 TLB/cache information: 4K pages & L2 TLB (0x80000006/ebx): instruction # entries = 0x0 (0) instruction associativity = L2 off (0) data # entries = 0x0 (0) data associativity = L2 off (0) L2 unified cache information (0x80000006/ecx): line size (bytes) = 0x40 (64) lines per tag = 0x0 (0) associativity = 8-way (6) size (Kb) = 0x800 (2048) L3 cache information (0x80000006/edx): line size (bytes) = 0x0 (0) lines per tag = 0x0 (0) associativity = L2 off (0) size (in 512Kb units) = 0x0 (0) Advanced Power Management Features (0x80000007/edx): temperature sensing diode = false frequency ID (FID) control = false voltage ID (VID) control = false thermal trip (TTP) = false thermal monitor (TM) = false software thermal control (STC) = false 100 MHz multiplier control = false hardware P-State control = false TscInvariant = false Physical Address and Linear Address Size (0x80000008/eax): maximum physical address bits = 0x20 (32) maximum linear (virtual) address bits = 0x20 (32) maximum guest physical address bits = 0x0 (0) Logical CPU cores (0x80000008/ecx): number of CPU cores - 1 = 0x0 (0) ApicIdCoreIdSize = 0x0 (0) (multi-processing synth): multi-core (c=2) (multi-processing method): Intel leaf 1/4 (APIC widths synth): CORE_width=1 SMT_width=0 (APIC synth): PKG_ID=0 CORE_ID=1 SMT_ID=0 (synth) = Intel Core Duo (Yonah C0), 65nm [-- Attachment #3: cpuinfo --] [-- Type: text/plain, Size: 1448 bytes --] processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU T2400 @ 1.83GHz stepping : 8 microcode : 0x39 cpu MHz : 1833.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm dtherm bugs : bogomips : 3657.43 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU T2400 @ 1.83GHz stepping : 8 microcode : 0x39 cpu MHz : 1000.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm dtherm bugs : bogomips : 3657.43 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management: ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: 4.4-rc5: ugly warn on: 5 W+X pages found 2015-12-14 8:04 ` 4.4-rc5: ugly warn on: " Pavel Machek 2015-12-14 8:58 ` Borislav Petkov @ 2015-12-14 12:29 ` Pavel Machek 1 sibling, 0 replies; 39+ messages in thread From: Pavel Machek @ 2015-12-14 12:29 UTC (permalink / raw) To: kernel list, sds, luto, arjan, bp, brgerst, dvlasenk, hpa, torvalds, efault, peterz, tglx On Mon 2015-12-14 09:04:03, Pavel Machek wrote: > Hi! > > > Kernel complains: > > And now, we are at -rc5, and kernel still complains... > > ...with a back trace, which is clearly completely useless, and just > there to make it scary and make people report. > > Problem is... noone cares for the reports. (-rc0 version below). > > Can we get rid of that WARN_ON? If you do care about reports, please > add email address those can be reported to. If you don't... just drop > it. > > Hardware is thinkpad x60. > [ 3.285993] x86/mm: Found insecure W+X mapping at address > ffe69000/0xffe69000 ---[ Persisent kmap() Area ]--- 0xffc00000-0xffd28000 1184K pte 0xffd28000-0xffddd000 724K RW GLB NX pte 0xffddd000-0xffe69000 560K pte 0xffe69000-0xffe6e000 20K RW GLB x pte 0xffe6e000-0xffe6f000 4K pte ---[ Fixmap Area ]--- Any other info that would be useful? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2016-01-19 19:45 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-15 7:00 4.4-rc0: 5 W+X pages found Pavel Machek 2015-11-23 14:37 ` Mihai Donțu 2015-12-08 21:19 ` Kees Cook 2015-12-09 0:10 ` Dave Jones 2015-12-09 19:33 ` Mihai Donțu 2015-12-14 8:04 ` 4.4-rc5: ugly warn on: " Pavel Machek 2015-12-14 8:58 ` Borislav Petkov 2015-12-14 9:07 ` Pavel Machek 2015-12-14 9:15 ` Borislav Petkov 2015-12-14 19:18 ` Linus Torvalds 2015-12-14 20:26 ` Pavel Machek 2015-12-14 21:02 ` Andy Lutomirski 2015-12-14 21:24 ` Arjan van de Ven 2015-12-14 22:25 ` Andy Lutomirski 2015-12-15 9:40 ` Pavel Machek 2015-12-15 17:45 ` Linus Torvalds 2015-12-15 18:30 ` Borislav Petkov 2015-12-15 19:06 ` Linus Torvalds 2015-12-15 19:15 ` Borislav Petkov 2015-12-15 18:40 ` Andy Lutomirski 2015-12-15 19:08 ` Linus Torvalds 2015-12-15 20:58 ` Pavel Machek 2015-12-15 21:12 ` 4.4.-rc5: lguest causes " Pavel Machek 2015-12-16 2:24 ` Rusty Russell 2015-12-16 8:10 ` Pavel Machek 2015-12-15 21:33 ` 4.4-rc5: " Borislav Petkov 2015-12-15 22:07 ` Pavel Machek 2015-12-15 22:15 ` Borislav Petkov 2015-12-15 7:56 ` Pavel Machek 2015-12-15 8:09 ` [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Andy Lutomirski 2015-12-15 8:09 ` [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling paging Andy Lutomirski 2015-12-15 8:09 ` [PATCH 2/2] x86/mm: Make kmap_prot into a #define Andy Lutomirski 2016-01-19 9:26 ` [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Ingo Molnar 2016-01-19 19:44 ` Andy Lutomirski 2015-12-15 13:26 ` 4.4-rc5: ugly warn on: 5 W+X pages found Arjan van de Ven 2015-12-15 14:08 ` Pavel Machek 2015-12-15 16:28 ` H. Peter Anvin 2015-12-15 17:45 ` Pavel Machek 2015-12-14 12:29 ` Pavel Machek
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.