Groups > linux.kernel > #1233090 > unrolled thread

[PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

Started by	Matt Fleming <matt@codeblueprint.co.uk>
First post	2015-09-26 00:10 +0200
Last post	2015-10-02 11:50 +0200
Articles	12 on this page of 32 — 9 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.

  [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Matt Fleming <matt@codeblueprint.co.uk> - 2015-09-26 00:10 +0200
    Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ingo Molnar <mingo@kernel.org> - 2015-09-26 08:00 +0200
      Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-26 08:50 +0200
      Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Matt Fleming <matt@codeblueprint.co.uk> - 2015-09-26 15:50 +0200
        Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ingo Molnar <mingo@kernel.org> - 2015-09-27 09:10 +0200
          Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-28 08:50 +0200
            Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ingo Molnar <mingo@kernel.org> - 2015-09-28 10:30 +0200
              Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-28 12:00 +0200
                Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ingo Molnar <mingo@kernel.org> - 2015-09-29 11:20 +0200
                  Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-29 12:50 +0200
                    Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Matt Fleming <matt@codeblueprint.co.uk> - 2015-09-29 16:20 +0200
                  Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Matt Fleming <matt@codeblueprint.co.uk> - 2015-09-29 16:00 +0200
      Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Andy Lutomirski <luto@amacapital.net> - 2015-09-26 19:10 +0200
        Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime "H. Peter Anvin" <hpa@zytor.com> - 2015-09-26 19:30 +0200
          Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-26 20:20 +0200
            Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Matt Fleming <matt@codeblueprint.co.uk> - 2015-09-26 22:00 +0200
              Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-26 22:10 +0200
                Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime "H. Peter Anvin" <hpa@zytor.com> - 2015-09-26 22:30 +0200
                  Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Andy Lutomirski <luto@amacapital.net> - 2015-09-27 18:40 +0200
                    Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Matthew Garrett <mjg59@srcf.ucam.org> - 2015-09-27 20:40 +0200
                      Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ingo Molnar <mingo@kernel.org> - 2015-09-28 08:20 +0200
                        Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Matthew Garrett <mjg59@srcf.ucam.org> - 2015-09-28 09:10 +0200
                          Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Laszlo Ersek <lersek@redhat.com> - 2015-09-30 00:00 +0200
                            Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-30 11:40 +0200
                              Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Andy Lutomirski <luto@amacapital.net> - 2015-09-30 18:50 +0200
                                Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime James Bottomley <jbottomley@odin.com> - 2015-09-30 19:30 +0200
                        Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime "H. Peter Anvin" <hpa@zytor.com> - 2015-09-30 03:00 +0200
            Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime "H. Peter Anvin" <hpa@zytor.com> - 2015-09-26 22:00 +0200
          Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Matt Fleming <matt@codeblueprint.co.uk> - 2015-09-26 22:00 +0200
        Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Ingo Molnar <mingo@kernel.org> - 2015-09-27 09:00 +0200
    [tip:core/urgent] x86/efi:   Fix boot crash by mapping EFI memmap entries bottom-up at runtime,   instead of top-down tip-bot for Matt Fleming <tipbot@zytor.com> - 2015-10-01 15:00 +0200
      Re: [tip:core/urgent] x86/efi: Fix boot crash by mapping EFI memmap  entries bottom-up at runtime, instead of top-down Matt Fleming <matt@codeblueprint.co.uk> - 2015-10-02 11:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1233873

From	Ingo Molnar <mingo@kernel.org>
Date	2015-09-28 08:20 +0200
Message-ID	<qdzX3-5PD-1@gated-at.bofh.it>
In reply to	#1233731

* Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Sun, Sep 27, 2015 at 09:30:48AM -0700, Andy Lutomirski wrote:
> > On Sep 26, 2015 1:19 PM, "H. Peter Anvin" <hpa@zytor.com> wrote:
> > >
> > > Sadly a lot of firmware is known to fail in that configuration :(  That was very much our guest choice.
> > >
> > 
> > Why can't we map everything completely 1:1 (VA = PA) and call the
> > setVA thing but pass it literally the identity.
> 
> Last time I tried this I found that some firmware makes assumptions 
> about having high addresses.

So the question is, what does Windows do?

PC firmware is a hostile environment for Linux, to be compatible the best we can 
do is to mimic the environment that the firmware is tested under - i.e. try to use 
the firmware in the way Windows uses it.

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]

#1233895

From	Matthew Garrett <mjg59@srcf.ucam.org>
Date	2015-09-28 09:10 +0200
Message-ID	<qdAJr-6Z2-13@gated-at.bofh.it>
In reply to	#1233873

On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:

> So the question is, what does Windows do?

It's pretty trivial to hack OVMF to dump the SetVirtualAddressMap() 
arguments to the qemu debug port. Unfortunately I'm about to drop mostly 
offline for a week, otherwise I'd give it a go...

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--
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]

#1235573

From	Laszlo Ersek <lersek@redhat.com>
Date	2015-09-30 00:00 +0200
Message-ID	<qeb6i-25A-21@gated-at.bofh.it>
In reply to	#1233895

On 09/28/15 08:41, Matthew Garrett wrote:
> On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:
>
>> So the question is, what does Windows do?
>
> It's pretty trivial to hack OVMF to dump the SetVirtualAddressMap()
> arguments to the qemu debug port. Unfortunately I'm about to drop
> mostly  offline for a week, otherwise I'd give it a go...

In order to enable the properties table feature in OVMF, two conditions
have to be satisfied:

(a) set gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable to TRUE
(b) build DXE_RUNTIME_DRIVER modules with 4KB section alignment

(a) used to be possible only statically (ie. at build time), but since
edk2 commit ab081a50e5 [1] it can be done dynamically too, on the qemu
command line. See that edk2 commit for details.

This OVMF feature depends on QEMU commit 81b2b81062 [2]. Another patch
from Gabriel is under review that enables such simple settings without
host-side files [3].

(b) is satisfied by the edk2 patch that Ard posted today [4].

Because I know how much people like building OVMF, I uploaded a fresh
OVMF binary (which includes a number of other patches from my personal
tree, but those are irrelevent here), with a matching varstore template,
to [5]. The relevant edk2 patches (ie. the one from Ard [4], and a debug
patch like you mention above) can also be found under [5].

(

I recommend to start QEMU like this:

  # Create a new (empty) varstore for the virtual machine, from the
  # varstore template.

  cp OVMF_VARS.fd my-vars.fd

  # Start the VM, with direct kernel boot.

  qemu-system-x86_64 \
  -m 2048 \
  -M pc,accel=kvm \
  \
  -device qxl-vga \
  \
  -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \
  -drive if=pflash,format=raw,unit=1,file=my-vars.fd \
  \
  -debugcon file:debug.log \
  -global isa-debugcon.iobase=0x402 \
  \
  -chardev stdio,signal=off,mux=on,id=char0 \
  -mon chardev=char0,mode=readline,default \
  -serial chardev:char0 \
  \
  -kernel vmlinuz... \
  -initrd initramfs... \
  -append "root=..." \
  \
  ...

The guest will have 2GB of RAM, it will use KVM, the virtual video card
will be QXL; the OVMF debug log will be written to "debug.log". The key
combination [Control-A C] will switch between the QEMU monitor prompt
and the serial port of the guest. The above should be suitable for rapid
testing of kernels built on the host.

)

Then I booted my Windows Server 2012 R2, Windows 8.1, and Windows 10
guests, with the properties table feature enabled vs. disabled in the
firmware. (All three Windows guests were updated first though.)

All three Windows OSes adapt their SetVirtualAddressMap() calls, when
the feature is enabled in the firmware. However, Windows 8.1 crashes
nonetheless (BSOD, I forget the fault details, sorry). Windows Server
2012 R2 and Windows 10 boot fine.

I uploaded the verbose OVMF log files from all six guest boots to [5].
The tables you might be interested in are dumped at the ends of the log
files.

All three guests had 2GB of RAM. They had different VM configurations,
but between disabling and enabling the properties table feature, no
other knob was tweaked. Therefore the two log files of the same guest
should be comparable against each other, for each guest. For example:

$ colordiff -u ovmf.win10.prop.{disabled,enabled}.log

Because stuff hosted on the web privately tends to go away, I'll quote
that diff here, for posterity:

> --- ovmf.win10.prop.disabled.log	2015-09-29 22:01:45.252126086 +0200
> +++ ovmf.win10.prop.enabled.log	2015-09-29 21:50:54.579475078 +0200
> @@ -24,7 +24,7 @@
>  QemuFwCfg interface is supported.
>  Platform PEIM Loaded
>  CMOS:
> -00: 38 00 01 00 22 00 03 29 09 15 26 02 00 80 00 00
> +00: 48 00 50 00 21 00 03 29 09 15 26 02 00 80 00 00
>  10: 00 00 00 00 06 80 02 FF FF 00 00 00 00 00 00 00
>  20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  30: FF FF 20 00 00 7F 00 20 30 00 00 00 00 12 00 00
> @@ -1110,6 +1110,17 @@
>  InstallProtocolInterface: 4CF5B200-68B8-4CA5-9EEC-B23E3F50029A 7F271568
>  [Variable]END_OF_DXE is signaled
>  Initialize variable error flag (FF)
> +MemoryProtectionAttribute - 0x0000000000000001
> +Total Image Count - 0x8
> +Dump ImageRecord:
> +  Image[0]: 0x000000007EC26000 - 0x000000000000A000
> +  Image[1]: 0x000000007EC35000 - 0x0000000000008000
> +  Image[2]: 0x000000007EC65000 - 0x000000000000C000
> +  Image[3]: 0x000000007ED76000 - 0x00000000000A3000
> +  Image[4]: 0x000000007FE9E000 - 0x0000000000009000
> +  Image[5]: 0x000000007FEA7000 - 0x000000000000A000
> +  Image[6]: 0x000000007FEB1000 - 0x000000000000C000
> +  Image[7]: 0x000000007FEBD000 - 0x000000000000C000
>  S3Ready!
>  SaveLockBox: Guid=DEA652B0-D587-4C54-B5B4-C682E7A0AA3D Buffer=7FEEE000 Length=0xA
>  SetLockBoxAttributes: Guid=DEA652B0-D587-4C54-B5B4-C682E7A0AA3D Attributes=0x1
> @@ -1822,18 +1833,29 @@
>  InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7F0EBA00
>  Loading driver at 0x00010000000 EntryPoint=0x00010014790 bootmgfw.efi
>  InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F0B8898
> -RuntimeDriverSetVirtualAddressMap: 12 descriptors
> +RuntimeDriverSetVirtualAddressMap: 23 descriptors
>   # Memory Type  PhysicalStart 0x  VirtualStart 0x          Size 0x Attributes
>  -- ------------ ---------------- ---------------- ---------------- --------------------------------------
> - 0 RuntimeData  000000007EC21000 FFFFFFFFFF7E4000 0000000000005000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> - 1 RuntimeCode  000000007EC26000 FFFFFFFFFF7E9000 000000000000A000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> - 2 RuntimeData  000000007EC30000 FFFFFFFFFF7F3000 0000000000005000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> - 3 RuntimeCode  000000007EC35000 FFFFFFFFFF7F8000 0000000000008000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> - 4 RuntimeData  000000007EC60000 FFFFFFFFFF800000 0000000000005000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> - 5 RuntimeCode  000000007EC65000 FFFFFFFFFF805000 000000000000C000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> - 6 RuntimeData  000000007EC9E000 FFFFFFFFFF811000 00000000000D8000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> - 7 RuntimeCode  000000007ED76000 FFFFFFFFFF8E9000 00000000000A3000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> - 8 RuntimeCode  000000007FE99000 FFFFFFFFFF98C000 0000000000030000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> - 9 RuntimeData  000000007FEC9000 FFFFFFFFFF9BC000 0000000000024000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> -10 RuntimeData  000000007FFD0000 FFFFFFFFFF9E0000 0000000000020000 [UC|WC|WT|WB|   |  |  |  |  |  |  |RT]
> -11 RuntimeData  00000000FFE00000 FFFFFFFFFFA00000 0000000000200000 [UC|  |  |  |   |  |  |  |  |  |  |RT]
> + 0 RuntimeData  000000007EC21000 FFFFFFFFFF7E4000 0000000000006000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> + 1 RuntimeCode  000000007EC27000 FFFFFFFFFF7EA000 0000000000007000 [UC|WC|WT|WB|   |  |  |  |RO|  |  |RT]
> + 2 RuntimeData  000000007EC2E000 FFFFFFFFFF7F1000 0000000000007000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> + 3 RuntimeData  000000007EC35000 FFFFFFFFFF7F8000 0000000000001000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> + 4 RuntimeCode  000000007EC36000 FFFFFFFFFF7F9000 0000000000005000 [UC|WC|WT|WB|   |  |  |  |RO|  |  |RT]
> + 5 RuntimeData  000000007EC3B000 FFFFFFFFFF7FE000 0000000000002000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> + 6 RuntimeData  000000007EC60000 FFFFFFFFFF800000 0000000000006000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> + 7 RuntimeCode  000000007EC66000 FFFFFFFFFF806000 0000000000009000 [UC|WC|WT|WB|   |  |  |  |RO|  |  |RT]
> + 8 RuntimeData  000000007EC6F000 FFFFFFFFFF80F000 0000000000002000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> + 9 RuntimeData  000000007EC9E000 FFFFFFFFFF811000 00000000000D9000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> +10 RuntimeCode  000000007ED77000 FFFFFFFFFF8EA000 0000000000097000 [UC|WC|WT|WB|   |  |  |  |RO|  |  |RT]
> +11 RuntimeData  000000007EE0E000 FFFFFFFFFF981000 000000000000B000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> +12 RuntimeData  000000007FE99000 FFFFFFFFFF98C000 0000000000006000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> +13 RuntimeCode  000000007FE9F000 FFFFFFFFFF992000 0000000000006000 [UC|WC|WT|WB|   |  |  |  |RO|  |  |RT]
> +14 RuntimeData  000000007FEA5000 FFFFFFFFFF998000 0000000000003000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> +15 RuntimeCode  000000007FEA8000 FFFFFFFFFF99B000 0000000000007000 [UC|WC|WT|WB|   |  |  |  |RO|  |  |RT]
> +16 RuntimeData  000000007FEAF000 FFFFFFFFFF9A2000 0000000000003000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> +17 RuntimeCode  000000007FEB2000 FFFFFFFFFF9A5000 0000000000009000 [UC|WC|WT|WB|   |  |  |  |RO|  |  |RT]
> +18 RuntimeData  000000007FEBB000 FFFFFFFFFF9AE000 0000000000003000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> +19 RuntimeCode  000000007FEBE000 FFFFFFFFFF9B1000 0000000000009000 [UC|WC|WT|WB|   |  |  |  |RO|  |  |RT]
> +20 RuntimeData  000000007FEC7000 FFFFFFFFFF9BA000 0000000000026000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> +21 RuntimeData  000000007FFD0000 FFFFFFFFFF9E0000 0000000000020000 [UC|WC|WT|WB|   |  |  |XP|  |  |  |RT]
> +22 RuntimeData  00000000FFE00000 FFFFFFFFFFA00000 0000000000200000 [UC|  |  |  |   |  |  |XP|  |  |  |RT]

Thanks
Laszlo

[1] https://github.com/tianocore/edk2/commit/ab081a50e5
[2] https://github.com/qemu/qemu/commit/81b2b81062
[3] http://news.gmane.org/find-root.php?message_id=%3C1443544141-26568-1-git-send-email-somlo@cmu.edu%3E
[4] http://thread.gmane.org/gmane.comp.bios.edk2.devel/2640
[5] http://people.redhat.com/~lersek/ovmf_prop_table/
--
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]

