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

Groups > linux.kernel > #1240213 > unrolled thread

Re: [PATCH v2] x86/mm: warn on W+x mappings

Started byIngo Molnar <mingo@kernel.org>
First post2015-10-06 09:40 +0200
Last post2015-10-14 18:50 +0200
Articles 20 on this page of 21 — 8 participants

Back to article view | Back to linux.kernel

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

Contents

  Re: [PATCH v2] x86/mm: warn on W+x mappings Ingo Molnar <mingo@kernel.org> - 2015-10-06 09:40 +0200
    Re: [PATCH v2] x86/mm: warn on W+x mappings Stephen Smalley <sds@tycho.nsa.gov> - 2015-10-06 17:50 +0200
      Re: [PATCH v2] x86/mm: warn on W+x mappings Borislav Petkov <bp@alien8.de> - 2015-10-12 13:40 +0200
        Re: [PATCH v2] x86/mm: warn on W+x mappings Matt Fleming <matt@codeblueprint.co.uk> - 2015-10-12 14:50 +0200
          Re: [PATCH v2] x86/mm: warn on W+x mappings Ingo Molnar <mingo@kernel.org> - 2015-10-12 14:50 +0200
            Re: [PATCH v2] x86/mm: warn on W+x mappings Matt Fleming <matt@codeblueprint.co.uk> - 2015-10-12 15:00 +0200
              Re: [PATCH v2] x86/mm: warn on W+x mappings Ingo Molnar <mingo@kernel.org> - 2015-10-12 16:20 +0200
                Re: [PATCH v2] x86/mm: warn on W+x mappings Matt Fleming <matt@codeblueprint.co.uk> - 2015-10-12 16:50 +0200
                  Re: [PATCH v2] x86/mm: warn on W+x mappings Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-10-12 17:40 +0200
                    Re: [PATCH v2] x86/mm: warn on W+x mappings Matt Fleming <matt@codeblueprint.co.uk> - 2015-10-12 18:00 +0200
                      Re: [PATCH v2] x86/mm: warn on W+x mappings Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-10-12 18:50 +0200
                  Re: [PATCH v2] x86/mm: warn on W+x mappings Ingo Molnar <mingo@kernel.org> - 2015-10-14 17:20 +0200
                    Re: [PATCH v2] x86/mm: warn on W+x mappings Borislav Petkov <bp@alien8.de> - 2015-10-14 17:40 +0200
                      Re: [PATCH v2] x86/mm: warn on W+x mappings Matt Fleming <matt@codeblueprint.co.uk> - 2015-10-15 12:20 +0200
                        Re: [PATCH v2] x86/mm: warn on W+x mappings Borislav Petkov <bp@alien8.de> - 2015-10-15 12:40 +0200
                          Re: [PATCH v2] x86/mm: warn on W+x mappings Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2015-10-16 03:50 +0200
                    Re: [PATCH v2] x86/mm: warn on W+x mappings Andy Lutomirski <luto@amacapital.net> - 2015-10-14 17:40 +0200
                    Re: [PATCH v2] x86/mm: warn on W+x mappings Matt Fleming <matt@codeblueprint.co.uk> - 2015-10-14 23:10 +0200
                Re: [PATCH v2] x86/mm: warn on W+x mappings Josh Triplett <josh@joshtriplett.org> - 2015-10-12 17:00 +0200
                  Re: [PATCH v2] x86/mm: warn on W+x mappings Ingo Molnar <mingo@kernel.org> - 2015-10-14 17:30 +0200
                    Re: [PATCH v2] x86/mm: warn on W+x mappings Josh Triplett <josh@joshtriplett.org> - 2015-10-14 18:50 +0200

Page 1 of 2  [1] 2  Next page →

#1240213 — Re: [PATCH v2] x86/mm: warn on W+x mappings

FromIngo Molnar <mingo@kernel.org>
Date2015-10-06 09:40 +0200
SubjectRe: [PATCH v2] x86/mm: warn on W+x mappings
Message-ID<qgv0S-7Vp-21@gated-at.bofh.it>
* Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On 10/03/2015 07:27 AM, Ingo Molnar wrote:
> > 
> > * Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > 
> >> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> >> index 30564e2..f8b1573 100644
> >> --- a/arch/x86/mm/init_64.c
> >> +++ b/arch/x86/mm/init_64.c
> >> @@ -1150,6 +1150,8 @@ void mark_rodata_ro(void)
> >>  	free_init_pages("unused kernel",
> >>  			(unsigned long) __va(__pa_symbol(rodata_end)),
> >>  			(unsigned long) __va(__pa_symbol(_sdata)));
> >> +
> >> +	debug_checkwx();
> > 
> > Any reason to not do this on NX capable 32-bit kernels as well?
> 
> Done in v3.  However, I do see lots of W+X mappings there.

Ha! That's a debug check plan gone very well! :)

> [    1.012796] WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x65d/0x840()
> [    1.012803] x86/mm: Found insecure W+X mapping at address f4a00000/0xf4a00000

What does this range correspond to on your kernel?

Thanks,

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

[toc] | [next] | [standalone]

#1240613

