EFI 1:1 mapping

Pointers in the efi_runtime_services_t structure now have type "void *" (formerly they were "unsigned long"). So we now see a bunch of warnings like this:

arch/ia64/hp/sim/boot/fw-emu.c:293: warning: assignment makes pointer from integer without a cast

Add (void *) casts to the 10 affected lines to make the build quiet again.

Signed-off-by Tony Luck <[email protected]>

---

Boris, Matt - Can you add this patch to the same tree that

commit 43ab0476a648053e5998bf081f47f215375a4502 [linux-next id]
efi: Convert runtime services function ptrs

is in so that it will follow along behind it. Thanks.

 arch/ia64/hp/sim/boot/fw-emu.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

arch/ia64/hp/sim/boot/fw-emu.c +10 -11

index 271f412..87bf9ad 100644
@@ -290,16 +290,16 @@ sys_fw_init (const char *args, int arglen)
        efi_runtime->hdr.signature = EFI_RUNTIME_SERVICES_SIGNATURE;
        efi_runtime->hdr.revision = EFI_RUNTIME_SERVICES_REVISION;
        efi_runtime->hdr.headersize = sizeof(efi_runtime->hdr);
-       efi_runtime->get_time = __pa(&fw_efi_get_time);
-       efi_runtime->set_time = __pa(&efi_unimplemented);
-       efi_runtime->get_wakeup_time = __pa(&efi_unimplemented);
-       efi_runtime->set_wakeup_time = __pa(&efi_unimplemented);
-       efi_runtime->set_virtual_address_map = __pa(&efi_unimplemented);
-       efi_runtime->get_variable = __pa(&efi_unimplemented);
-       efi_runtime->get_next_variable = __pa(&efi_unimplemented);
-       efi_runtime->set_variable = __pa(&efi_unimplemented);
-       efi_runtime->get_next_high_mono_count = __pa(&efi_unimplemented);
-       efi_runtime->reset_system = __pa(&efi_reset_system);
+       efi_runtime->get_time = (void *)__pa(&fw_efi_get_time);
+       efi_runtime->set_time = (void *)__pa(&efi_unimplemented);
+       efi_runtime->get_wakeup_time = (void *)__pa(&efi_unimplemented);
+       efi_runtime->set_wakeup_time = (void *)__pa(&efi_unimplemented);
+       efi_runtime->set_virtual_address_map = (void *)__pa(&efi_unimplemented);
+       efi_runtime->get_variable = (void *)__pa(&efi_unimplemented);
+       efi_runtime->get_next_variable = (void *)__pa(&efi_unimplemented);
+       efi_runtime->set_variable = (void *)__pa(&efi_unimplemented);
+       efi_runtime->get_next_high_mono_count = (void *)__pa(&efi_unimplemented);
+       efi_runtime->reset_system = (void *)__pa(&efi_reset_system);
 
        efi_tables->guid = SAL_SYSTEM_TABLE_GUID;
        efi_tables->table = __pa(sal_systab);
--

1.8.1.4

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

Oops - pasted in old e-mail address for Boris

From: Borislav Petkov <[email protected]>

Due to the braindead design of EFI, we cannot map runtime services more than once for the duration of a booted system. Thus, if we want to use EFI runtime services in a kexec'ed kernel, maybe the only possible and sensible approach would be to map them 1:1 so that when the kexec kernel loads, it can simply call those addresses without the need for remapping (which doesn't work anyway).

Furthermore, this mapping approach could be of help with b0rked EFI implementations for a different set of reasons.

This implementation is 64-bit only for now.

Signed-off-by Borislav Petkov <[email protected]>

---
 arch/x86/include/asm/efi.h          |  67 +++++++++++----
 arch/x86/platform/efi/efi.c         | 165 +++++++++++++++++++++++++++++-------
 arch/x86/platform/efi/efi_stub_64.S |  56 ++++++++++++
 3 files changed, 240 insertions(+), 48 deletions(-)

From: Borislav Petkov <[email protected]>

Hi all,

this is just a snapshot of the current state of affairs. The patchset starts to boot successfully on real hardware now but we're far away from the coverage we'd like to have before we even consider upstreaming it.

And yes, considering the sick f*ck EFI is, we're keeping the 1:1 mapping optional and off by default (you need to boot with "efi=1:1_map" to enable it).