#1235936

From	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date	2015-09-30 11:40 +0200
Message-ID	<qem1J-Zq-11@gated-at.bofh.it>
In reply to	#1235573

On 29 September 2015 at 23:58, Laszlo Ersek <lersek@redhat.com> wrote:
> On 09/28/15 08:41, Matthew Garrett wrote:
>> On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:
>>
>>> So the question is, what does Windows do?
>>
>> It's pretty trivial to hack OVMF to dump the SetVirtualAddressMap()
>> arguments to the qemu debug port. Unfortunately I'm about to drop
>> mostly  offline for a week, otherwise I'd give it a go...
[...]
> Then I booted my Windows Server 2012 R2, Windows 8.1, and Windows 10
> guests, with the properties table feature enabled vs. disabled in the
> firmware. (All three Windows guests were updated first though.)
>
> All three Windows OSes adapt their SetVirtualAddressMap() calls, when
> the feature is enabled in the firmware. However, Windows 8.1 crashes
> nonetheless (BSOD, I forget the fault details, sorry). Windows Server
> 2012 R2 and Windows 10 boot fine.
>

Looking at the log, it seems the VA mapping strategy is actually the
same (i.e., bottom-up for Win10), and the difference can be explained
by the differences in the memory map provided by the firmware to the
OS. And indeed, the Win8.1 log shows the following:

 # MemType Phys 0x  Virt 0x  Size 0x Attributes