FromStephen Smalley <sds@tycho.nsa.gov>
Date2015-10-06 17:50 +0200
Message-ID<qgCF5-20n-31@gated-at.bofh.it>
In reply to#1240213
On 10/06/2015 03:32 AM, Ingo Molnar wrote:
> 
> * Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
>> On 10/03/2015 07:27 AM, Ingo Molnar wrote:
>>>
>>> * Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>
>>>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
>>>> index 30564e2..f8b1573 100644
>>>> --- a/arch/x86/mm/init_64.c
>>>> +++ b/arch/x86/mm/init_64.c
>>>> @@ -1150,6 +1150,8 @@ void mark_rodata_ro(void)
>>>>  	free_init_pages("unused kernel",
>>>>  			(unsigned long) __va(__pa_symbol(rodata_end)),
>>>>  			(unsigned long) __va(__pa_symbol(_sdata)));
>>>> +
>>>> +	debug_checkwx();
>>>
>>> Any reason to not do this on NX capable 32-bit kernels as well?
>>
>> Done in v3.  However, I do see lots of W+X mappings there.
> 
> Ha! That's a debug check plan gone very well! :)
> 
>> [    1.012796] WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x65d/0x840()
>> [    1.012803] x86/mm: Found insecure W+X mapping at address f4a00000/0xf4a00000
> 
> What does this range correspond to on your kernel?

From dmesg:
[    0.000000] virtual kernel memory layout:
                   fixmap  : 0xffa96000 - 0xfffff000   (5540 kB)
                   pkmap   : 0xff800000 - 0xffa00000   (2048 kB)
                   vmalloc : 0xf7ffe000 - 0xff7fe000   ( 120 MB)
                   lowmem  : 0xc0000000 - 0xf77fe000   ( 887 MB)
                     .init : 0xc0dde000 - 0xc0e9d000   ( 764 kB)
                     .data : 0xc0aa2ba0 - 0xc0ddca00   (3303 kB)
                     .text : 0xc0400000 - 0xc0aa2ba0   (6794 kB)

/sys/kernel/debug/kernel_page_tables seems to have many such mappings,
even before the reported one under Kernel Mapping, plus one in the vmalloc() area:

---[ Kernel Mapping ]---
0xc0000000-0xc009b000         620K     RW                 GLB NX pte
0xc009b000-0xc009c000           4K     ro                 GLB NX pte
0xc009c000-0xc009d000           4K     ro                 GLB x  pte
0xc009d000-0xc0200000        1420K     RW                 GLB NX pte
0xc0200000-0xc0400000           2M     RW         PSE     GLB NX pmd
0xc0400000-0xc0a00000           6M     ro         PSE     GLB x  pmd
0xc0a00000-0xc0aa3000         652K     ro                 GLB x  pte
0xc0aa3000-0xc0d2a000        2588K     ro                 GLB NX pte
0xc0d2a000-0xc1000000        2904K     RW                 GLB NX pte
0xc1000000-0xe7000000         608M     RW         PSE     GLB NX pmd
0xe7000000-0xe7027000         156K     RW                 GLB x  pte
0xe7027000-0xe7028000           4K     ro                 GLB x  pte
0xe7028000-0xe709b000         460K     RW                 GLB x  pte
0xe709b000-0xe709c000           4K     ro                 GLB x  pte
0xe709c000-0xe70b8000         112K     RW                 GLB x  pte
0xe70b8000-0xe70b9000           4K     ro                 GLB x  pte
0xe70b9000-0xe7108000         316K     RW                 GLB x  pte
0xe7108000-0xe710a000           8K     ro                 GLB x  pte
0xe710a000-0xe7127000         116K     RW                 GLB x  pte
0xe7127000-0xe712a000          12K     ro                 GLB x  pte
<many additional ones elided>
0xf2c5c000-0xf2c5d000           4K     ro                 GLB x  pte
0xf2c5d000-0xf2e00000        1676K     RW                 GLB x  pte
0xf2e00000-0xf4a00000          28M     RW         PSE     GLB NX pmd
0xf4a00000-0xf4b28000        1184K     RW                 GLB x  pte
0xf4b28000-0xf4c00000         864K     RW                 GLB NX pte
0xf4c00000-0xf5200000           6M     RW         PSE     GLB x  pmd
0xf5200000-0xf525d000         372K     RW                 GLB x  pte
0xf525d000-0xf525e000           4K     ro                 GLB x  pte
0xf525e000-0xf525f000           4K     RW                 GLB x  pte
0xf525f000-0xf5260000           4K     ro                 GLB x  pte
0xf5260000-0xf526a000          40K     RW                 GLB x  pte
0xf6400000-0xf658c000        1584K     RW                 GLB NX pte
0xf658c000-0xf6600000         464K     RW                 GLB x  pte
0xf6600000-0xf7600000          16M     RW         PSE     GLB NX pmd
0xf7600000-0xf77fe000        2040K     RW                 GLB NX pte
0xf77fe000-0xf7800000           8K                               pte
0xf7800000-0xf7e00000           6M                               pmd
0xf7e00000-0xf7ffe000        2040K                               pte
---[ vmalloc() Area ]---
0xf7ffe000-0xf7fff000           4K     RW                 GLB NX pte
0xf7fff000-0xf8000000           4K                               pte
0xf8000000-0xf8002000           8K     RW                 GLB NX pte
...
0xf86f3000-0xf8800000        1076K                               pte
0xf8800000-0xf8a00000           2M     RW PWT     PSE     GLB x  pmd
0xf8a00000-0xf8b00000           1M     RW PWT             GLB NX pte

$ grep -c 'RW.*x' kernel_page_tables 
114

There was also an earlier W+X mapping originally that I squelched via pci=nobios.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1244611

