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: [GIT PULL] EFI urgent fix
* Matt Fleming m...@console-pimps.org wrote: Hi, The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f: Linux 3.12-rc1 (2013-09-16 16:17:51 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent for you to fetch changes up to 700870119f49084da004ab588ea2b799689efaf7: x86, efi: Don't map Boot Services on i386 (2013-09-18 14:42:33 +0100) * Fix WARNING on i386 by only enabling a workaround for x86-64 since we've never encountered the bug on i386 - Josh Boyer Josh Boyer (1): x86, efi: Don't map Boot Services on i386 arch/x86/platform/efi/efi.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Pulled into tip:x86/urgent, thanks Matt! 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 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: [edk2] Corrupted EFI region
On Wed, 18 Sep, at 01:24:14PM, jerry.hoem...@hp.com wrote: Matt, I conducted the following experiments on a 3.11 kernel: Jerry, could you paste your memory map from the kernel log? -- 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 09/17] Move unicode to ASCII conversion to shared function.
On Wed, 18 Sep, at 09:48:44PM, Roy Franz wrote: Would it be acceptable to fix the naming/comments, and convert values above 126 to '?' in the current patchset, and address a more thorough fix in another patch set? The ARM and ARM64 EFI stub patchsets that are mostly complete depend on this one, so getting this merged soon would be helpful. Just fixing the function name and comments is enough for this patch series. Anything else should be separate. -- 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 09/17] Move unicode to ASCII conversion to shared function.
On Fri, 20 Sep, at 01:02:41AM, Adam Borowski wrote: Are we on the same page so far? If so, I can make a patch atop yours. Patches to fix this would be most welcome, though I'd wait until Roy sends out another version of this patch with the name/comment changes. This series will eventually end up in the 'next' branch at, git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git -- 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 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
Re: [PATCH V4 00/17] ARM EFI stub common code
A general note: In multiline comments like: /* Relocate a kernel image, either compressed or uncompressed. * In the ARM64 case, all kernel images are currently * uncompressed, and as such when we relocate it we need to * allocate additional space for the BSS segment. Any low * memory that this function should avoid needs to be * unavailable in the EFI memory map, as if the preferred * address is not available the lowest available address will * be used. */ Please have a blank line at the beginning: /* * Relocate a kernel image, either compressed or uncompressed. * In the ARM64 case, all kernel images are currently * uncompressed, and as such when we relocate it we need to * allocate additional space for the BSS segment. Any low * memory that this function should avoid needs to be * unavailable in the EFI memory map, as if the preferred * address is not available the lowest available address will * be used. */ Also, if this a comment at the head of a function, have a blank line before the comment. -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 09/17] Move unicode to ASCII conversion to shared function.
On 09/20/2013 04:27 AM, Matt Fleming wrote:
On Wed, 18 Sep, at 09:48:44PM, Roy Franz wrote:
Would it be acceptable to fix the naming/comments, and convert values
above 126 to '?'
in the current patchset, and address a more thorough fix in another patch
set?
The ARM and ARM64 EFI stub patchsets that are mostly complete depend
on this one,
so getting this merged soon would be helpful.
Just fixing the function name and comments is enough for this patch
series. Anything else should be separate.
I just whipped up a patch to do proper UTF-16 to UTF-8 conversion.
Completely untested, of course.
-hpa
From 7d6cf630c1adbb9787a24c2994230373c2b20a8f Mon Sep 17 00:00:00 2001
From: H. Peter Anvin h...@linux.intel.com
Date: Fri, 20 Sep 2013 09:55:39 -0500
Subject: [PATCH] efi: Handle arbitrary Unicode characters
Instead of truncating UTF-16 assuming all characters is ASCII,
properly convert it to UTF-8.
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
arch/x86/boot/compressed/eboot.c | 3 +-
drivers/firmware/efi/efi-stub-helper.c | 89 ++
2 files changed, 71 insertions(+), 21 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index bf56206..aacbe50 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -488,8 +488,7 @@ struct boot_params *make_boot_params(void *handle, efi_system_table_t *_table)
hdr-type_of_loader = 0x21;
/* Convert unicode cmdline to ascii */
- cmdline_ptr = efi_convert_cmdline_to_ascii(sys_table, image,
- options_size);
+ cmdline_ptr = efi_convert_cmdline(sys_table, image, options_size);
if (!cmdline_ptr)
goto fail;
hdr-cmd_line_ptr = (unsigned long)cmdline_ptr;
diff --git a/drivers/firmware/efi/efi-stub-helper.c b/drivers/firmware/efi/efi-stub-helper.c
index c91e757..7d4c1a4 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -567,20 +567,72 @@ static efi_status_t efi_relocate_kernel(efi_system_table_t *sys_table_arg,
return status;
}
-/* Convert the unicode UEFI command line to ASCII to pass to kernel.
+
+/*
+ * Get the number of UTF-8 bytes corresponding to an UTF-16 character.
+ * This overestimates for surrogates, but that is okay.
+ */
+static int efi_utf8_bytes(u16 c)
+{
+ return 1 + (c = 0x80) + (c = 0x800);
+}
+
+/*
+ * Convert an UTF-16 string, not necessarily null terminated, to UTF-8.
+ */
+static u8 *efi_utf8_to_utf16(u8 *dst, const u16 *src, int n)
+{
+ unsigned int c;
+
+ while (n--) {
+ c = *src++;
+ if (n c = 0xd800 c = 0xdbff
+ *src = 0xdc00 *src = 0xdfff) {
+ c = 0x1 + ((c 0x3ff) 10) + (*src 0x3ff);
+ src++;
+ n--;
+ }
+ if (c = 0xd800 c = 0xdfff)
+ c = 0xfffd; /* Unmatched surrogate */
+ if (c 0x80) {
+ *dst++ = c;
+ continue;
+ }
+ if (c 0x800) {
+ *dst++ = 0xc0 + (c 6);
+ goto t1;
+ }
+ if (c 0x1) {
+ *dst++ = 0xe0 + (c 12);
+ goto t2;
+ }
+ *dst++ = 0xf0 + (c 18);
+ *dst++ = 0x80 + ((c 12) 0x3f);
+ t2:
+ *dst++ = 0x80 + ((c 6) 0x3f);
+ t1:
+ *dst++ = 0x80 + (c 0x3f);
+ }
+
+ return dst;
+}
+
+/*
+ * Convert the unicode UEFI command line to ASCII to pass to kernel.
* Size of memory allocated return in *cmd_line_len.
* Returns NULL on error.
*/
-static char *efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
- efi_loaded_image_t *image,
- int *cmd_line_len)
+static char *efi_convert_cmdline(efi_system_table_t *sys_table_arg,
+ efi_loaded_image_t *image,
+ int *cmd_line_len)
{
- u16 *s2;
+ const u16 *s2;
u8 *s1 = NULL;
unsigned long cmdline_addr = 0;
int load_options_size = image-load_options_size / 2; /* ASCII */
- void *options = image-load_options;
- int options_size = 0;
+ const void *options = image-load_options;
+ int options_bytes = 0; /* UTF-8 bytes */
+ int options_chars = 0; /* UTF-16 chars */
efi_status_t status;
int i;
u16 zero = 0;
@@ -588,40 +640,39 @@ static char *efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
if (options) {
s2 = options;
while (*s2 *s2 != '\n' options_size load_options_size) {
+ options_bytes += efi_utf8_bytes(*s2);
s2++;
- options_size++;
}
+ options_chars = s2 - options;
}
- if (options_size == 0) {
- /* No command line options, so return empty string*/
- options_size = 1;
+ if (!options_chars) {
+ /* No command line options, so return empty string */
options = zero;
}
- options_size++; /* NUL termination */
+ options_bytes++; /* NUL termination */
+
#ifdef CONFIG_ARM
/* For ARM, allocate at a high address to avoid reserved
* regions at low addresses that we don't know the specfics of
* at the time we are processing the command line.
*/
- status = efi_high_alloc(sys_table_arg, options_size, 0,
+ status = efi_high_alloc(sys_table_arg, options_bytes, 0,
cmdline_addr, 0xf000);
#else
- status = efi_low_alloc(sys_table_arg,
Re: [PATCH] x86 efi: bugfix interrupt disabling sequence
On Wed, 18 Sep, at 07:28:53PM, Bart Kuivenhoven wrote: The problem in efi_main was that the idt was cleared before the interrupts were disabled. The UEFI spec states that interrupts aren't used so this shouldn't be too much of a problem. Peripherals however don't necessarily know about this and thus might cause interrupts to happen anyway. Even if ExitBootServices() has been called. This means there is a risk of an interrupt being triggered while the IDT register is nullified and the interrupt bit hasn't been cleared, allowing for a triple fault. Just to be clear, you haven't witnessed a triple fault, correct? This patch fixes this by clearing the interrupt bit before the lidt instruction. I think we can go even further than this and get rid of all of the IDT code in the EFI boot stub. The kernel maintains its own IDT anyway. -- 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] x86 efi: bugfix interrupt disabling sequence
On Fri, 2013-09-20 at 16:28 +0100, Matt Fleming wrote: On Wed, 18 Sep, at 07:28:53PM, Bart Kuivenhoven wrote: The problem in efi_main was that the idt was cleared before the interrupts were disabled. The UEFI spec states that interrupts aren't used so this shouldn't be too much of a problem. Peripherals however don't necessarily know about this and thus might cause interrupts to happen anyway. Even if ExitBootServices() has been called. This means there is a risk of an interrupt being triggered while the IDT register is nullified and the interrupt bit hasn't been cleared, allowing for a triple fault. Just to be clear, you haven't witnessed a triple fault, correct? This patch fixes this by clearing the interrupt bit before the lidt instruction. I think we can go even further than this and get rid of all of the IDT code in the EFI boot stub. The kernel maintains its own IDT anyway. Well, isn't it so, that the kernel expects a setup in which interrupts are disabled before the decompressed image is loaded? What we can do is remove the lidt instruction and IDT pointer, but that still doesn't change anything with regards to the kernels expectations. And no, I haven't witnessed a triple fault, this is purely theoretical, with a very slim chance of it actually happening. That does not mean that it can't happen though. -- Kind regards/Met vriendelijke groet, Bart Kuivenhoven. Intern Fedora ARM, Red Hat. -- 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