-- ------- -------- -------- ------- -------------------------------
 0 RtData  7EC21000 FFBFA000 0006000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
 1 RtCode  7EC27000 FFBF3000 0007000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
 2 RtData  7EC2E000 FFBEC000 0007000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
 3 RtData  7EC35000 FFBEB000 0001000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
 4 RtCode  7EC36000 FFBE6000 0005000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
 5 RtData  7EC3B000 FFBE4000 0002000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
 6 RtData  7EC60000 FFBDE000 0006000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
 7 RtCode  7EC66000 FFBD5000 0009000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
 8 RtData  7EC6F000 FFBD3000 0002000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
 9 RtData  7EC9E000 FFAFA000 00D9000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
10 RtCode  7ED77000 FFA63000 0097000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
11 RtData  7EE0E000 FFA58000 000B000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
12 RtData  7FE99000 FFA52000 0006000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
13 RtCode  7FE9F000 FFA4C000 0006000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
14 RtData  7FEA5000 FFA49000 0003000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
15 RtCode  7FEA8000 FFA42000 0007000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
16 RtData  7FEAF000 FFA3F000 0003000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
17 RtCode  7FEB2000 FFA36000 0009000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
18 RtData  7FEBB000 FFA33000 0003000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
19 RtCode  7FEBE000 FFA2A000 0009000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
20 RtData  7FEC7000 FFA04000 0026000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
21 RtData  7FFD0000 FF9E4000 0020000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
22 RtData  FFE00000 FF7E4000 0200000 [UC|  |  |  |  |XP|  |  |  |RT]

I.e., the physical addresses increase while the virtual addresses
decrease, and since each consecutive RuntimeCode/RuntimeData pair
constitutes a PE/COFF image (.text and .data, respectively), the
PE/COFF images appear corrupted in the virtual space.

> I uploaded the verbose OVMF log files from all six guest boots to [5].
> The tables you might be interested in are dumped at the ends of the log
> files.
>
> All three guests had 2GB of RAM. They had different VM configurations,
> but between disabling and enabling the properties table feature, no
> other knob was tweaked. Therefore the two log files of the same guest
> should be comparable against each other, for each guest. For example:
>
> $ colordiff -u ovmf.win10.prop.{disabled,enabled}.log
>
> Because stuff hosted on the web privately tends to go away, I'll quote
> that diff here, for posterity:
>
>> --- ovmf.win10.prop.disabled.log      2015-09-29 22:01:45.252126086 +0200
>> +++ ovmf.win10.prop.enabled.log       2015-09-29 21:50:54.579475078 +0200
[...]

Thanks a lot for taking the time, this is very useful info.

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

#1236532

From	Andy Lutomirski <luto@amacapital.net>
Date	2015-09-30 18:50 +0200
Message-ID	<qesJQ-2eW-17@gated-at.bofh.it>
In reply to	#1235936

