Re: [PATCH] x86, efi: retry ExitBootServices() on failure
The 0xa restriction applies to BIOS really... m...@console-pimps.org m...@console-pimps.org wrote: On Tue, 18 Jun, at 10:12:22PM, Zachary Bobroff wrote: Okay, I'm fine with that aspect then. Let's hope everyone plays by that rule. This is all according to specification, so if they are not following these rules they should be corrected. The link to where the current public version of the specification is available is here: http://www.uefi.org/specs/agreement While I agree that the vendor should be informed if their implementation deviates from the spec in some way, the Linux kernel usually still needs to support these nonconforming machines once they end up in the hands of consumers (which is often the point at which we discover these kinds of issues). Sadly, we're still not in a position where firmware updates can be applied from OEMs ubiquitously, either because machines are End of Life'd or because the update needs to be run from Windows. We tend to adopt the approach of: let's try this until we get reports of a class of machines where this solution doesn't work. Though I do find it refreshing to hear engineers talking about the UEFI spec in such black and white terms. That is certainly the ideal we should be aiming for. Why by one? Splitting some 'free memory' block may result in an increase by more then one afaict. Assuming the increment can only be one is implying you having knowledge of the allocator implementation and behavior, which shouldn't be made use of in kernel code. We had to actually increment it by two to get it to work correctly. This is all based upon the use of the low_alloc routine in the linux kernel file. I agree there is still some outstanding issue based upon this, but we put it through several different types of tests and it continued to work correctly. The truest solution would be to us the AllocateMaxAddress parameter when using AllocatePages. [...] It was my understanding that the point of this was to allocate the memory map below a certain address in memory because the kernel required it. Matt, can you comment here? I am not aware of what address it needs to be below, but using this function should do the trick. Also, if you want to inform me better of what memory ceiling restrictions there are at this early stage of the kernel, I can rewrite the file without the need of the low_alloc routine entirely. The most important restriction is that all allocations in the EFI boot stub need to be below the 1GB mark, because only the first 1GB of virtual memory is mapped, unless certain flags are set in the xloadflags field of the boot_params header. See Documentation/x86/boot.txt. Further to that, I think I remember some restrictions on the location of the cmdline pointer - that it needs to be below 0xa. Again, Documentation/x86/boot.xt should have all the info you need. -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
* Borislav Petkov b...@alien8.de wrote: From: Borislav Petkov b...@suse.de 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. Looks pretty clean. 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. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote: 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. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
* Borislav Petkov b...@alien8.de wrote: On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote: 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. Do we know why? 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. A bug I suspect? 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. But once it works reliably we can enable it, right? Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote: Do we know why? Well, according to mjg59 some Macs break if we don't give them a map which uses high addresses. I can imagine flipping the meaning of this option to be on by default and efi=no_11_map to disable the 1:1 map for those Macs. A bug I suspect? Probably. The problem is, it is very hard to debug the boot stub that early. And of course, I can't reproduce it in qemu :(. If only I had a hardware debugger... But once it works reliably we can enable it, right? It's all the same to me - I hate EFI with passion so whatever people agree upon, I'll do it. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 03:02:25PM +0200, Borislav Petkov wrote: On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote: 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. I suspect they'll be fine with having a 1:1 map, as long as we pass the high mappings via SetVirtualAddressMap(). -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote: * Borislav Petkov b...@alien8.de wrote: 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. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 05:08:04PM +0100, Matthew Garrett wrote: 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? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 06:18:27PM +0200, Borislav Petkov wrote: On Wed, Jun 19, 2013 at 05:08:04PM +0100, Matthew Garrett wrote: 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. Yes, kexec needs a different solution. Btw, why would you even want the 1:1 mappings if we pass the high values via SetVirtualAddressMap? Because firmware images don't always update all of the pointers, and so will crash if the 1:1 mappings aren't present. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On Wed, 2013-06-19 at 18:38 +0200, Borislav Petkov wrote: On Wed, Jun 19, 2013 at 05:21:15PM +0100, Matthew Garrett wrote: 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. 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? I think it will work. The only thing I'd worry about is aliasing. This scheme clearly won't work for any virtually indexed processor (so it's basically x86 only) but even on Physically Indexed, you do have to make sure the cache attributes of any given page are the same for all virtual address aliases. As long as the 1:1 mapping is writeback, I think this is satisfied. James -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 05:48:22PM +0100, Matthew Garrett wrote: 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? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On 06/19/2013 08:02 AM, Borislav Petkov wrote: 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. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 12:25:42PM -0500, H. Peter Anvin wrote: On 06/19/2013 08:02 AM, Borislav Petkov wrote: 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. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On 06/19/2013 12:37 PM, Borislav Petkov wrote: On Wed, Jun 19, 2013 at 12:25:42PM -0500, H. Peter Anvin wrote: On 06/19/2013 08:02 AM, Borislav Petkov wrote: 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? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2 0/4] EFI 1:1 mapping
On Wed, Jun 19, 2013 at 12:38:24PM -0500, H. Peter Anvin wrote: I thought that was the plan? Well, currently if I'm booted with efi=1:1_map I'm creating only the 1:1 mapping in -trampoline_pgd and switching the pagetable only then. Otherwise, I'm using the high, ioremapped mappings - i.e., what we have now. I guess I can sync the kernel address space into -trampoline_pgd after having created the 1:1 mappings and always switch the pagetable later, after we've done SetVirtualAddressMap. Which should take care of the EFI boot stub issue too, as I can define another set of efi_callX which switch the pagetable unconditionally. Let me see how that pans out... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