I hope making it a weird boot option is not the end plan, there's little point in _not_ enabling 1:1 mappings by default eventually:
the 1:1 mapping is supposed to emulate a "Windows compatible" EFI environment better and is expected to work around certain EFI runtime crashes.

Quoted 5 lines · Ingo Molnar

I hope making it a weird boot option is not the end plan, there's little point in _not_ enabling 1:1 mappings by default eventually:
the 1:1 mapping is supposed to emulate a "Windows compatible" EFI environment better and is expected to work around certain EFI runtime crashes.

And yet there are the Macs which reportedly cannot stomach this.

And then there's the issue where some boxes cannot boot through the EFI stub with those patches even without "efi=1:1_map" on the command line. The issue has something to do with the "cmpb $0, efi_use_11_map" in the efi_callX stubs.

And then again, other boxes have no problem with it and boot perfectly fine.

So I don't know - it all looks like a weird boot, opt-in option for now.

Do we know why?

A bug I suspect?

But once it works reliably we can enable it, right?

Quoted 1 line · Borislav Petkov

And yet there are the Macs which reportedly cannot stomach this.

Do we know why?

But, as always, the only reliable thing to do here is to behave as much like Windows as possible. Which means performing the 1:1 mapping but maintaining the high mapping, and passing the high values via SetVirtualAddressMap.

Quoted 4 lines · Matthew Garrett

But, as always, the only reliable thing to do here is to behave as much like Windows as possible. Which means performing the 1:1 mapping but maintaining the high mapping, and passing the high values via SetVirtualAddressMap.

We can't pass the high values via SetVirtualAddressMap and have EFI runtime in the kexec-ed kernel, as you and I established last week. And since not all would want EFI runtime in the kexec-ed kernel, I'm leaning more towards a boot-time option which enables the 1:1 mapping.

Btw, why would you even want the 1:1 mappings if we pass the high values via SetVirtualAddressMap?

Yes, kexec needs a different solution.

Because firmware images don't always update all of the pointers, and so will crash if the 1:1 mappings aren't present.

Quoted 1 line · Matthew Garrett

Yes, kexec needs a different solution.

No need. If we say, "efi=use_11_map", the 1:1 map will be shoved down SetVirtualAddressMap. Otherwise the high mappings.

Quoted 2 lines

Because firmware images don't always update all of the pointers, and so will crash if the 1:1 mappings aren't present.

Ok, so it sounds like we want to *always* create both mappings but, depending on what we want, to shove down SetVirtualAddressMap a different set. And the 1:1 map will be the optional one which we give SetVirtualAddressMap only when user wants it, i.e. when booting with "efi=1:1_map".

Quoted 5 lines

Ok, so it sounds like we want to *always* create both mappings but, depending on what we want, to shove down SetVirtualAddressMap a different set. And the 1:1 map will be the optional one which we give SetVirtualAddressMap only when user wants it, i.e. when booting with "efi=1:1_map".

Yup, I think that sounds ideal.

Quoted 7 lines · Matthew Garrett

Quoted 5 lines

Ok, so it sounds like we want to *always* create both mappings but, depending on what we want, to shove down SetVirtualAddressMap a different set. And the 1:1 map will be the optional one which we give SetVirtualAddressMap only when user wants it, i.e. when booting with "efi=1:1_map".

Yup, I think that sounds ideal.

Crap, I got completely sidetracked. The 1:1 mappings go in a different pagetable (real_mode_header->trampoline_pgd) than the kernel one (i.e. init_mm.pgd). However, the ->trampoline_pgd has all mappings anyway, which means that if we want to do EFI runtime calls with the high mappings but *also* have the 1:1 mappings established, we should *always* switch to that pagetable when doing those calls.

hpa, MattF, agreed?

Quoted 7 lines · Matthew Garrett

Quoted 5 lines

Ok, so it sounds like we want to *always* create both mappings but, depending on what we want, to shove down SetVirtualAddressMap a different set. And the 1:1 map will be the optional one which we give SetVirtualAddressMap only when user wants it, i.e. when booting with "efi=1:1_map".

Yup, I think that sounds ideal.

Crap, I got completely sidetracked. The 1:1 mappings go in a different pagetable (real_mode_header->trampoline_pgd) than the kernel one (i.e. init_mm.pgd). However, the ->trampoline_pgd has all mappings anyway, which means that if we want to do EFI runtime calls with the high mappings but *also* have the 1:1 mappings established, we should *always* switch to that pagetable when doing those calls.