On Wed, Sep 30, 2015 at 2:30 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 29 September 2015 at 23:58, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 09/28/15 08:41, Matthew Garrett wrote:
>>> On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:
>>>
>>>> So the question is, what does Windows do?
>>>
>>> It's pretty trivial to hack OVMF to dump the SetVirtualAddressMap()
>>> arguments to the qemu debug port. Unfortunately I'm about to drop
>>> mostly  offline for a week, otherwise I'd give it a go...
> [...]
>> Then I booted my Windows Server 2012 R2, Windows 8.1, and Windows 10
>> guests, with the properties table feature enabled vs. disabled in the
>> firmware. (All three Windows guests were updated first though.)
>>
>> All three Windows OSes adapt their SetVirtualAddressMap() calls, when
>> the feature is enabled in the firmware. However, Windows 8.1 crashes
>> nonetheless (BSOD, I forget the fault details, sorry). Windows Server
>> 2012 R2 and Windows 10 boot fine.
>>
>
> Looking at the log, it seems the VA mapping strategy is actually the
> same (i.e., bottom-up for Win10), and the difference can be explained
> by the differences in the memory map provided by the firmware to the
> OS. And indeed, the Win8.1 log shows the following:
>
>  # MemType Phys 0x  Virt 0x  Size 0x Attributes
> -- ------- -------- -------- ------- -------------------------------
>  0 RtData  7EC21000 FFBFA000 0006000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
>  1 RtCode  7EC27000 FFBF3000 0007000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
>  2 RtData  7EC2E000 FFBEC000 0007000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
>  3 RtData  7EC35000 FFBEB000 0001000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
>  4 RtCode  7EC36000 FFBE6000 0005000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
>  5 RtData  7EC3B000 FFBE4000 0002000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
>  6 RtData  7EC60000 FFBDE000 0006000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
>  7 RtCode  7EC66000 FFBD5000 0009000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
>  8 RtData  7EC6F000 FFBD3000 0002000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
>  9 RtData  7EC9E000 FFAFA000 00D9000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
> 10 RtCode  7ED77000 FFA63000 0097000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
> 11 RtData  7EE0E000 FFA58000 000B000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
> 12 RtData  7FE99000 FFA52000 0006000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
> 13 RtCode  7FE9F000 FFA4C000 0006000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
> 14 RtData  7FEA5000 FFA49000 0003000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
> 15 RtCode  7FEA8000 FFA42000 0007000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
> 16 RtData  7FEAF000 FFA3F000 0003000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
> 17 RtCode  7FEB2000 FFA36000 0009000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
> 18 RtData  7FEBB000 FFA33000 0003000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
> 19 RtCode  7FEBE000 FFA2A000 0009000 [UC|WC|WT|WB|  |  |RO|  |  |RT]
> 20 RtData  7FEC7000 FFA04000 0026000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
> 21 RtData  7FFD0000 FF9E4000 0020000 [UC|WC|WT|WB|  |XP|  |  |  |RT]
> 22 RtData  FFE00000 FF7E4000 0200000 [UC|  |  |  |  |XP|  |  |  |RT]
>
> I.e., the physical addresses increase while the virtual addresses
> decrease, and since each consecutive RuntimeCode/RuntimeData pair
> constitutes a PE/COFF image (.text and .data, respectively), the
> PE/COFF images appear corrupted in the virtual space.

All of this garbage makes me want to ask a rhetorical question:

Why on Earth did anyone think it's a good idea to invoke EFI functions
at CPL0 once the OS is booted?

And a more practical question:

Do we actually have to invoke EFI functions at CPL0?

I really mean it.  Sure, for things like reboot where we give up
control and don't get it back, we need to do that.  But for things
like variable access, the EFI code should really only need access to
EFI memor (with a known PA -> VA map) and the ability to trigger an
SMI.  Doing it at CPL3 could require more fixups than would really
make sense, but could we virtualize it instead?

Actually, CPL3 + IOPL3 just might work.

Heck, on mixed-mode, we're already invoke EFI functions in compat
mode, and that seems okay, so those functions can't be poking at any
CPU state that varies between long and 32-bit modes.

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

#1236569

From	James Bottomley <jbottomley@odin.com>
Date	2015-09-30 19:30 +0200
Message-ID	<qetmz-3dp-37@gated-at.bofh.it>
In reply to	#1236532