FromBorislav Petkov <bp@alien8.de>
Date2015-10-12 13:40 +0200
Message-ID<qiJCq-64x-1@gated-at.bofh.it>
In reply to#1240613
On Tue, Oct 06, 2015 at 11:37:57AM -0400, Stephen Smalley wrote:
> > What does this range correspond to on your kernel?

Got a W+X splat here too, on the UEFI box with rc5+tip/master:

[    6.792949] rtc_cmos 00:02: setting system clock to 2015-10-12 11:17:03 UTC (1444648623)
[    6.807863] Freeing unused kernel memory: 1312K (ffffffff81f5f000 - ffffffff820a7000)
[    6.815831] usb 3-1: new high-speed USB device number 2 using ehci-pci
[    6.823261] Write protecting the kernel read-only data: 14336k
[    6.832196] Freeing unused kernel memory: 1796K (ffff88000383f000 - ffff880003a00000)
[    6.842210] Freeing unused kernel memory: 284K (ffff880003db9000 - ffff880003e00000)
[    6.850524] ------------[ cut here ]------------
[    6.855682] WARNING: CPU: 5 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x61e/0x7e0()
[    6.864944] x86/mm: Found insecure W+X mapping at address ffff88000005e000/0xffff88000005e000
[    6.874022] Modules linked in:
[    6.877643] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.3.0-rc5+ #1
[    6.884462] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A13 05/11/2014
[    6.892416]  ffffffff81caf1f7 ffff88043bdffd60 ffffffff813aab2c ffff88043bdffda8
[    6.900460]  ffff88043bdffd98 ffffffff81066776 ffff880004e55308 0000000000000004
[    6.907816] usb 4-1: new high-speed USB device number 2 using ehci-pci
[    6.915499]  8000000000000163 ffff88043bdffe98 0000000000000000 ffff88043bdffdf8
[    6.923520] Call Trace:
[    6.926512]  [<ffffffff813aab2c>] dump_stack+0x4e/0x82
[    6.931551] usb 3-1: New USB device found, idVendor=8087, idProduct=0024
[    6.931552] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    6.933120] hub 3-1:1.0: USB hub found
[    6.933369] hub 3-1:1.0: 6 ports detected
[    6.955784]  [<ffffffff81066776>] warn_slowpath_common+0x86/0xc0
[    6.962341]  [<ffffffff810667fc>] warn_slowpath_fmt+0x4c/0x50
[    6.968631]  [<ffffffff8105bb7e>] note_page+0x61e/0x7e0
[    6.974404]  [<ffffffff8105c09f>] ptdump_walk_pgd_level_core+0x35f/0x3f0
[    6.981651]  [<ffffffff8105c1d7>] ptdump_walk_pgd_level_checkwx+0x17/0x20
[    6.988996]  [<ffffffff81051b0e>] mark_rodata_ro+0xee/0x100
[    6.995124]  [<ffffffff81828610>] ? rest_init+0x140/0x140
[    7.001064]  [<ffffffff8182862d>] kernel_init+0x1d/0xe0
[    7.006841]  [<ffffffff81836f6f>] ret_from_fork+0x3f/0x70
[    7.012774]  [<ffffffff81828610>] ? rest_init+0x140/0x140
[    7.018706] ---[ end trace 920055014e07ef1e ]---
[    7.024302] x86/mm: Checked W+X mappings: FAILED, 69568 W+X pages found.

And yes, there are a bunch of those mappings here too:

$ grep -c 'RW.*x' /sys/kernel/debug/kernel_page_tables
75

Some of them are the UEFI runtime regions. I guess we can try to map
them as RO maybe, they need to be X. Matt, any reasons against that?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1244657