hpa, MattF, agreed?

Quoted 1 line · Matthew Garrett

Yes, kexec needs a different solution.

No need. If we say, "efi=use_11_map", the 1:1 map will be shoved down SetVirtualAddressMap. Otherwise the high mappings.

Quoted 2 lines

Because firmware images don't always update all of the pointers, and so will crash if the 1:1 mappings aren't present.

Ok, so it sounds like we want to *always* create both mappings but, depending on what we want, to shove down SetVirtualAddressMap a different set. And the 1:1 map will be the optional one which we give SetVirtualAddressMap only when user wants it, i.e. when booting with "efi=1:1_map".

Makes sense?

Quoted 4 lines · Ingo Molnar

Quoted 1 line · Borislav Petkov

And yet there are the Macs which reportedly cannot stomach this.

Do we know why?

I got lost in a maze of pointer arithmetic. There seems to be an assumption that nvram writes should be forbidden if in runtime mode but with pointers still below the phys/virt split, which obviously makes no sense but hey.

But, as always, the only reliable thing to do here is to behave as much like Windows as possible. [...]

[...] Which means performing the 1:1 mapping but maintaining the high mapping, and passing the high values via SetVirtualAddressMap.

Cool - and supposedly this will work in a Mac environment as well? Would be very nice to avoid fundamentally fragile system specific quirks for something as fundamental as the EFI runtime memory mapping model ...

Quoted 3 lines · Ingo Molnar

Cool - and supposedly this will work in a Mac environment as well? Would be very nice to avoid fundamentally fragile system specific quirks for something as fundamental as the EFI runtime memory mapping model ...

Apple is the only case where I'd expect there to be an issue, since they only started supporting booting Windows via UEFI on very recent systems. However, unless they're actually sniffing the page tables on UEFI entry, I can't see any way that this could break things???

Quoted 8 lines

Quoted 3 lines

Cool - and supposedly this will work in a Mac environment as well? Would be very nice to avoid fundamentally fragile system specific quirks for something as fundamental as the EFI runtime memory mapping model ...

Apple is the only case where I'd expect there to be an issue, since they only started supporting booting Windows via UEFI on very recent systems. However, unless they're actually sniffing the page tables on UEFI entry, I can't see any way that this could break things???

Agreed - I was susprised to see that the runtime was able to _break_ in any way due to 1:1: my assumption was that it can only get better.

But I did not realize that the 1:1 boot flag also changed what was passed down, which probably explains the breakages.

I'd even argue to not do this whole boot flag thing at all - just standardize on the Windows compatibility model as closely as possible.

This will break the Macs so maybe we can do

efi=no_11_map

so the Macs can still boot but use the 1:1 map by default.

Quoted 5 lines

This will break the Macs so maybe we can do

efi=no_11_map

so the Macs can still boot but use the 1:1 map by default.

I'm going to guess that there are more people running unmodified Linux kernels on Macs than there are people using kexec,

Quoted 5 lines · Borislav Petkov

This will break the Macs so maybe we can do

efi=no_11_map

so the Macs can still boot but use the 1:1 map by default.

I'm going to guess that there are more people running unmodified Linux kernels on Macs than there are people using kexec, so just pass the high maps by default and let the enterprise kernels that care about kexec do something different.

Can't we detect Macs from some of the UEFI strings at boot time and do the right thing with the boot switch (which can be overriden from the kernel command line if we get it wrong)?

Quoted 3 lines

Can't we detect Macs from some of the UEFI strings at boot time and do the right thing with the boot switch (which can be overriden from the kernel command line if we get it wrong)?

Yes, and then our behaviour differs from Windows

So if we properly detect those (and only those), we mimic Windows completely, right?

Quoted 3 lines · James Bottomley

Can't we detect Macs from some of the UEFI strings at boot time and do the right thing with the boot switch (which can be overriden from the kernel command line if we get it wrong)?

Yes, and then our behaviour differs from Windows and so we'll have inevitably broken some other system.

Unless you can think of the way out of this, we seem to have the stark choice of behave like windows or allow kexec. For the server market, kexec wins, so either we find a way not to have to make the choice or we do something automatic to make it fairly painless.

Quoted 4 lines · James Bottomley