T24gV2VkLCAyMDE1LTA5LTMwIGF0IDA5OjQzIC0wNzAwLCBBbmR5IEx1dG9taXJza2kgd3JvdGU6
DQo+IE9uIFdlZCwgU2VwIDMwLCAyMDE1IGF0IDI6MzAgQU0sIEFyZCBCaWVzaGV1dmVsDQo+IDxh
cmQuYmllc2hldXZlbEBsaW5hcm8ub3JnPiB3cm90ZToNCj4gPiBPbiAyOSBTZXB0ZW1iZXIgMjAx
NSBhdCAyMzo1OCwgTGFzemxvIEVyc2VrIDxsZXJzZWtAcmVkaGF0LmNvbT4gd3JvdGU6DQo+ID4+
IE9uIDA5LzI4LzE1IDA4OjQxLCBNYXR0aGV3IEdhcnJldHQgd3JvdGU6DQo+ID4+PiBPbiBNb24s
IFNlcCAyOCwgMjAxNSBhdCAwODoxNjo0NkFNICswMjAwLCBJbmdvIE1vbG5hciB3cm90ZToNCj4g
Pj4+DQo+ID4+Pj4gU28gdGhlIHF1ZXN0aW9uIGlzLCB3aGF0IGRvZXMgV2luZG93cyBkbz8NCj4g
Pj4+DQo+ID4+PiBJdCdzIHByZXR0eSB0cml2aWFsIHRvIGhhY2sgT1ZNRiB0byBkdW1wIHRoZSBT
ZXRWaXJ0dWFsQWRkcmVzc01hcCgpDQo+ID4+PiBhcmd1bWVudHMgdG8gdGhlIHFlbXUgZGVidWcg
cG9ydC4gVW5mb3J0dW5hdGVseSBJJ20gYWJvdXQgdG8gZHJvcA0KPiA+Pj4gbW9zdGx5ICBvZmZs
aW5lIGZvciBhIHdlZWssIG90aGVyd2lzZSBJJ2QgZ2l2ZSBpdCBhIGdvLi4uDQo+ID4gWy4uLl0N
Cj4gPj4gVGhlbiBJIGJvb3RlZCBteSBXaW5kb3dzIFNlcnZlciAyMDEyIFIyLCBXaW5kb3dzIDgu
MSwgYW5kIFdpbmRvd3MgMTANCj4gPj4gZ3Vlc3RzLCB3aXRoIHRoZSBwcm9wZXJ0aWVzIHRhYmxl
IGZlYXR1cmUgZW5hYmxlZCB2cy4gZGlzYWJsZWQgaW4gdGhlDQo+ID4+IGZpcm13YXJlLiAoQWxs
IHRocmVlIFdpbmRvd3MgZ3Vlc3RzIHdlcmUgdXBkYXRlZCBmaXJzdCB0aG91Z2guKQ0KPiA+Pg0K
PiA+PiBBbGwgdGhyZWUgV2luZG93cyBPU2VzIGFkYXB0IHRoZWlyIFNldFZpcnR1YWxBZGRyZXNz
TWFwKCkgY2FsbHMsIHdoZW4NCj4gPj4gdGhlIGZlYXR1cmUgaXMgZW5hYmxlZCBpbiB0aGUgZmly
bXdhcmUuIEhvd2V2ZXIsIFdpbmRvd3MgOC4xIGNyYXNoZXMNCj4gPj4gbm9uZXRoZWxlc3MgKEJT
T0QsIEkgZm9yZ2V0IHRoZSBmYXVsdCBkZXRhaWxzLCBzb3JyeSkuIFdpbmRvd3MgU2VydmVyDQo+
ID4+IDIwMTIgUjIgYW5kIFdpbmRvd3MgMTAgYm9vdCBmaW5lLg0KPiA+Pg0KPiA+DQo+ID4gTG9v
a2luZyBhdCB0aGUgbG9nLCBpdCBzZWVtcyB0aGUgVkEgbWFwcGluZyBzdHJhdGVneSBpcyBhY3R1
YWxseSB0aGUNCj4gPiBzYW1lIChpLmUuLCBib3R0b20tdXAgZm9yIFdpbjEwKSwgYW5kIHRoZSBk
aWZmZXJlbmNlIGNhbiBiZSBleHBsYWluZWQNCj4gPiBieSB0aGUgZGlmZmVyZW5jZXMgaW4gdGhl
IG1lbW9yeSBtYXAgcHJvdmlkZWQgYnkgdGhlIGZpcm13YXJlIHRvIHRoZQ0KPiA+IE9TLiBBbmQg
aW5kZWVkLCB0aGUgV2luOC4xIGxvZyBzaG93cyB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gICMg
TWVtVHlwZSBQaHlzIDB4ICBWaXJ0IDB4ICBTaXplIDB4IEF0dHJpYnV0ZXMNCj4gPiAtLSAtLS0t
LS0tIC0tLS0tLS0tIC0tLS0tLS0tIC0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KPiA+ICAwIFJ0RGF0YSAgN0VDMjEwMDAgRkZCRkEwMDAgMDAwNjAwMCBbVUN8V0N8V1R8
V0J8ICB8WFB8ICB8ICB8ICB8UlRdDQo+ID4gIDEgUnRDb2RlICA3RUMyNzAwMCBGRkJGMzAwMCAw
MDA3MDAwIFtVQ3xXQ3xXVHxXQnwgIHwgIHxST3wgIHwgIHxSVF0NCj4gPiAgMiBSdERhdGEgIDdF
QzJFMDAwIEZGQkVDMDAwIDAwMDcwMDAgW1VDfFdDfFdUfFdCfCAgfFhQfCAgfCAgfCAgfFJUXQ0K
PiA+ICAzIFJ0RGF0YSAgN0VDMzUwMDAgRkZCRUIwMDAgMDAwMTAwMCBbVUN8V0N8V1R8V0J8ICB8
WFB8ICB8ICB8ICB8UlRdDQo+ID4gIDQgUnRDb2RlICA3RUMzNjAwMCBGRkJFNjAwMCAwMDA1MDAw
IFtVQ3xXQ3xXVHxXQnwgIHwgIHxST3wgIHwgIHxSVF0NCj4gPiAgNSBSdERhdGEgIDdFQzNCMDAw
IEZGQkU0MDAwIDAwMDIwMDAgW1VDfFdDfFdUfFdCfCAgfFhQfCAgfCAgfCAgfFJUXQ0KPiA+ICA2
IFJ0RGF0YSAgN0VDNjAwMDAgRkZCREUwMDAgMDAwNjAwMCBbVUN8V0N8V1R8V0J8ICB8WFB8ICB8
ICB8ICB8UlRdDQo+ID4gIDcgUnRDb2RlICA3RUM2NjAwMCBGRkJENTAwMCAwMDA5MDAwIFtVQ3xX
Q3xXVHxXQnwgIHwgIHxST3wgIHwgIHxSVF0NCj4gPiAgOCBSdERhdGEgIDdFQzZGMDAwIEZGQkQz
MDAwIDAwMDIwMDAgW1VDfFdDfFdUfFdCfCAgfFhQfCAgfCAgfCAgfFJUXQ0KPiA+ICA5IFJ0RGF0
YSAgN0VDOUUwMDAgRkZBRkEwMDAgMDBEOTAwMCBbVUN8V0N8V1R8V0J8ICB8WFB8ICB8ICB8ICB8
UlRdDQo+ID4gMTAgUnRDb2RlICA3RUQ3NzAwMCBGRkE2MzAwMCAwMDk3MDAwIFtVQ3xXQ3xXVHxX
QnwgIHwgIHxST3wgIHwgIHxSVF0NCj4gPiAxMSBSdERhdGEgIDdFRTBFMDAwIEZGQTU4MDAwIDAw
MEIwMDAgW1VDfFdDfFdUfFdCfCAgfFhQfCAgfCAgfCAgfFJUXQ0KPiA+IDEyIFJ0RGF0YSAgN0ZF
OTkwMDAgRkZBNTIwMDAgMDAwNjAwMCBbVUN8V0N8V1R8V0J8ICB8WFB8ICB8ICB8ICB8UlRdDQo+
ID4gMTMgUnRDb2RlICA3RkU5RjAwMCBGRkE0QzAwMCAwMDA2MDAwIFtVQ3xXQ3xXVHxXQnwgIHwg
IHxST3wgIHwgIHxSVF0NCj4gPiAxNCBSdERhdGEgIDdGRUE1MDAwIEZGQTQ5MDAwIDAwMDMwMDAg
W1VDfFdDfFdUfFdCfCAgfFhQfCAgfCAgfCAgfFJUXQ0KPiA+IDE1IFJ0Q29kZSAgN0ZFQTgwMDAg
RkZBNDIwMDAgMDAwNzAwMCBbVUN8V0N8V1R8V0J8ICB8ICB8Uk98ICB8ICB8UlRdDQo+ID4gMTYg
UnREYXRhICA3RkVBRjAwMCBGRkEzRjAwMCAwMDAzMDAwIFtVQ3xXQ3xXVHxXQnwgIHxYUHwgIHwg
IHwgIHxSVF0NCj4gPiAxNyBSdENvZGUgIDdGRUIyMDAwIEZGQTM2MDAwIDAwMDkwMDAgW1VDfFdD
fFdUfFdCfCAgfCAgfFJPfCAgfCAgfFJUXQ0KPiA+IDE4IFJ0RGF0YSAgN0ZFQkIwMDAgRkZBMzMw
MDAgMDAwMzAwMCBbVUN8V0N8V1R8V0J8ICB8WFB8ICB8ICB8ICB8UlRdDQo+ID4gMTkgUnRDb2Rl
ICA3RkVCRTAwMCBGRkEyQTAwMCAwMDA5MDAwIFtVQ3xXQ3xXVHxXQnwgIHwgIHxST3wgIHwgIHxS
VF0NCj4gPiAyMCBSdERhdGEgIDdGRUM3MDAwIEZGQTA0MDAwIDAwMjYwMDAgW1VDfFdDfFdUfFdC
fCAgfFhQfCAgfCAgfCAgfFJUXQ0KPiA+IDIxIFJ0RGF0YSAgN0ZGRDAwMDAgRkY5RTQwMDAgMDAy
MDAwMCBbVUN8V0N8V1R8V0J8ICB8WFB8ICB8ICB8ICB8UlRdDQo+ID4gMjIgUnREYXRhICBGRkUw
MDAwMCBGRjdFNDAwMCAwMjAwMDAwIFtVQ3wgIHwgIHwgIHwgIHxYUHwgIHwgIHwgIHxSVF0NCj4g
Pg0KPiA+IEkuZS4sIHRoZSBwaHlzaWNhbCBhZGRyZXNzZXMgaW5jcmVhc2Ugd2hpbGUgdGhlIHZp
cnR1YWwgYWRkcmVzc2VzDQo+ID4gZGVjcmVhc2UsIGFuZCBzaW5jZSBlYWNoIGNvbnNlY3V0aXZl
IFJ1bnRpbWVDb2RlL1J1bnRpbWVEYXRhIHBhaXINCj4gPiBjb25zdGl0dXRlcyBhIFBFL0NPRkYg
aW1hZ2UgKC50ZXh0IGFuZCAuZGF0YSwgcmVzcGVjdGl2ZWx5KSwgdGhlDQo+ID4gUEUvQ09GRiBp
bWFnZXMgYXBwZWFyIGNvcnJ1cHRlZCBpbiB0aGUgdmlydHVhbCBzcGFjZS4NCj4gDQo+IEFsbCBv
ZiB0aGlzIGdhcmJhZ2UgbWFrZXMgbWUgd2FudCB0byBhc2sgYSByaGV0b3JpY2FsIHF1ZXN0aW9u
Og0KPiANCj4gV2h5IG9uIEVhcnRoIGRpZCBhbnlvbmUgdGhpbmsgaXQncyBhIGdvb2QgaWRlYSB0
byBpbnZva2UgRUZJIGZ1bmN0aW9ucw0KPiBhdCBDUEwwIG9uY2UgdGhlIE9TIGlzIGJvb3RlZD8N
Cg0KSSdtIGFmcmFpZCB0aGUgb3JpZ2luYXRvcnMgb2YgRUZJIChJbnRlbCkgbG9vayBvbiBpdCBh
cyBhIERPUw0KcmVwbGFjZW1lbnQgLi4uIHdpdGggdGhlIHNhbWUgT1Mgc3VwcG9ydC4NCg0KPiBB
bmQgYSBtb3JlIHByYWN0aWNhbCBxdWVzdGlvbjoNCj4gDQo+IERvIHdlIGFjdHVhbGx5IGhhdmUg
dG8gaW52b2tlIEVGSSBmdW5jdGlvbnMgYXQgQ1BMMD8NCj4gDQo+IEkgcmVhbGx5IG1lYW4gaXQu
ICBTdXJlLCBmb3IgdGhpbmdzIGxpa2UgcmVib290IHdoZXJlIHdlIGdpdmUgdXANCj4gY29udHJv
bCBhbmQgZG9uJ3QgZ2V0IGl0IGJhY2ssIHdlIG5lZWQgdG8gZG8gdGhhdC4gIEJ1dCBmb3IgdGhp
bmdzDQo+IGxpa2UgdmFyaWFibGUgYWNjZXNzLCB0aGUgRUZJIGNvZGUgc2hvdWxkIHJlYWxseSBv
bmx5IG5lZWQgYWNjZXNzIHRvDQo+IEVGSSBtZW1vciAod2l0aCBhIGtub3duIFBBIC0+IFZBIG1h
cCkgYW5kIHRoZSBhYmlsaXR5IHRvIHRyaWdnZXIgYW4NCj4gU01JLiAgRG9pbmcgaXQgYXQgQ1BM
MyBjb3VsZCByZXF1aXJlIG1vcmUgZml4dXBzIHRoYW4gd291bGQgcmVhbGx5DQo+IG1ha2Ugc2Vu
c2UsIGJ1dCBjb3VsZCB3ZSB2aXJ0dWFsaXplIGl0IGluc3RlYWQ/DQo+IA0KPiBBY3R1YWxseSwg
Q1BMMyArIElPUEwzIGp1c3QgbWlnaHQgd29yay4NCj4gDQo+IEhlY2ssIG9uIG1peGVkLW1vZGUs
IHdlJ3JlIGFscmVhZHkgaW52b2tlIEVGSSBmdW5jdGlvbnMgaW4gY29tcGF0DQo+IG1vZGUsIGFu
ZCB0aGF0IHNlZW1zIG9rYXksIHNvIHRob3NlIGZ1bmN0aW9ucyBjYW4ndCBiZSBwb2tpbmcgYXQg
YW55DQo+IENQVSBzdGF0ZSB0aGF0IHZhcmllcyBiZXR3ZWVuIGxvbmcgYW5kIDMyLWJpdCBtb2Rl
cy4NCg0KSXQncyBoYXJkLiAgVGhlIEVGSSBmdW5jdGlvbnMgZXhwZWN0IHRvIGludGVyYWN0IGRp
cmVjdGx5IHdpdGgga2VybmVsDQptZW1vcnksIHdoaWNoIHRoZXkgY2FuJ3QgYXQgQ1BMMy4gIFdl
IGNvdWxkIHZlY3RvciBhbGwgdGhhdCB0aHJvdWdoIGENCkNQTDMgcmVhZGFibGUgYnVmZmVyIGJ1
dCBhbnl0aGluZyB3aXRoaW4gRUZJIHRoYXQgdXNlcyBwcml2aWxlZ2VkDQppbnN0cnVjdGlvbnMg
d2lsbCBmYXVsdCBhbmQgd2UnbGwgaGF2ZSB0byBoYW5kbGUgaXQgLi4uIHRoaXMgcmVhbGx5DQpz
b3VuZHMgbGlrZSBhIGNhbiBvZiB3b3Jtcy4gIEVzcGVjaWFsbHkgYXMgd2luZG93cyB3aWxsIGJl
IG5vIGhlbHANCnRlc3RpbmcgYWxsIG9mIHRoaXMgYmVjYXVzZSBpdCB3aWxsIGNhbGwgaW4gYXQg
Q1BMMC4NCg0KSmFtZXMNCg0K
--
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]

