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

Groups > linux.kernel > #1268039 > unrolled thread

[PATCH 6/6] Documentation/x86: Update EFI memory region description

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

  [PATCH 6/6] Documentation/x86: Update EFI memory region description Matt Fleming <matt@codeblueprint.co.uk> - 2015-11-12 16:50 +0100
    Re: [PATCH 6/6] Documentation/x86: Update EFI memory region  description Borislav Petkov <bp@alien8.de> - 2015-11-12 19:40 +0100
    Re: [PATCH 6/6] Documentation/x86: Update EFI memory region  description Ingo Molnar <mingo@kernel.org> - 2015-11-13 10:30 +0100
      Re: [PATCH 6/6] Documentation/x86: Update EFI memory region  description Matt Fleming <matt@codeblueprint.co.uk> - 2015-11-13 10:30 +0100
        Re: [PATCH 6/6] Documentation/x86: Update EFI memory region description Linus Torvalds <torvalds@linux-foundation.org> - 2015-11-13 17:50 +0100
          Re: [PATCH 6/6] Documentation/x86: Update EFI memory region  description Matt Fleming <matt@codeblueprint.co.uk> - 2015-11-13 23:30 +0100

#1268039 — [PATCH 6/6] Documentation/x86: Update EFI memory region description

Make it clear that the EFI page tables are only available during EFI
runtime calls since that subject has come up a fair numbers of times
in the past.

Additionally, add the EFI region start and end addresses to the table
so that it's possible to see at a glance where they fall in relation
to other regions.

Cc: Borislav Petkov <bp@alien8.de>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Denys Vlasenko <dvlasenk@redhat.com>,
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
 Documentation/x86/x86_64/mm.txt | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 05712ac83e38..a9885bb1ac22 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -16,6 +16,8 @@ ffffec0000000000 - fffffc0000000000 (=44 bits) kasan shadow memory (16TB)
 ... unused hole ...
 ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
 ... unused hole ...
+ffffffef00000000 - ffffffff00000000 (=64 GB) EFI region mapping space
+... unused hole ...
 ffffffff80000000 - ffffffffa0000000 (=512 MB)  kernel text mapping, from phys 0
 ffffffffa0000000 - ffffffffff5fffff (=1525 MB) module mapping space
 ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
@@ -32,11 +34,9 @@ reference.
 Current X86-64 implementations only support 40 bits of address space,
 but we support up to 46 bits. This expands into MBZ space in the page tables.
 
-->trampoline_pgd:
-
-We map EFI runtime services in the aforementioned PGD in the virtual
-range of 64Gb (arbitrarily set, can be raised if needed)
-
-0xffffffef00000000 - 0xffffffff00000000
+We map EFI runtime services in the efi_pgd PGD in the virtual range of
+64Gb (arbitrarily set, can be raised if needed). The mappings are not
+part of any other kernel PGD and are only available during EFI runtime
+calls.
 
 -Andi Kleen, Jul 2004
-- 
2.6.2

--
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]

#1268190 — Re: [PATCH 6/6] Documentation/x86: Update EFI memory region description

On Thu, Nov 12, 2015 at 03:40:23PM +0000, Matt Fleming wrote:
> Make it clear that the EFI page tables are only available during EFI
> runtime calls since that subject has come up a fair numbers of times
> in the past.
> 
> Additionally, add the EFI region start and end addresses to the table
> so that it's possible to see at a glance where they fall in relation
> to other regions.
> 
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Dave Jones <davej@codemonkey.org.uk>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Denys Vlasenko <dvlasenk@redhat.com>,
> Cc: Stephen Smalley <sds@tycho.nsa.gov>
> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
> ---
>  Documentation/x86/x86_64/mm.txt | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
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]

#1268714 — Re: [PATCH 6/6] Documentation/x86: Update EFI memory region description

* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> +We map EFI runtime services in the efi_pgd PGD in the virtual range of
> +64Gb (arbitrarily set, can be raised if needed). The mappings are not
> +part of any other kernel PGD and are only available during EFI runtime
> +calls.

Is that virtual address range 0-64Gb, i.e.:

	0x00000000.00000000 - 0x00000010.00000000

or is it somewhere else?

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]

#1268719 — Re: [PATCH 6/6] Documentation/x86: Update EFI memory region description