Unless you can think of the way out of this, we seem to have the stark choice of behave like windows or allow kexec. For the server market, kexec wins, so either we find a way not to have to make the choice or we do something automatic to make it fairly painless.

hpa suggested ensuring that UEFI regions are mapped at fixed high offsets. Someone who cares about kexec should probably make that happen.

If we can detect the Macs, we can make this decision automatic. And since no Mac boots windoze, a single DMI check of the sort "if (Mac)" should suffice.

Quoted 3 lines · Borislav Petkov

If we can detect the Macs, we can make this decision automatic. And since no Mac boots windoze, a single DMI check of the sort "if (Mac)" should suffice.

Yes, we can special-case Macs. But since our behaviour is then obviously different to Windows, we'll inevitably break some other system.

Quoted 6 lines · Matthew Garrett

Quoted 3 lines · Borislav Petkov

If we can detect the Macs, we can make this decision automatic. And since no Mac boots windoze, a single DMI check of the sort "if (Mac)" should suffice.

Quoted 2 lines

Yes, we can special-case Macs. But since our behaviour is then obviously different to Windows, we'll inevitably break some other system.

Why different? We'll have the high mappings and shove the 1:1 mappings down SetVirtualAddressMap by default.

Because Windows passes high addresses to SetVirtualAddressMap(), and because if you can imagine firmware developers getting it wrong then firmware developers will have got it wrong.

Quoted 3 lines · Matthew Garrett

Because Windows passes high addresses to SetVirtualAddressMap(), and because if you can imagine firmware developers getting it wrong then firmware developers will have got it wrong.

Can we reversely assume that if we'd used fixed high offsets, as hpa suggests, then it'll be fine? IOW, are any high addresses, even fixed ones, fine?

Quoted 8 lines · Borislav Petkov

Quoted 3 lines · Matthew Garrett

Because Windows passes high addresses to SetVirtualAddressMap(), and because if you can imagine firmware developers getting it wrong then firmware developers will have got it wrong.

Can we reversely assume that if we'd used fixed high offsets, as hpa suggests, then it'll be fine? IOW, are any high addresses, even fixed ones, fine?

Windows actually seems to start at the top of address space and go down
- this is what I get booting Windows 8 under kvm. It looks like very high addresses are fine, and we're currently using "low" high addresses, so I suspect we're fine pretty much anywhere in that range.

****** SetVirtualAddressMap
Type: 5
Physical Start: 3E878000
Virtual Start: FFFFFFFFFFBEB000
Number Of Pages: 15
Attributes: 800000000000000F
Type: 6
Physical Start: 3E88D000
Virtual Start: FFFFFFFFFFBD6000
Number Of Pages: 15
Attributes: 800000000000000F
Type: 5
Physical Start: 3FB22000
Virtual Start: FFFFFFFFFFBA6000
Number Of Pages: 30
Attributes: 800000000000000F
Type: 6

Physical Start: 3FB52000
Virtual Start: FFFFFFFFFFB82000
Number Of Pages: 24
Attributes: 800000000000000F
Type: 6
Physical Start: 3FFE0000
Virtual Start: FFFFFFFFFFB62000
Number Of Pages: 20

I guess we can do a top-down allocation, starting from the highest virtual addresses:

EFI_HIGHEST_ADDRESS

|
| size1
|
--> region1
|
| size2
|

--> region2

...

and we make EFI_HIGHEST_ADDRESS be the same absolute number on every system.

hpa, is this close to what you had in mind? It would be prudent to verify whether this will suit well with the kexec virtual space layout though...

Quoted 14 lines · Borislav Petkov

I guess we can do a top-down allocation, starting from the highest virtual addresses:

EFI_HIGHEST_ADDRESS

|
| size1
|
--> region1
|
| size2
|

--> region2

Quoted 9 lines

...

and we make EFI_HIGHEST_ADDRESS be the same absolute number on every system.

hpa, is this close to what you had in mind? It would be prudent to verify whether this will suit well with the kexec virtual space layout though...

This would work really well, I think. The tricky part here is to pick a safe EFI_HIGHEST_ADDRESS as it is an ABI.

My preference would be to make EFI_HIGHEST_ADDRESS = -4 GB, which is *not* what Windows uses, but will leave the high negative range clear, and allows a range where we can grow down without much risk of interfering with anything else.

Quoted 15 lines · H. Peter Anvin