#1235679

From	"H. Peter Anvin" <hpa@zytor.com>
Date	2015-09-30 03:00 +0200
Message-ID	<qedUt-67a-1@gated-at.bofh.it>
In reply to	#1233873

On 09/27/2015 11:16 PM, Ingo Molnar wrote:
> 
> So the question is, what does Windows do?
> 
> PC firmware is a hostile environment for Linux, to be compatible the best we can 
> do is to mimic the environment that the firmware is tested under - i.e. try to use 
> the firmware in the way Windows uses it.
> 

Windows apparently went through the same exercise of breakage followed
by a fix.  It is unknown if Windows will preserve gaps since those are
not manifest on existing firmware.

	-hpa


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

#1233286

From	"H. Peter Anvin" <hpa@zytor.com>
Date	2015-09-26 22:00 +0200
Message-ID	<qd3Nw-1lI-21@gated-at.bofh.it>
In reply to	#1233261

It is still a hack unless all relative offsets are preserved.  That is actually simpler, even: no sorting necessary.

On September 26, 2015 11:15:57 AM PDT, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>On 26 September 2015 at 10:20, H. Peter Anvin <hpa@zytor.com> wrote:
>> I think it "works" because the affected BIOSes don't put spaces
>between the chunks.  I have discussed this with Matt.
>>
>
>Forgive the ASCII art but perhaps an illustration might help:
>
>before the 2.5 feature, PE/COFF runtime images were remapped as
>illustrated here:
>
>                                PA                        VA
>+---------------+         +---------------+
>|               |         |               |
>| PE/COFF .text |         |    EFI        |
>|               |         |    Runtime    |
>+- - - - - - - -+    =>   |    Services   |----+
>|               |         |    Code       |    |    :               :
>| PE/COFF .data |         |               |    |    :               :
>|               |         |               |    |    +---------------+
>+---------------+         +---------------+    |    |               |
>|               |         |               |    |    |    EFI        |
>:               :         :               :    |    |    Runtime    |
>:               :         :               :    +--->|    Services   |
>|               |         |               |         |    Code       |
>+---------------+         +---------------+         |               |
>|               |         |               |         |               |
>| PE/COFF .text |         |    EFI        |         +---------------+
>|               |         |    Runtime    |         :      gap      :
>+- - - - - - - -+    =>   |    Services   |---+     +---------------+
>|               |         |    Code       |   |     |               |
>| PE/COFF .data |         |               |   |     |    EFI        |
>|               |         |               |   |     |    Runtime    |
>+---------------+         +---------------+   +---->|    Services   |
>|               |         |               |         |    Code       |
>:               :         :               :         |               |
>:               :         :               :         |               |
>:               :         :               :         +---------------+
>:               :         :               :         :               :
>
>Since the affected symbol references only exist between PE/COFF .text
>and PE/COFF .data, there is never a problem since each is PE/COFF
>image is mapped as a single region.
>However, with the new feature enabled, this no longer holds:
>                                PA                        VA
>+---------------+         +---------------+
>|               |         |               |
>| PE/COFF .text |         |    RtServices |----+
>|               |         |    Code       |    |
>+- - - - - - - -+    =>   +---------------+    |    +---------------+
>|               |         |    RtServices |    +--->|    RtServices |
>| PE/COFF .data |         |    Data       |         |    Code       |
>|               |         |               |----+    +---------------+
>+---------------+         +---------------+    |    :     gap       :
>|               |         |               |    |    +---------------+
>:               :         :               :    +--->|    RtServices |
>:               :         :               :         |    Data       |
>|               |         |               |         +---------------+
>+---------------+         +---------------+         :     gap       :
>|               |         |               |         +---------------+
>| PE/COFF .text |         |    RtServices |-------->|    RtServices |
>|               |         |    Code       |         |    Code       |
>+- - - - - - - -+    =>   +---------------+         +---------------+
>|               |         |    RtServices |         :     gap       :
>| PE/COFF .data |         |    Data       |---+     +---------------+
>|               |         |               |   |     |    RtServices |
>+---------------+         +---------------+   +---->|    Data       |
>|               |         |               |         |               |
>:               :         :               :         +---------------+
>:               :         :               :         :               :
>:               :         :               :         :               :
>
>The illustration uses gaps, but obviously, this applies equally to
>inverting the mapping order, since the PE/COFF .text and .data
>sections will end up out of order.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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]