FromMatt Fleming <matt@codeblueprint.co.uk>
Date2015-10-12 14:50 +0200
Message-ID<qiKIa-7EQ-21@gated-at.bofh.it>
In reply to#1244611
On Mon, 12 Oct, at 01:36:05PM, Borislav Petkov wrote:
> On Tue, Oct 06, 2015 at 11:37:57AM -0400, Stephen Smalley wrote:
> > > What does this range correspond to on your kernel?
> 
> Got a W+X splat here too, on the UEFI box with rc5+tip/master:
> 
> [    6.792949] rtc_cmos 00:02: setting system clock to 2015-10-12 11:17:03 UTC (1444648623)
> [    6.807863] Freeing unused kernel memory: 1312K (ffffffff81f5f000 - ffffffff820a7000)
> [    6.815831] usb 3-1: new high-speed USB device number 2 using ehci-pci
> [    6.823261] Write protecting the kernel read-only data: 14336k
> [    6.832196] Freeing unused kernel memory: 1796K (ffff88000383f000 - ffff880003a00000)
> [    6.842210] Freeing unused kernel memory: 284K (ffff880003db9000 - ffff880003e00000)
> [    6.850524] ------------[ cut here ]------------
> [    6.855682] WARNING: CPU: 5 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x61e/0x7e0()
> [    6.864944] x86/mm: Found insecure W+X mapping at address ffff88000005e000/0xffff88000005e000
> [    6.874022] Modules linked in:
> [    6.877643] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.3.0-rc5+ #1
> [    6.884462] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A13 05/11/2014
> [    6.892416]  ffffffff81caf1f7 ffff88043bdffd60 ffffffff813aab2c ffff88043bdffda8
> [    6.900460]  ffff88043bdffd98 ffffffff81066776 ffff880004e55308 0000000000000004
> [    6.907816] usb 4-1: new high-speed USB device number 2 using ehci-pci
> [    6.915499]  8000000000000163 ffff88043bdffe98 0000000000000000 ffff88043bdffdf8
> [    6.923520] Call Trace:
> [    6.926512]  [<ffffffff813aab2c>] dump_stack+0x4e/0x82
> [    6.931551] usb 3-1: New USB device found, idVendor=8087, idProduct=0024
> [    6.931552] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> [    6.933120] hub 3-1:1.0: USB hub found
> [    6.933369] hub 3-1:1.0: 6 ports detected
> [    6.955784]  [<ffffffff81066776>] warn_slowpath_common+0x86/0xc0
> [    6.962341]  [<ffffffff810667fc>] warn_slowpath_fmt+0x4c/0x50
> [    6.968631]  [<ffffffff8105bb7e>] note_page+0x61e/0x7e0
> [    6.974404]  [<ffffffff8105c09f>] ptdump_walk_pgd_level_core+0x35f/0x3f0
> [    6.981651]  [<ffffffff8105c1d7>] ptdump_walk_pgd_level_checkwx+0x17/0x20
> [    6.988996]  [<ffffffff81051b0e>] mark_rodata_ro+0xee/0x100
> [    6.995124]  [<ffffffff81828610>] ? rest_init+0x140/0x140
> [    7.001064]  [<ffffffff8182862d>] kernel_init+0x1d/0xe0
> [    7.006841]  [<ffffffff81836f6f>] ret_from_fork+0x3f/0x70
> [    7.012774]  [<ffffffff81828610>] ? rest_init+0x140/0x140
> [    7.018706] ---[ end trace 920055014e07ef1e ]---
> [    7.024302] x86/mm: Checked W+X mappings: FAILED, 69568 W+X pages found.
> 
> And yes, there are a bunch of those mappings here too:
> 
> $ grep -c 'RW.*x' /sys/kernel/debug/kernel_page_tables
> 75
> 
> Some of them are the UEFI runtime regions. I guess we can try to map
> them as RO maybe, they need to be X. Matt, any reasons against that?

I'm glad you asked (but you won't be)!

Basically, it's guaranteed that there exist some machines that contain
data in EfiRuntimeCode regions (and so require write permission) and
code in EfiRuntimeData regions (and therefore require eXecute),
because the whole point of the new EFI_PROPERTIES_TABLE feature in
UEFI v2.5 was to make it explicit when the firmware does not include
such regions.

I do have patches sitting in a git branch that begin to implement
support for mapping EFI runtime data regions as NX, and code regions
as RO when EFI_PROPERTIES_TABLE is enabled,

  https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=memmap

Things got stalled when we realised that Linux didn't even boot with
the feature enabled, see commit a5caa209ba9c ("x86/efi: Fix boot crash
by mapping EFI memmap entries bottom-up at runtime, instead of
top-down").

For more information on what the current limitations are for mapping
EFI regions, check out this whitepaper,

  https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Practices_with_UEFI.pdf

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

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

#1244659

FromIngo Molnar <mingo@kernel.org>
Date2015-10-12 14:50 +0200
Message-ID<qiKIa-7EQ-25@gated-at.bofh.it>
In reply to#1244657
* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> On Mon, 12 Oct, at 01:36:05PM, Borislav Petkov wrote:
> > On Tue, Oct 06, 2015 at 11:37:57AM -0400, Stephen Smalley wrote:
> > > > What does this range correspond to on your kernel?
> > 
> > Got a W+X splat here too, on the UEFI box with rc5+tip/master:
> > 
> > [    6.792949] rtc_cmos 00:02: setting system clock to 2015-10-12 11:17:03 UTC (1444648623)
> > [    6.807863] Freeing unused kernel memory: 1312K (ffffffff81f5f000 - ffffffff820a7000)
> > [    6.815831] usb 3-1: new high-speed USB device number 2 using ehci-pci
> > [    6.823261] Write protecting the kernel read-only data: 14336k
> > [    6.832196] Freeing unused kernel memory: 1796K (ffff88000383f000 - ffff880003a00000)
> > [    6.842210] Freeing unused kernel memory: 284K (ffff880003db9000 - ffff880003e00000)
> > [    6.850524] ------------[ cut here ]------------
> > [    6.855682] WARNING: CPU: 5 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x61e/0x7e0()
> > [    6.864944] x86/mm: Found insecure W+X mapping at address ffff88000005e000/0xffff88000005e000
> > [    6.874022] Modules linked in:
> > [    6.877643] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.3.0-rc5+ #1
> > [    6.884462] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A13 05/11/2014
> > [    6.892416]  ffffffff81caf1f7 ffff88043bdffd60 ffffffff813aab2c ffff88043bdffda8
> > [    6.900460]  ffff88043bdffd98 ffffffff81066776 ffff880004e55308 0000000000000004
> > [    6.907816] usb 4-1: new high-speed USB device number 2 using ehci-pci
> > [    6.915499]  8000000000000163 ffff88043bdffe98 0000000000000000 ffff88043bdffdf8
> > [    6.923520] Call Trace:
> > [    6.926512]  [<ffffffff813aab2c>] dump_stack+0x4e/0x82
> > [    6.931551] usb 3-1: New USB device found, idVendor=8087, idProduct=0024
> > [    6.931552] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> > [    6.933120] hub 3-1:1.0: USB hub found
> > [    6.933369] hub 3-1:1.0: 6 ports detected
> > [    6.955784]  [<ffffffff81066776>] warn_slowpath_common+0x86/0xc0
> > [    6.962341]  [<ffffffff810667fc>] warn_slowpath_fmt+0x4c/0x50
> > [    6.968631]  [<ffffffff8105bb7e>] note_page+0x61e/0x7e0
> > [    6.974404]  [<ffffffff8105c09f>] ptdump_walk_pgd_level_core+0x35f/0x3f0
> > [    6.981651]  [<ffffffff8105c1d7>] ptdump_walk_pgd_level_checkwx+0x17/0x20
> > [    6.988996]  [<ffffffff81051b0e>] mark_rodata_ro+0xee/0x100
> > [    6.995124]  [<ffffffff81828610>] ? rest_init+0x140/0x140
> > [    7.001064]  [<ffffffff8182862d>] kernel_init+0x1d/0xe0
> > [    7.006841]  [<ffffffff81836f6f>] ret_from_fork+0x3f/0x70
> > [    7.012774]  [<ffffffff81828610>] ? rest_init+0x140/0x140
> > [    7.018706] ---[ end trace 920055014e07ef1e ]---
> > [    7.024302] x86/mm: Checked W+X mappings: FAILED, 69568 W+X pages found.
> > 
> > And yes, there are a bunch of those mappings here too:
> > 
> > $ grep -c 'RW.*x' /sys/kernel/debug/kernel_page_tables
> > 75
> > 
> > Some of them are the UEFI runtime regions. I guess we can try to map
> > them as RO maybe, they need to be X. Matt, any reasons against that?
> 
> I'm glad you asked (but you won't be)!
> 
> Basically, it's guaranteed that there exist some machines that contain
> data in EfiRuntimeCode regions (and so require write permission) and
> code in EfiRuntimeData regions (and therefore require eXecute),
> because the whole point of the new EFI_PROPERTIES_TABLE feature in
> UEFI v2.5 was to make it explicit when the firmware does not include
> such regions.