Quoted 14 lines · Borislav Petkov

I guess we can do a top-down allocation, starting from the highest virtual addresses:

EFI_HIGHEST_ADDRESS

|
| size1
|
--> region1
|
| size2
|

--> region2

Quoted 3 lines

Quoted 3 lines

...

and we make EFI_HIGHEST_ADDRESS be the same absolute number on

every

Quoted 4 lines

Quoted 4 lines

system.

hpa, is this close to what you had in mind? It would be prudent to verify whether this will suit well with the kexec virtual space

layout

Quoted 4 lines

Quoted 2 lines

though...

This would work really well, I think. The tricky part here is to

pick a

Quoted 4 lines

safe EFI_HIGHEST_ADDRESS as it is an ABI.

My preference would be to make EFI_HIGHEST_ADDRESS = -4 GB, which is *not* what Windows uses, but will leave the high negative range

clear,

Quoted 2 lines

and allows a range where we can grow down without much risk of interfering with anything else.

Hmm, cool. Let me see whether my primitive math still has it:

-(4 << 30) = 0xffffffff00000000.

Staring at Documentation/x86/x86_64/mm.txt, that's right in the unused hole, sandwiched between:

ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)

xxxxxxxxxxxxxxxx - ffffffff00000000 (=XX bits, not a lot :-), maybe 4, i.e. 64G) EFI

ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0

Now, if we go and do that, what are we going to say for the lower bound,
in case later someone wants to use some more of the rest of the unused hole? Should we limit it to say

0xffffffff00000000 -
0xfffffff000000000 = 64G max EFI mappable region.

Or am I too generous? The remaining hole is around

(0xfffffff000000000 - 0xffffeaffffffffff) >> 40 = 20TB.

Thanks.

If you cap it you are basically imposing a constraint on the firmware and may not run properly (or at least have to turn off EFI runtime calls with all that implies.)

It might be good to have a sanity check but it needs to be pretty generous.

Quoted 3 lines · H. Peter Anvin

If you cap it you are basically imposing a constraint on the firmware and may not run properly (or at least have to turn off EFI runtime calls with all that implies.)

I don't want to cap EFI just for the fun of it but rather set a limit so that the next one who wants a chunk of the virtual address space can have a reliable limit from where she/he can start. Otherwise we won't know where EFI reliably ends...

Quoted 2 lines

It might be good to have a sanity check but it needs to be pretty generous.

64 Gb generous enough?

Quoted 10 lines · Borislav Petkov

Quoted 3 lines · H. Peter Anvin

If you cap it you are basically imposing a constraint on the firmware and may not run properly (or at least have to turn off EFI runtime calls with all that implies.)

I don't want to cap EFI just for the fun of it but rather set a limit so that the next one who wants a chunk of the virtual address space can have a reliable limit from where she/he can start. Otherwise we won't know where EFI reliably ends...

We don't... and I don't think there is anything we can do about it. If some messed-up firmware wants to map a terabyte we either refuse and don't allow EFI runtime calls on that machine or we accept it.

Fortunately the space is extremely large and with growing down from a known address it is less likely that we'll conflict with something.

Quoted 5 lines · Ingo Molnar

I hope making it a weird boot option is not the end plan, there's little point in _not_ enabling 1:1 mappings by default eventually:
the 1:1 mapping is supposed to emulate a "Windows compatible" EFI environment better and is expected to work around certain EFI runtime crashes.

And yet there are the Macs which reportedly cannot stomach this.

And yet there are the Macs which reportedly cannot stomach this.

Quoted 3 lines · Borislav Petkov

And yet there are the Macs which reportedly cannot stomach this.

No, the reports are that if you use the 1:1 map as the primary address on Macs the drivers fail... not that you can't have a 1:1 map.

Quoted 6 lines · H. Peter Anvin

Quoted 3 lines · Borislav Petkov

And yet there are the Macs which reportedly cannot stomach this.

No, the reports are that if you use the 1:1 map as the primary address on Macs the drivers fail... not that you can't have a 1:1 map.

That's what I meant: ... cannot stomach when the 1:1 map is shoved down SetVirtualAddressMap.

The thing is, if we want to have both the 1:1 map and the high map during an EFI runtime call, we would need to *always* switch the pagetable for an EFI runtime call and establish both mappings in ->trampoline_pgd beforehand.

I thought that was the plan?