#1233287

From	Matt Fleming <matt@codeblueprint.co.uk>
Date	2015-09-26 22:00 +0200
Message-ID	<qd3Nw-1lI-29@gated-at.bofh.it>
In reply to	#1233243

On Sat, 26 Sep, at 10:20:22AM, H. Peter Anvin wrote:
>
> I think it "works" because the affected BIOSes don't put spaces
> between the chunks.  I have discussed this with Matt.

Right, that's very true. Though note that the current mapping
algorithm will handle a gap <= PMD_SIZE, it's just anything larger
than PMD_SIZE we "squash" to the next multiple of PMD_SIZE.

It's unclear whether the firmware toolchains would even support
references between sections with a PMD_SIZE gap between them, and I
think the firmware engineers would have to go out of their way to
actually insert such a gap.

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

#1233626

From	Ingo Molnar <mingo@kernel.org>
Date	2015-09-27 09:00 +0200
Message-ID	<qde6d-7Zc-5@gated-at.bofh.it>
In reply to	#1233232

* Andy Lutomirski <luto@amacapital.net> wrote:

> On Fri, Sep 25, 2015 at 10:56 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > So this commit worries me.
> >
> > This bug is a good find, and the fix is obviously needed and urgent, but I'm not
> > sure about the implementation at all. (I've Cc:-ed a few more x86 low level
> > gents.)
> >
> > * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> >> +             /*
> >> +              * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
> >> +              * config table feature requires us to map all entries
> >> +              * in the same order as they appear in the EFI memory
> >> +              * map. That is to say, entry N must have a lower
> >> +              * virtual address than entry N+1. This is because the
> >> +              * firmware toolchain leaves relative references in
> >> +              * the code/data sections, which are split and become
> >> +              * separate EFI memory regions. Mapping things
> >> +              * out-of-order leads to the firmware accessing
> >> +              * unmapped addresses.
> >> +              *
> 
> I'm clearly missing something.  What is EFI doing that it doesn't care how big 
> the gap between sections is but it still requires them to be in order?  It's not 
> as though x86_64 has an addressing mode that allows only non-negative offsets.

It appears the problem is that what we think to be 'different sections' are in 
reality smaller parts of the same section.

Any relative address calculation will be broken if we don't preserve the relative 
positions of these sections/sub-sections. Any CPU that supports addition is 
affected, it doesn't need any special addressing modes.

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]

#1237397 — [tip:core/urgent] x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down

From	tip-bot for Matt Fleming <tipbot@zytor.com>
Date	2015-10-01 15:00 +0200
Subject	[tip:core/urgent] x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
Message-ID	<qeLCN-4xp-15@gated-at.bofh.it>
In reply to	#1233090

Commit-ID:  a5caa209ba9c29c6421292e7879d2387a2ef39c9
Gitweb:     http://git.kernel.org/tip/a5caa209ba9c29c6421292e7879d2387a2ef39c9
Author:     Matt Fleming <matt.fleming@intel.com>
AuthorDate: Fri, 25 Sep 2015 23:02:18 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 1 Oct 2015 12:51:28 +0200

x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down

Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
that signals that the firmware PE/COFF loader supports splitting
code and data sections of PE/COFF images into separate EFI
memory map entries. This allows the kernel to map those regions
with strict memory protections, e.g. EFI_MEMORY_RO for code,
EFI_MEMORY_XP for data, etc.

Unfortunately, an unwritten requirement of this new feature is
that the regions need to be mapped with the same offsets
relative to each other as observed in the EFI memory map. If
this is not done crashes like this may occur,

  BUG: unable to handle kernel paging request at fffffffefe6086dd
  IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
  Call Trace:
   [<ffffffff8104c90e>] efi_call+0x7e/0x100
   [<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
   [<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
   [<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
   [<ffffffff81f37e1b>] start_kernel+0x38a/0x417
   [<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
   [<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef

Here 0xfffffffefe6086dd refers to an address the firmware
expects to be mapped but which the OS never claimed was mapped.
The issue is that included in these regions are relative
addresses to other regions which were emitted by the firmware
toolchain before the "splitting" of sections occurred at
runtime.

Needless to say, we don't satisfy this unwritten requirement on
x86_64 and instead map the EFI memory map entries in reverse
order. The above crash is almost certainly triggerable with any
kernel newer than v3.13 because that's when we rewrote the EFI
runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping"). For kernel versions before
v3.13 things may work by pure luck depending on the
fragmentation of the kernel virtual address space at the time we
map the EFI regions.

Instead of mapping the EFI memory map entries in reverse order,
where entry N has a higher virtual address than entry N+1, map
them in the same order as they appear in the EFI memory map to
preserve this relative offset between regions.

This patch has been kept as small as possible with the intention
that it should be applied aggressively to stable and
distribution kernels. It is very much a bugfix rather than
support for a new feature, since when EFI_PROPERTIES_TABLE is
enabled we must map things as outlined above to even boot - we
have no way of asking the firmware not to split the code/data
regions.

In fact, this patch doesn't even make use of the more strict
memory protections available in UEFI v2.5. That will come later.

Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Chun-Yi <jlee@suse.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: James Bottomley <JBottomley@Odin.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/platform/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 1db84c0..6a28ded 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -705,6 +705,70 @@ out:
 }
 
 /*
+ * Iterate the EFI memory map in reverse order because the regions
+ * will be mapped top-down. The end result is the same as if we had
+ * mapped things forward, but doesn't require us to change the
+ * existing implementation of efi_map_region().
+ */
+static inline void *efi_map_next_entry_reverse(void *entry)
+{
+	/* Initial call */
+	if (!entry)
+		return memmap.map_end - memmap.desc_size;
+
+	entry -= memmap.desc_size;
+	if (entry < memmap.map)
+		return NULL;
+
+	return entry;
+}
+
+/*
+ * efi_map_next_entry - Return the next EFI memory map descriptor
+ * @entry: Previous EFI memory map descriptor
+ *
+ * This is a helper function to iterate over the EFI memory map, which
+ * we do in different orders depending on the current configuration.
+ *
+ * To begin traversing the memory map @entry must be %NULL.
+ *
+ * Returns %NULL when we reach the end of the memory map.
+ */
+static void *efi_map_next_entry(void *entry)
+{
+	if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
+		/*
+		 * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
+		 * config table feature requires us to map all entries
+		 * in the same order as they appear in the EFI memory
+		 * map. That is to say, entry N must have a lower
+		 * virtual address than entry N+1. This is because the
+		 * firmware toolchain leaves relative references in
+		 * the code/data sections, which are split and become
+		 * separate EFI memory regions. Mapping things
+		 * out-of-order leads to the firmware accessing
+		 * unmapped addresses.
+		 *
+		 * Since we need to map things this way whether or not
+		 * the kernel actually makes use of
+		 * EFI_PROPERTIES_TABLE, let's just switch to this
+		 * scheme by default for 64-bit.
+		 */
+		return efi_map_next_entry_reverse(entry);
+	}
+
+	/* Initial call */
+	if (!entry)
+		return memmap.map;
+
+	entry += memmap.desc_size;
+	if (entry >= memmap.map_end)
+		return NULL;
+
+	return entry;
+}
+
+/*
  * Map the efi memory ranges of the runtime services and update new_mmap with
  * virtual addresses.
  */