So why not unmap them after bootup? Is there any reason to call into EFI code 
while the system is up and running?

Thanks,

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

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

#1244664

FromMatt Fleming <matt@codeblueprint.co.uk>
Date2015-10-12 15:00 +0200
Message-ID<qiKRQ-7QK-7@gated-at.bofh.it>
In reply to#1244659
On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
> 
> 
> So why not unmap them after bootup? Is there any reason to call into EFI code 
> while the system is up and running?

That's where the runtime services code lives. So if you want things
like EFI variables (used by the distro installer, among other things)
you need to map the runtime regions.

You can of course disable that by using the "noefi" kernel parameter,
which should unmap everything for you once you've finished booting.

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

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

#1244738

FromIngo Molnar <mingo@kernel.org>
Date2015-10-12 16:20 +0200
Message-ID<qiM7h-1nR-31@gated-at.bofh.it>
In reply to#1244664
* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
> > 
> > 
> > So why not unmap them after bootup? Is there any reason to call into EFI code 
> > while the system is up and running?
> 
> That's where the runtime services code lives. So if you want things like EFI 
> variables (used by the distro installer, among other things) you need to map the 
> runtime regions.

So EFI variables could be queried during bootup and saved on the Linux side.

Calling into firmware after the kernel has booted up is fragile in general - 
beyond W+X the security considerations.

Thanks,

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

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

#1244783

FromMatt Fleming <matt@codeblueprint.co.uk>
Date2015-10-12 16:50 +0200
Message-ID<qiMAh-1Y3-5@gated-at.bofh.it>
In reply to#1244738
On Mon, 12 Oct, at 04:17:54PM, Ingo Molnar wrote:
> 
> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> 
> > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
> > > 
> > > 
> > > So why not unmap them after bootup? Is there any reason to call into EFI code 
> > > while the system is up and running?
> > 
> > That's where the runtime services code lives. So if you want things like EFI 
> > variables (used by the distro installer, among other things) you need to map the 
> > runtime regions.
> 
> So EFI variables could be queried during bootup and saved on the Linux side.
 
Right, we could do that, but then we wouldn't be able to support
creation/updating variables at runtime, such as when you install a
distribution for the first time, or want to boot a new kernel filename
directly from the firmware without a boot loader (and need to modify
the BootXXXX variables).

And it's not just EFI variables that need runtime support either, for
some platforms the only way to reboot/poweroff is with EFI, such as on
the ASUS T100TA (Intel Baytrail-T).

That's not to say your suggestion doesn't make sense for some cases, I
can definitely see how turning off runtime support but providing a
cache of EFI variables would be useful for some scenarios. But I don't
think it's ever going to be workable as a default option.

> Calling into firmware after the kernel has booted up is fragile in general - 
> beyond W+X the security considerations.

It isn't intended to be fragile, and effort has gone into defining the
context under which the EFI runtime services can operate (though there
are obviously gaps in that specification).

The entire point of the EFI runtime services is that they can be
invoked from the OS, and because hardware/firmware developers rely on
that when designing platforms, it's going to be something that Linux
is going to have to be able to do. Of course, that doesn't we
shouldn't be able to turn it off if the user is happy to sacrifice
some platform functionality.

Additionally, if we've got suggestions for the firmware developers on
what we want the runtime context to look like, let's propose it to
them. They're pretty receptive in my experience.

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

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

