Re: [PATCH 00/11] EFI runtime services virtual mapping, vN++
On Thu, 31 Oct, at 05:24:58PM, Borislav Petkov wrote: From: Borislav Petkov b...@suse.de Hi all, here's maybe the final version of the patchset, no major changes since the last time but cosmetic and cleanups and tidying as requested by Matt and others. Patches also at: git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git#efi Thanks Borislav, I've merged this version in the EFI 'next' branch to queue up for v3.14. Good work! -- Matt Fleming, Intel Open Source Technology Center -- 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
[PATCH 00/11] EFI runtime services virtual mapping, vN++
From: Borislav Petkov b...@suse.de Hi all, here's maybe the final version of the patchset, no major changes since the last time but cosmetic and cleanups and tidying as requested by Matt and others. Patches also at: git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git#efi The previous announcement: here's finally a new version of the runtime services VA mapping patchset which hopefully implements hpa's idea of statically mapping EFI runtime regions in a top-down manner starting at -4Gb virtual. We're also using a different pagetable so as not to pollute kernel address space. For that, we switch to that table before doing an EFI call, and afterwards we switch back to the previous one. To the patches: 1-2 are simple cleanups which Matt probably can take now 3-10 add the machinery to map regions into an arbitrary PGD. Those I've split deliberately into very small bites so that they can be reviewed more thoroughly and easily for my pagetable skills are pretty basic. 11 is the actual patch which implements that mapping so that we can use runtime services in kexec (which is the whole reason for this fuss :)) So please take a long hard look at those, hammer on them on your boxes and let me know. They boot fine on my Dell UEFI box and in OVMF (obviously :)). Borislav Petkov (11): efi: Simplify EFI_DEBUG x86, pageattr: Lookup address in an arbitrary PGD x86, pageattr: Add a PGD pagetable populating function x86, pageattr: Add a PUD pagetable populating function x86, pageattr: Add a PMD pagetable populating function x86, pageattr: Add a PTE pagetable populating function x86, pageattr: Add a PUD error unwinding path x86, pageattr: Add last levels of error path x86, cpa: Map in an arbitrary pgd EFI: Runtime services virtual mapping efi: Check krealloc return value Documentation/kernel-parameters.txt | 6 + Documentation/x86/x86_64/mm.txt | 7 + arch/x86/include/asm/efi.h | 64 +++-- arch/x86/include/asm/pgtable_types.h | 3 +- arch/x86/mm/pageattr.c | 461 +-- arch/x86/platform/efi/efi.c | 111 ++--- arch/x86/platform/efi/efi_32.c | 9 +- arch/x86/platform/efi/efi_64.c | 109 + arch/x86/platform/efi/efi_stub_64.S | 54 include/linux/efi.h | 1 + 10 files changed, 755 insertions(+), 70 deletions(-) -- 1.8.4 -- 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 00/11] EFI runtime services virtual mapping
On Tue, 08 Oct, at 06:45:51PM, Borislav Petkov wrote: @@ -141,34 +151,75 @@ static long efi_runtime_ioctl(struct file *file, unsigned int cmd, return -EFAULT; convert_from_guid(vendor, vendor_guid); - status = efi.get_variable(pgetvariable-VariableName, vendor, - attr, datasize, pgetvariable-Data); + + vardata = kmalloc(datasize, GFP_KERNEL); + if (!vardata) + return -ENOMEM; + + namelen = ucs2_strsize(pgetvariable-VariableName, 1024); + + varname = kmalloc(namelen, GFP_KERNEL); + if (!varname) + return -ENOMEM; + + if (copy_from_user(varname, pgetvariable-VariableName, namelen)) + return -EFAULT; + varname = kmalloc(namelen + 1, GFP_KERNEL); varname[namelen] = 0; Note that ucs2_strsize() doesn't count the terminating NUL. -- Matt Fleming, Intel Open Source Technology Center -- 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 00/11] EFI runtime services virtual mapping
On 09/19/13 at 04:54pm, Borislav Petkov wrote: From: Borislav Petkov b...@suse.de Hi all, here's finally a new version of the runtime services VA mapping patchset which hopefully implements hpa's idea of statically mapping EFI runtime regions in a top-down manner starting at -4Gb virtual. We're also using a different pagetable so as not to pollute kernel address space. For that, we switch to that table before doing an EFI call, and afterwards we switch back to the previous one. To the patches: 1-2 are simple cleanups which Matt probably can take now 3-10 add the machinery to map regions into an arbitrary PGD. Those I've split deliberately into very small bites so that they can be reviewed more thoroughly and easily for my pagetable skills are pretty basic. 11 is the actual patch which implements that mapping so that we can use runtime services in kexec (which is the whole reason for this fuss :)) So please take a long hard look at those, hammer on them on your boxes and let me know. They boot fine on my Dell UEFI box and in OVMF (obviously :)). Thanks for your update! Just tested this series, for 1st kernel It boots ok in qemu+ovmf. But it immediately reboot on my Thinkpad T420. Unfortunately there's no way to debug this very early problem because there's no serial port also earlyprintk does not work for efi boot. No usb debug as well on this machine. I will test it when I go back to work after the china holiday. OTOH, for 2nd kernel testing because kexec tools does not fill efi_info[] in bootparam so kernel will disable efi, also it pass acpi_rsdp pointer automaticlly to make 2nd kernel boot ok. I tested with a user space patch which copy efi_info from 1st kernel to bootparams, as I said previously this is not enough because several fields in systab, fw_vendor, runtime and tables are converted to virtual address but in kernel efi init function they are assumed physical addresses. Thus we need save these physical address. I have a patch to save them and pass them to 2nd kernel in bootparams. Since the mapping are same, I wonder if we can calculate the physical address from virtual address. Idea? Another concern is that is it safe for i386 efi boot? Thanks. Borislav Petkov (11): efi: Simplify EFI_DEBUG efi: Remove EFI_PAGE_SHIFT and EFI_PAGE_SIZE x86, pageattr: Lookup address in an arbitrary PGD x86, pageattr: Add a PGD pagetable populating function x86, pageattr: Add a PUD pagetable populating function x86, pageattr: Add a PMD pagetable populating function x86, pageattr: Add a PTE pagetable populating function x86, pageattr: Add a PUD error unwinding path x86, pageattr: Add last levels of error path x86, cpa: Map in an arbitrary pgd EFI: Runtime services virtual mapping arch/x86/boot/compressed/eboot.c | 12 +- arch/x86/boot/compressed/eboot.h | 1 - arch/x86/include/asm/efi.h | 58 +++-- arch/x86/include/asm/pgtable_types.h | 3 +- arch/x86/mm/pageattr.c | 461 +-- arch/x86/platform/efi/efi.c | 126 +- arch/x86/platform/efi/efi_64.c | 56 + arch/x86/platform/efi/efi_stub_64.S | 47 include/linux/efi.h | 6 +- 9 files changed, 615 insertions(+), 155 deletions(-) -- 1.8.4 -- 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 00/11] EFI runtime services virtual mapping
On 09/20/13 at 03:29pm, Dave Young wrote: On 09/19/13 at 04:54pm, Borislav Petkov wrote: From: Borislav Petkov b...@suse.de Hi all, here's finally a new version of the runtime services VA mapping patchset which hopefully implements hpa's idea of statically mapping EFI runtime regions in a top-down manner starting at -4Gb virtual. We're also using a different pagetable so as not to pollute kernel address space. For that, we switch to that table before doing an EFI call, and afterwards we switch back to the previous one. To the patches: 1-2 are simple cleanups which Matt probably can take now 3-10 add the machinery to map regions into an arbitrary PGD. Those I've split deliberately into very small bites so that they can be reviewed more thoroughly and easily for my pagetable skills are pretty basic. 11 is the actual patch which implements that mapping so that we can use runtime services in kexec (which is the whole reason for this fuss :)) So please take a long hard look at those, hammer on them on your boxes and let me know. They boot fine on my Dell UEFI box and in OVMF (obviously :)). Thanks for your update! Just tested this series, for 1st kernel It boots ok in qemu+ovmf. But it immediately reboot on my Thinkpad T420. Unfortunately there's no way to debug this very early problem because there's no serial port also earlyprintk does not work for efi boot. No usb debug as well on this machine. I will test it when I go back to work after the china holiday. Actually the ovmf testing is qemu-system-x86_64 -kernel , boot from grub fails as well. Nothing printed on serial. I guess '-kernel' is using efi stub to boot? OTOH, for 2nd kernel testing because kexec tools does not fill efi_info[] in bootparam so kernel will disable efi, also it pass acpi_rsdp pointer automaticlly to make 2nd kernel boot ok. I tested with a user space patch which copy efi_info from 1st kernel to bootparams, as I said previously this is not enough because several fields in systab, fw_vendor, runtime and tables are converted to virtual address but in kernel efi init function they are assumed physical addresses. Thus we need save these physical address. I have a patch to save them and pass them to 2nd kernel in bootparams. Since the mapping are same, I wonder if we can calculate the physical address from virtual address. Idea? Another concern is that is it safe for i386 efi boot? -- 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 00/11] EFI runtime services virtual mapping
On Fri, Sep 20, 2013 at 03:29:04PM +0800, Dave Young wrote: Just tested this series, for 1st kernel It boots ok in qemu+ovmf. But it immediately reboot on my Thinkpad T420. Unfortunately there's no way to debug this very early problem because there's no serial port also earlyprintk does not work for efi boot. No usb debug as well on this machine. I will test it when I go back to work after the china holiday. Hmm, I'm booting with the efi boot stub, how do you do it? OTOH, for 2nd kernel testing because kexec tools does not fill efi_info[] in bootparam so kernel will disable efi, also it pass acpi_rsdp pointer automaticlly to make 2nd kernel boot ok. Right, the way this could be done is to pass in efi_info.efi_memmap, i.e. the physical map and then iterate over it and compute the virtual addresses *without* calling phys_efi_set_virtual_address_map() - they are stable now. I tested with a user space patch which copy efi_info from 1st kernel to bootparams, as I said previously this is not enough because several fields in systab, fw_vendor, runtime and tables are converted to virtual address but in kernel efi init function they are assumed physical addresses. Thus we need save these physical address. I have a patch to save them and pass them to 2nd kernel in bootparams. Yep. Since the mapping are same, I wonder if we can calculate the physical address from virtual address. Idea? Just look at the loop where we're iterating over regions in efi_enter_virtual_mode(): we basically can do the same __map_region calls without calling phys_efi_set_virtual_address_map. Another concern is that is it safe for i386 efi boot? That's why I didn't put a git tree on k.org - I wanted to run tests myself before Fengguang's robot :) But no, 32-bit is not addressed here. Which just dawned on me: Matt, I probably should keep the ioremapping code for 32-bit, doh. I completely went 64-bit only here :-) Thanks. -- 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 00/11] EFI runtime services virtual mapping
On Fri, Sep 20, 2013 at 04:19:40PM +0800, Dave Young wrote: Actually the ovmf testing is qemu-system-x86_64 -kernel , boot from grub fails as well. Nothing printed on serial. I guess '-kernel' is using efi stub to boot? Yes. Which OVMF are you using? Mine is pretty recent: svn revision 14530 from August. Thanks. -- 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 00/11] EFI runtime services virtual mapping
On Fri, 20 Sep, at 11:05:44AM, Borislav Petkov wrote: But no, 32-bit is not addressed here. Which just dawned on me: Matt, I probably should keep the ioremapping code for 32-bit, doh. I completely went 64-bit only here :-) Yes, please keep the ioremap code. At least for now. -- Matt Fleming, Intel Open Source Technology Center -- 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 00/11] EFI runtime services virtual mapping
On Fri, 20 Sep, at 11:05:44AM, Borislav Petkov wrote: Another concern is that is it safe for i386 efi boot? That's why I didn't put a git tree on k.org - I wanted to run tests myself before Fengguang's robot :) But no, 32-bit is not addressed here. Which just dawned on me: Matt, I probably should keep the ioremapping code for 32-bit, doh. I completely went 64-bit only here :-) /home/build/git/efi/arch/x86/platform/efi/efi.c: In function ‘__map_region’: /home/build/git/efi/arch/x86/platform/efi/efi.c:753:24: error: ‘struct real_mode_header’ has no member named ‘trampoline_pgd’ /home/build/git/efi/arch/x86/platform/efi/efi.c: In function ‘efi_enter_virtual_mode’: /home/build/git/efi/arch/x86/platform/efi/efi.c:863:64: error: ‘struct real_mode_header’ has no member named ‘trampoline_pgd’ /home/build/git/efi/arch/x86/platform/efi/efi.c:867:2: error: implicit declaration of function ‘efi_sync_low_kernel_mappings’ [-Werror=implicit-function-declaration] -- Matt Fleming, Intel Open Source Technology Center -- 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 00/11] EFI runtime services virtual mapping
On Fri, Sep 20, 2013 at 10:49:13AM +0100, Matt Fleming wrote: /home/build/git/efi/arch/x86/platform/efi/efi.c: In function ‘__map_region’: /home/build/git/efi/arch/x86/platform/efi/efi.c:753:24: error: ‘struct real_mode_header’ has no member named ‘trampoline_pgd’ /home/build/git/efi/arch/x86/platform/efi/efi.c: In function ‘efi_enter_virtual_mode’: /home/build/git/efi/arch/x86/platform/efi/efi.c:863:64: error: ‘struct real_mode_header’ has no member named ‘trampoline_pgd’ /home/build/git/efi/arch/x86/platform/efi/efi.c:867:2: error: implicit declaration of function ‘efi_sync_low_kernel_mappings’ [-Werror=implicit-function-declaration] Yep, I know - saw them last night and fixed them. But this place will need some reorg anyway in the next version - just don't do 32-bit builds with this one :) -- 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 00/11] EFI runtime services virtual mapping
On 09/20/13 at 11:33am, Borislav Petkov wrote: On Fri, Sep 20, 2013 at 04:19:40PM +0800, Dave Young wrote: Actually the ovmf testing is qemu-system-x86_64 -kernel , boot from grub fails as well. Nothing printed on serial. I guess '-kernel' is using efi stub to boot? Yes. Which OVMF are you using? Mine is pretty recent: svn revision 14530 from August. It's a fresh clone at 2013-09-12. Thanks. -- 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 00/11] EFI runtime services virtual mapping
On 09/20/13 at 11:05am, Borislav Petkov wrote: On Fri, Sep 20, 2013 at 03:29:04PM +0800, Dave Young wrote: Just tested this series, for 1st kernel It boots ok in qemu+ovmf. But it immediately reboot on my Thinkpad T420. Unfortunately there's no way to debug this very early problem because there's no serial port also earlyprintk does not work for efi boot. No usb debug as well on this machine. I will test it when I go back to work after the china holiday. Hmm, I'm booting with the efi boot stub, how do you do it? Just a Fedora 19 grub boot. OTOH, for 2nd kernel testing because kexec tools does not fill efi_info[] in bootparam so kernel will disable efi, also it pass acpi_rsdp pointer automaticlly to make 2nd kernel boot ok. Right, the way this could be done is to pass in efi_info.efi_memmap, i.e. the physical map and then iterate over it and compute the virtual addresses *without* calling phys_efi_set_virtual_address_map() - they are stable now. I tested with a user space patch which copy efi_info from 1st kernel to bootparams, as I said previously this is not enough because several fields in systab, fw_vendor, runtime and tables are converted to virtual address but in kernel efi init function they are assumed physical addresses. Thus we need save these physical address. I have a patch to save them and pass them to 2nd kernel in bootparams. Yep. Since the mapping are same, I wonder if we can calculate the physical address from virtual address. Idea? Just look at the loop where we're iterating over regions in efi_enter_virtual_mode(): we basically can do the same __map_region calls without calling phys_efi_set_virtual_address_map. Sorry, I do not understand the do the same __map_region See below code: /* * Show what we know for posterity */ c16 = tmp = early_ioremap(efi.systab-fw_vendor, 2); efi.systab-fw_vendor is a virtual addr after entering virtual mode, so can not ioremap it in 2nd kernel. efi_init is before enter_virtual_mode, do you means move mem mapping code earlier so we can directly use the fw_vendor as a virtual address? Another concern is that is it safe for i386 efi boot? That's why I didn't put a git tree on k.org - I wanted to run tests myself before Fengguang's robot :) But no, 32-bit is not addressed here. Which just dawned on me: Matt, I probably should keep the ioremapping code for 32-bit, doh. I completely went 64-bit only here :-) Thanks. -- 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 00/11] EFI runtime services virtual mapping
On 09/20/13 at 01:29pm, Matt Fleming wrote: On Fri, 20 Sep, at 11:05:44AM, Borislav Petkov wrote: On Fri, Sep 20, 2013 at 03:29:04PM +0800, Dave Young wrote: Just tested this series, for 1st kernel It boots ok in qemu+ovmf. But it immediately reboot on my Thinkpad T420. Unfortunately there's no way to debug this very early problem because there's no serial port also earlyprintk does not work for efi boot. No usb debug as well on this machine. I will test it when I go back to work after the china holiday. Hmm, I'm booting with the efi boot stub, how do you do it? Dave, could you try this patch? Matt, It works for me, thanks for the quick fix. --- diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S index 06e71c2..9bcc15c 100644 --- a/arch/x86/boot/compressed/head_64.S +++ b/arch/x86/boot/compressed/head_64.S @@ -207,6 +207,8 @@ ENTRY(startup_64) jmp preferred_addr ENTRY(efi_pe_entry) + movq%cr3, %r15 + movq%r15, efi_scratch+16(%rip) mov %rcx, %rdi mov %rdx, %rsi pushq %rdi @@ -219,6 +221,8 @@ ENTRY(efi_pe_entry) popq%rdi ENTRY(efi_stub_entry) + movq%cr3, %r15 + movq%r15, efi_scratch+16(%rip) callefi_main movq%rax,%rsi cmpq$0,%rax -- Matt Fleming, Intel Open Source Technology Center -- 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
[PATCH 00/11] EFI runtime services virtual mapping
From: Borislav Petkov b...@suse.de Hi all, here's finally a new version of the runtime services VA mapping patchset which hopefully implements hpa's idea of statically mapping EFI runtime regions in a top-down manner starting at -4Gb virtual. We're also using a different pagetable so as not to pollute kernel address space. For that, we switch to that table before doing an EFI call, and afterwards we switch back to the previous one. To the patches: 1-2 are simple cleanups which Matt probably can take now 3-10 add the machinery to map regions into an arbitrary PGD. Those I've split deliberately into very small bites so that they can be reviewed more thoroughly and easily for my pagetable skills are pretty basic. 11 is the actual patch which implements that mapping so that we can use runtime services in kexec (which is the whole reason for this fuss :)) So please take a long hard look at those, hammer on them on your boxes and let me know. They boot fine on my Dell UEFI box and in OVMF (obviously :)). Thanks. Borislav Petkov (11): efi: Simplify EFI_DEBUG efi: Remove EFI_PAGE_SHIFT and EFI_PAGE_SIZE x86, pageattr: Lookup address in an arbitrary PGD x86, pageattr: Add a PGD pagetable populating function x86, pageattr: Add a PUD pagetable populating function x86, pageattr: Add a PMD pagetable populating function x86, pageattr: Add a PTE pagetable populating function x86, pageattr: Add a PUD error unwinding path x86, pageattr: Add last levels of error path x86, cpa: Map in an arbitrary pgd EFI: Runtime services virtual mapping arch/x86/boot/compressed/eboot.c | 12 +- arch/x86/boot/compressed/eboot.h | 1 - arch/x86/include/asm/efi.h | 58 +++-- arch/x86/include/asm/pgtable_types.h | 3 +- arch/x86/mm/pageattr.c | 461 +-- arch/x86/platform/efi/efi.c | 126 +- arch/x86/platform/efi/efi_64.c | 56 + arch/x86/platform/efi/efi_stub_64.S | 47 include/linux/efi.h | 6 +- 9 files changed, 615 insertions(+), 155 deletions(-) -- 1.8.4 -- 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