@@ -714,7 +778,8 @@ static void * __init efi_map_regions(int *count, int *pg_shift)
 	unsigned long left = 0;
 	efi_memory_desc_t *md;
 
-	for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+	p = NULL;
+	while ((p = efi_map_next_entry(p))) {
 		md = p;
 		if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
 #ifdef CONFIG_X86_64
--
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]

#1238069 — Re: [tip:core/urgent] x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down

From	Matt Fleming <matt@codeblueprint.co.uk>
Date	2015-10-02 11:50 +0200
Subject	Re: [tip:core/urgent] x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
Message-ID	<qf58t-83i-1@gated-at.bofh.it>
In reply to	#1237397

On Thu, 01 Oct, at 05:48:43AM, tip-bot for Matt Fleming wrote:
> Commit-ID:  a5caa209ba9c29c6421292e7879d2387a2ef39c9
> Gitweb:     http://git.kernel.org/tip/a5caa209ba9c29c6421292e7879d2387a2ef39c9
> Author:     Matt Fleming <matt.fleming@intel.com>
> AuthorDate: Fri, 25 Sep 2015 23:02:18 +0100
> Committer:  Ingo Molnar <mingo@kernel.org>
> CommitDate: Thu, 1 Oct 2015 12:51:28 +0200
> 
> x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
> 
> Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
> that signals that the firmware PE/COFF loader supports splitting
> code and data sections of PE/COFF images into separate EFI
> memory map entries. This allows the kernel to map those regions
> with strict memory protections, e.g. EFI_MEMORY_RO for code,
> EFI_MEMORY_XP for data, etc.
> 
> Unfortunately, an unwritten requirement of this new feature is
> that the regions need to be mapped with the same offsets
> relative to each other as observed in the EFI memory map. If
> this is not done crashes like this may occur,
> 
>   BUG: unable to handle kernel paging request at fffffffefe6086dd
>   IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
>   Call Trace:
>    [<ffffffff8104c90e>] efi_call+0x7e/0x100
>    [<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
>    [<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
>    [<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
>    [<ffffffff81f37e1b>] start_kernel+0x38a/0x417
>    [<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
>    [<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
> 
> Here 0xfffffffefe6086dd refers to an address the firmware
> expects to be mapped but which the OS never claimed was mapped.
> The issue is that included in these regions are relative
> addresses to other regions which were emitted by the firmware
> toolchain before the "splitting" of sections occurred at
> runtime.
> 
> Needless to say, we don't satisfy this unwritten requirement on
> x86_64 and instead map the EFI memory map entries in reverse
> order. The above crash is almost certainly triggerable with any
> kernel newer than v3.13 because that's when we rewrote the EFI
> runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
> Runtime services virtual mapping"). For kernel versions before
> v3.13 things may work by pure luck depending on the
> fragmentation of the kernel virtual address space at the time we
> map the EFI regions.
> 
> Instead of mapping the EFI memory map entries in reverse order,
> where entry N has a higher virtual address than entry N+1, map
> them in the same order as they appear in the EFI memory map to
> preserve this relative offset between regions.
> 
> This patch has been kept as small as possible with the intention
> that it should be applied aggressively to stable and
> distribution kernels. It is very much a bugfix rather than
> support for a new feature, since when EFI_PROPERTIES_TABLE is
> enabled we must map things as outlined above to even boot - we
> have no way of asking the firmware not to split the code/data
> regions.
> 
> In fact, this patch doesn't even make use of the more strict
> memory protections available in UEFI v2.5. That will come later.
> 
> Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
> Cc: <stable@vger.kernel.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Chun-Yi <jlee@suse.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: James Bottomley <JBottomley@Odin.com>
> Cc: Lee, Chun-Yi <jlee@suse.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Matthew Garrett <mjg59@srcf.ucam.org>
> Cc: Mike Galbraith <efault@gmx.de>
> Cc: Peter Jones <pjones@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-kernel@vger.kernel.org
> Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk
> Signed-off-by: Ingo Molnar <mingo@kernel.org>

It's probably a little late to change this now, but I just realised
that I dropped Joey's Tested-by tags from this patch. Sorry Joey!

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

Page 2 of 2 — ← Prev page 1 [2]

csiph-web

[PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

Contents

#1233873

#1233895

#1235573

#1235936

#1236532

#1236569

#1235679

#1233286

#1233287

#1233626

#1237397 — [tip:core/urgent] x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down

#1238069 — Re: [tip:core/urgent] x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down