#1244832

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2015-10-12 17:40 +0200
Message-ID<qiNmG-38X-17@gated-at.bofh.it>
In reply to#1244783
On 12 October 2015 at 16:49, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Mon, 12 Oct, at 04:17:54PM, Ingo Molnar wrote:
>>
>> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
>>
>> > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
>> > >
>> > >
>> > > So why not unmap them after bootup? Is there any reason to call into EFI code
>> > > while the system is up and running?
>> >
>> > That's where the runtime services code lives. So if you want things like EFI
>> > variables (used by the distro installer, among other things) you need to map the
>> > runtime regions.
>>
>> So EFI variables could be queried during bootup and saved on the Linux side.
>
> Right, we could do that, but then we wouldn't be able to support
> creation/updating variables at runtime, such as when you install a
> distribution for the first time, or want to boot a new kernel filename
> directly from the firmware without a boot loader (and need to modify
> the BootXXXX variables).
>
> And it's not just EFI variables that need runtime support either, for
> some platforms the only way to reboot/poweroff is with EFI, such as on
> the ASUS T100TA (Intel Baytrail-T).
>
> That's not to say your suggestion doesn't make sense for some cases, I
> can definitely see how turning off runtime support but providing a
> cache of EFI variables would be useful for some scenarios. But I don't
> think it's ever going to be workable as a default option.
>
>> Calling into firmware after the kernel has booted up is fragile in general -
>> beyond W+X the security considerations.
>
> It isn't intended to be fragile, and effort has gone into defining the
> context under which the EFI runtime services can operate (though there
> are obviously gaps in that specification).
>
> The entire point of the EFI runtime services is that they can be
> invoked from the OS, and because hardware/firmware developers rely on
> that when designing platforms, it's going to be something that Linux
> is going to have to be able to do. Of course, that doesn't we
> shouldn't be able to turn it off if the user is happy to sacrifice
> some platform functionality.
>
> Additionally, if we've got suggestions for the firmware developers on
> what we want the runtime context to look like, let's propose it to
> them. They're pretty receptive in my experience.
>

