* 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 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
* 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 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: 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 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-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 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: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 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 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 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: 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: 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: [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
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.