On Fri, 13 Nov, at 10:22:10AM, Ingo Molnar wrote:
> 
> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> 
> > +We map EFI runtime services in the efi_pgd PGD in the virtual range of
> > +64Gb (arbitrarily set, can be raised if needed). The mappings are not
> > +part of any other kernel PGD and are only available during EFI runtime
> > +calls.
> 
> Is that virtual address range 0-64Gb, i.e.:
> 
> 	0x00000000.00000000 - 0x00000010.00000000
> 
> or is it somewhere else?

You've snipped the patch hunk that gives the address range used,

diff --git a/Documentation/x86/x86_64/mm.txt
b/Documentation/x86/x86_64/mm.txt
index 05712ac83e38..a9885bb1ac22 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -16,6 +16,8 @@ ffffec0000000000 - fffffc0000000000 (=44 bits) kasan
shadow memory (16TB)
 ... unused hole ...
 ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
 ... unused hole ...
+ffffffef00000000 - ffffffff00000000 (=64 GB) EFI region mapping space
+... unused hole ...
 ffffffff80000000 - ffffffffa0000000 (=512 MB)  kernel text mapping,
from phys 0
 ffffffffa0000000 - ffffffffff5fffff (=1525 MB) module mapping space
 ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
--
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]

#1269085

On Fri, Nov 13, 2015 at 1:29 AM, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Fri, 13 Nov, at 10:22:10AM, Ingo Molnar wrote:
>
> You've snipped the patch hunk that gives the address range used,

I'm actually wondering if we should strive to make the UEFI stuff more
like a user process, and just map the UEFI mappings in low memory in
that magic UEFI address space.

We won't be able to run those things *as* user space, since I assume
the code will want to do a lot of kernely things, but shouldn't we aim
to make it look as much like that as possible? Maybe some day we could
even strive to run it in some controlled environment (ie user space
with fixups, virtual machine, whatever), but even if we never get
there it sounds like a potentially good idea to try to set up the
mappings to move in that direction..

No big hurry, and maybe there are good reasons not to go that way. The
first step is indeed just to get rid of the WX mappings in the normal
kernel page tables.

               Linus
--
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]

#1269344 — Re: [PATCH 6/6] Documentation/x86: Update EFI memory region description

On Fri, 13 Nov, at 08:42:54AM, Linus Torvalds wrote:
> On Fri, Nov 13, 2015 at 1:29 AM, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> > On Fri, 13 Nov, at 10:22:10AM, Ingo Molnar wrote:
> >
> > You've snipped the patch hunk that gives the address range used,
> 
> I'm actually wondering if we should strive to make the UEFI stuff more
> like a user process, and just map the UEFI mappings in low memory in
> that magic UEFI address space.
 
We map things in the user address space now but only for the purposes
of having an identity mapping, for the reasons that I mentioned
previously: bust firmware accesses and for the SetVirtaulAddressMap()
call [1]. Importantly, the kernel does not access the identity mapping
directly.

So if we were to repurpose the user address space it would make sense
to just have the identity mapping be the one and only mapping.

However, going through the identity addresses to invoke EFI runtime
services is known to break some Apple Macs. It's probably worth
revisiting this issue, because I don't have any further details.

Having a separate mapping in the user address space that isn't the
identity mapping is also possible of course.

> We won't be able to run those things *as* user space, since I assume
> the code will want to do a lot of kernely things, but shouldn't we aim
> to make it look as much like that as possible? Maybe some day we could
> even strive to run it in some controlled environment (ie user space
> with fixups, virtual machine, whatever), but even if we never get
> there it sounds like a potentially good idea to try to set up the
> mappings to move in that direction..

It would be interesting to see how far we could push this, say, using
SMAP/SMEP to further isolate what kernel pieces the firmware can
touch. It's not about security guarantees since most of the firmware
functionality is implemented in SMM today for x86, but it does go some
way towards providing protection from unintended accesses.

> No big hurry, and maybe there are good reasons not to go that way. The
> first step is indeed just to get rid of the WX mappings in the normal
> kernel page tables.

I think it's worth exploring.

[1] Oh, and also for the EFI mixed mode code (running 64-bit kernels
on 32-bit EFI), but less people tend to care about that ;-)
--
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] | [standalone]

Back to top | Article view | linux.kernel

csiph-web