On arm64, we only map in all of the UEFI runtime services regions
during the time any of these services are being invoked. I think this
should be mostly feasible on x86 as well, although it would involve
yet another rewrite of the EFI region mapping code, and most likely a
long list of quirks for platforms that are not able to deal with it
correctly for one reason or the other (but that all come down to: 'if
you are not doing it like Windows does it, you must be doing it
wrong'). That would make the 'secure' way of mapping things an opt-in
feature, which is generally not desirable for security features (since
it will rarely be used in the real world then).

So enabling the Properties Table memprotect feature as soon as the
spec defines it in a meaningful way is probably a better way to go,
and our current involvement is focused on defining it such that it can
be enabled by default by firmwares rather than ending up an obscure
switch in the BIOS screen that only the paranoid ever turn on.

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

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

#1244852

FromMatt Fleming <matt@codeblueprint.co.uk>
Date2015-10-12 18:00 +0200
Message-ID<qiNG2-3wf-21@gated-at.bofh.it>
In reply to#1244832
On Mon, 12 Oct, at 05:34:53PM, Ard Biesheuvel wrote:
> 
> On arm64, we only map in all of the UEFI runtime services regions
> during the time any of these services are being invoked. I think this
> should be mostly feasible on x86 as well, although it would involve
> yet another rewrite of the EFI region mapping code, and most likely a
> long list of quirks for platforms that are not able to deal with it
> correctly for one reason or the other (but that all come down to: 'if
> you are not doing it like Windows does it, you must be doing it
> wrong').

Actually, we use separate page tables for mapping the EFI runtime
services on x86 right now. These tables are only used when making
runtime calls, just like on arm64.

So we've got a little bit of isolation right now.

> That would make the 'secure' way of mapping things an opt-in
> feature, which is generally not desirable for security features
> (since it will rarely be used in the real world then).

I'd like to think that we're coming to EFI_PROPERTIES_TABLE early
enough that we can work out all the kinks, get things working out of
the box in upstream tianocore, and have it be the standard way to
expose memory regions.

At least that's my hope.

> So enabling the Properties Table memprotect feature as soon as the
> spec defines it in a meaningful way is probably a better way to go,
> and our current involvement is focused on defining it such that it can
> be enabled by default by firmwares rather than ending up an obscure
> switch in the BIOS screen that only the paranoid ever turn on.

Indeed.

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

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

#1244911

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2015-10-12 18:50 +0200
Message-ID<qiOsq-4II-23@gated-at.bofh.it>
In reply to#1244852
On 12 October 2015 at 17:50, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Mon, 12 Oct, at 05:34:53PM, Ard Biesheuvel wrote:
>>
>> On arm64, we only map in all of the UEFI runtime services regions
>> during the time any of these services are being invoked. I think this
>> should be mostly feasible on x86 as well, although it would involve
>> yet another rewrite of the EFI region mapping code, and most likely a
>> long list of quirks for platforms that are not able to deal with it
>> correctly for one reason or the other (but that all come down to: 'if
>> you are not doing it like Windows does it, you must be doing it
>> wrong').
>
> Actually, we use separate page tables for mapping the EFI runtime
> services on x86 right now. These tables are only used when making
> runtime calls, just like on arm64.
>
> So we've got a little bit of isolation right now.
>

Ah ok. I thought that only applied to the duplicate 1:1 mapping, not
to the high mapping.

But that does reduce the attack surface considerably. Combined with
strict w^x once the UEFI 2.5 feature is fully supported, I am a lot
less nervous about RWX EFI runtime regions being used to subvert the
system.

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

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

#1246884

FromIngo Molnar <mingo@kernel.org>
Date2015-10-14 17:20 +0200
Message-ID<qjw0q-2n4-31@gated-at.bofh.it>
In reply to#1244783
* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> On Mon, 12 Oct, at 04:17:54PM, Ingo Molnar wrote:
> > 
> > * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> > 
> > > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
> > > > 
> > > > 
> > > > So why not unmap them after bootup? Is there any reason to call into EFI code 
> > > > while the system is up and running?
> > > 
> > > That's where the runtime services code lives. So if you want things like EFI 
> > > variables (used by the distro installer, among other things) you need to map the 
> > > runtime regions.
> > 
> > So EFI variables could be queried during bootup and saved on the Linux side.
>  
> Right, we could do that, but then we wouldn't be able to support
> creation/updating variables at runtime, such as when you install a
> distribution for the first time, or want to boot a new kernel filename
> directly from the firmware without a boot loader (and need to modify
> the BootXXXX variables).

Do we know the precise position and address range of these variables?

We could map them writable (but not executable), and the rest executable (but not 
writable).

That raises the question whether the same physical page ever mixes variables and 
actual code - but the hope would be that it's suffiently page granular for this to 
work.

Thanks,

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

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

#1246901

FromBorislav Petkov <bp@alien8.de>
Date2015-10-14 17:40 +0200
Message-ID<qjwjL-2JS-3@gated-at.bofh.it>
In reply to#1246884
On Wed, Oct 14, 2015 at 08:30:48AM -0700, Andy Lutomirski wrote:
> Can we just unmap these things until someone tries to do an EFI call,
> and then unmap them again after the call returns?  We already switch
> pgds for EFI IIRC.

hpa did mention an EFI-aware page fault handler at the time. I guess we
could do that too...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1247639

FromMatt Fleming <matt@codeblueprint.co.uk>
Date2015-10-15 12:20 +0200
Message-ID<qjNNE-3o4-15@gated-at.bofh.it>
In reply to#1246901
On Wed, 14 Oct, at 05:35:22PM, Borislav Petkov wrote:
> On Wed, Oct 14, 2015 at 08:30:48AM -0700, Andy Lutomirski wrote:
> > Can we just unmap these things until someone tries to do an EFI call,
> > and then unmap them again after the call returns?  We already switch
> > pgds for EFI IIRC.
> 
> hpa did mention an EFI-aware page fault handler at the time. I guess we
> could do that too...

We do this for the Linux UEFI Validation project kernel [1]. There, we
do not map EFI Boot Services regions by default, only if the firmware
tries to access them.

This gives us the opporunity to print an error message if Boot
Services regions are accessed after ExitBootServices() (which is the
bug mjg59 describes in commit 916f676f8dc0 ("x86, efi: Retain boot
service code until after switching to virtual mode")).

But for the issue being discussed in this thread, the thing unmapping
the EFI regions buys you is that they're no longer accessible from the
x86 sleep/wakeup code paths, since those also use trampoline_pgd which
is where the EFI page tables are mapped.

And that's probably a good idea.

[1] - https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=stable&id=9b78793058bf93958aa9529400cb2617ec1bc958

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

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

#1247657

FromBorislav Petkov <bp@alien8.de>
Date2015-10-15 12:40 +0200
Message-ID<qjO70-3Ld-31@gated-at.bofh.it>
In reply to#1247639
On Thu, Oct 15, 2015 at 11:10:16AM +0100, Matt Fleming wrote:
> We do this for the Linux UEFI Validation project kernel [1]. There, we
> do not map EFI Boot Services regions by default, only if the firmware
> tries to access them.
> 
> This gives us the opporunity to print an error message if Boot
> Services regions are accessed after ExitBootServices() (which is the
> bug mjg59 describes in commit 916f676f8dc0 ("x86, efi: Retain boot
> service code until after switching to virtual mode")).

Yeah, that's actually a good idea. Why not upstream it for the wider
audience so that people can actually start reporting b0rked UEFIs? With
a big and nice FW_BUG splat in there...

> But for the issue being discussed in this thread, the thing unmapping
> the EFI regions buys you is that they're no longer accessible from the
> x86 sleep/wakeup code paths, since those also use trampoline_pgd which
> is where the EFI page tables are mapped.
> 
> And that's probably a good idea.
> 
> [1] - https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=stable&id=9b78793058bf93958aa9529400cb2617ec1bc958

In reading that commit message above, the fact that the braindead
decision of allowing SetVirtualAddressMap() to be called only once
reminds me that we can't really have a PF handler for runtime
services as *all* mappings need to be ready before calling
SetVirtualAddressMap().

Or, alternatively, we can prep them, call SetVirtualAddressMap() and
then unmap them all and map them again at the same addresses only in the
PF handler, each time a runtime call happens. When that call finishes,
we unmap them again...

Hmm, perhaps not worth the trouble...


-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1248295

FromRicardo Neri <ricardo.neri-calderon@linux.intel.com>
Date2015-10-16 03:50 +0200
Message-ID<qk2jD-85Q-3@gated-at.bofh.it>
In reply to#1247657
On Thu, 2015-10-15 at 12:33 +0200, Borislav Petkov wrote:
> Yeah, that's actually a good idea. Why not upstream it for the wider
> audience so that people can actually start reporting b0rked UEFIs?
> With
> a big and nice FW_BUG splat in there...

We attempted to upstream in the past but later I discovered that my
implementation in particular is causing warnings due to SMP. Also, I
need to implement an alternative or extension to the current
efi_map_region, which have the __init qualifier. This is because
mappings might happen after the __inits have been discarded. I have this
work currently in my scope.

Thanks and BR,
Ricardo

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

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

#1246907

FromAndy Lutomirski <luto@amacapital.net>
Date2015-10-14 17:40 +0200
Message-ID<qjwjL-2JS-5@gated-at.bofh.it>
In reply to#1246884
On Wed, Oct 14, 2015 at 8:18 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
>
>> On Mon, 12 Oct, at 04:17:54PM, Ingo Molnar wrote:
>> >
>> > * Matt Fleming <matt@codeblueprint.co.uk> wrote:
>> >
>> > > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
>> > > >
>> > > >
>> > > > So why not unmap them after bootup? Is there any reason to call into EFI code
>> > > > while the system is up and running?
>> > >
>> > > That's where the runtime services code lives. So if you want things like EFI
>> > > variables (used by the distro installer, among other things) you need to map the
>> > > runtime regions.
>> >
>> > So EFI variables could be queried during bootup and saved on the Linux side.
>>
>> Right, we could do that, but then we wouldn't be able to support
>> creation/updating variables at runtime, such as when you install a
>> distribution for the first time, or want to boot a new kernel filename
>> directly from the firmware without a boot loader (and need to modify
>> the BootXXXX variables).
>
> Do we know the precise position and address range of these variables?
>
> We could map them writable (but not executable), and the rest executable (but not
> writable).
>
> That raises the question whether the same physical page ever mixes variables and
> actual code - but the hope would be that it's suffiently page granular for this to
> work.

Can we just unmap these things until someone tries to do an EFI call,
and then unmap them again after the call returns?  We already switch
pgds for EFI IIRC.

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

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

#1247177

FromMatt Fleming <matt@codeblueprint.co.uk>
Date2015-10-14 23:10 +0200
Message-ID<qjBta-20C-55@gated-at.bofh.it>
In reply to#1246884
On Wed, 14 Oct, at 05:18:07PM, Ingo Molnar wrote:
> 
> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> 
> > On Mon, 12 Oct, at 04:17:54PM, Ingo Molnar wrote:
> > > 
> > > * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> > > 
> > > > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
> > > > > 
> > > > > 
> > > > > So why not unmap them after bootup? Is there any reason to call into EFI code 
> > > > > while the system is up and running?
> > > > 
> > > > That's where the runtime services code lives. So if you want things like EFI 
> > > > variables (used by the distro installer, among other things) you need to map the 
> > > > runtime regions.
> > > 
> > > So EFI variables could be queried during bootup and saved on the Linux side.
> >  
> > Right, we could do that, but then we wouldn't be able to support
> > creation/updating variables at runtime, such as when you install a
> > distribution for the first time, or want to boot a new kernel filename
> > directly from the firmware without a boot loader (and need to modify
> > the BootXXXX variables).
> 
> Do we know the precise position and address range of these variables?
> 
> We could map them writable (but not executable), and the rest executable (but not 
> writable).
 
The variables are stored in NVRAM, which we don't map into the kernel
virtual address space. We have to initiate the transaction of writing
to the variables by executing EFI runtime services.

We obviously have buffers that we pass to the BIOS that contain
variable data, but these should be NX anyway because they're regular
kernel allocations.

> That raises the question whether the same physical page ever mixes variables and 
> actual code - but the hope would be that it's suffiently page granular for this to 
> work.

I don't think that would ever happen.

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

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

#1244790

FromJosh Triplett <josh@joshtriplett.org>
Date2015-10-12 17:00 +0200
Message-ID<qiMJZ-29w-25@gated-at.bofh.it>
In reply to#1244738
On Mon, Oct 12, 2015 at 04:17:54PM +0200, Ingo Molnar wrote:
> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
> > > So why not unmap them after bootup? Is there any reason to call into EFI code 
> > > while the system is up and running?
> > 
> > That's where the runtime services code lives. So if you want things like EFI 
> > variables (used by the distro installer, among other things) you need to map the 
> > runtime regions.
> 
> So EFI variables could be queried during bootup and saved on the Linux side.

That wouldn't support writing to EFI variables.  Or using the EFI
capsule update system to update firmware.

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

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

#1246893

FromIngo Molnar <mingo@kernel.org>
Date2015-10-14 17:30 +0200
Message-ID<qjwa6-2yi-19@gated-at.bofh.it>
In reply to#1244790
* Josh Triplett <josh@joshtriplett.org> wrote:

> On Mon, Oct 12, 2015 at 04:17:54PM +0200, Ingo Molnar wrote:
> > * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> > > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
> > > > So why not unmap them after bootup? Is there any reason to call into EFI code 
> > > > while the system is up and running?
> > > 
> > > That's where the runtime services code lives. So if you want things like EFI 
> > > variables (used by the distro installer, among other things) you need to map the 
> > > runtime regions.
> > 
> > So EFI variables could be queried during bootup and saved on the Linux side.
> 
> That wouldn't support writing to EFI variables.  Or using the EFI
> capsule update system to update firmware.

Well, if we know the location of those pages then we could map those 'rw-' - while 
the rest would be mapped 'r-x'.

The 'rwx' mappings that are created are problematic from a security POV - they 
basically undo many of our NX protections...

Thanks,

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

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web