| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Sep 2013 10:43:27 -0700
From: Darren Hart <darren.hart@...el.com>
To: Matt Fleming <matt@...sole-pimps.org>
Cc: Bryan O'Donoghue <bryan.odonoghue.lkml@...us-software.ie>,
matthew.garrett@...ula.com, linux-efi@...r.kernel.org,
x86@...nel.org, linux-kernel@...r.kernel.org,
Josh Triplett <josh@...htriplett.org>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Josh Boyer <jwboyer@...hat.com>
Subject: Re: [PATCH] Remove warning in efi_enter_virtual_mode
On Fri, 2013-04-19 at 08:50 +0100, Matt Fleming wrote:
> On 04/19/2013 01:18 AM, Darren Hart wrote:
> > On 04/18/2013 09:19 AM, Matt Fleming wrote:
> >>
> >> Could you give it a spin on your MinnowBoard?
> >
> > I've removed the patch I reference above and applied your patch to my
> > 3.8.4 MinnowBoard dev tree. It panics with:
>
> D'oh. OK, at this point I'm inclined to apply Josh Boyer's patch on top
> of my urgent branch which will address the WARNING people are hitting on
> i386. I updated the commit message a little.
>
> Josh (Boyer), are you guys still carrying this patch and have you seen
> any fallout? I notice your SoB isn't on the patch that Darren posted, am
> I OK to add it?
Josh OK'd this, but as far as I can tell, it hasn't made it upstream
yet. Matt was there an alternate fixed pushed?
The patch from Josh we're referring to here I believe is:
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index e4a86a6..b9876aa 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -997,10 +997,13 @@ void __init efi_enter_virtual_mode(void)
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size)
{
md = p;
- if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
- md->type != EFI_BOOT_SERVICES_CODE &&
- md->type != EFI_BOOT_SERVICES_DATA)
- continue;
+ if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
+#ifdef CONFIG_X86_64
+ if (md->type != EFI_BOOT_SERVICES_CODE &&
+ md->type != EFI_BOOT_SERVICES_DATA)
+#endif
+ continue;
+ }
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
--
Darren
>
> ---
>
> From 40f053eb6ccb3f0c462ef7a23c44c3264d87a0d4 Mon Sep 17 00:00:00 2001
> From: Josh Boyer <jwboyer@...hat.com>
> Date: Thu, 18 Apr 2013 07:51:34 -0700
> Subject: [PATCH] x86, efi: Don't map Boot Services on i386
>
> Add patch to fix 32bit EFI service mapping (rhbz 726701)
>
> Multiple people are reporting hitting the following WARNING on i386,
>
> WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
> Call Trace:
> [<c102b6af>] warn_slowpath_common+0x5f/0x80
> [<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
> [<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
> [<c102b6ed>] warn_slowpath_null+0x1d/0x20
> [<c1023fb3>] __ioremap_caller+0x3d3/0x440
> [<c106007b>] ? get_usage_chars+0xfb/0x110
> [<c102d937>] ? vprintk_emit+0x147/0x480
> [<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
> [<c102406a>] ioremap_cache+0x1a/0x20
> [<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
> [<c1418593>] efi_enter_virtual_mode+0x1e4/0x3de
> [<c1407984>] start_kernel+0x286/0x2f4
> [<c1407535>] ? repair_env_string+0x51/0x51
> [<c1407362>] i386_start_kernel+0x12c/0x12f
>
> Due to the workaround described in commit 916f676f8 ("x86, efi: Retain
> boot service code until after switching to virtual mode") EFI Boot
> Service regions are mapped for a period during boot. Unfortunately, with
> the limited size of the i386 direct kernel map it's possible that some
> of the Boot Service regions will not be directly accessible, which
> causes them to be ioremap()'d, triggering the above warning as the
> regions are marked as E820_RAM in the e820 memmap.
>
> There are currently only two situations where we need to map EFI Boot
> Service regions,
>
> 1. To workaround the firmware bug described in 916f676f8
> 2. To access the ACPI BGRT image
>
> but since we haven't seen an i386 implementation that requires either,
> this simple fix should suffice for now.
>
> [ Added to changelog - Matt ]
>
> Reported-by: Bryan O'Donoghue <bryan.odonoghue.lkml@...us-software.ie>
> Acked-by: Tom Zanussi <tom.zanussi@...el.com>
> Acked-by: Darren Hart <dvhart@...ux.intel.com>
> Cc: Josh Triplett <josh@...htriplett.org>
> Cc: Matthew Garrett <mjg59@...f.ucam.org>
> Cc: H. Peter Anvin <hpa@...or.com>
> Cc: Ingo Molnar <mingo@...nel.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: <stable@...r.kernel.org>
> Signed-off-by: Josh Boyer <jwboyer@...hat.com>
> Signed-off-by: Matt Fleming <matt.fleming@...el.com>
> ---
> arch/x86/platform/efi/efi.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index e4a86a6..b9876aa 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -997,10 +997,13 @@ void __init efi_enter_virtual_mode(void)
>
> for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> md = p;
> - if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> - md->type != EFI_BOOT_SERVICES_CODE &&
> - md->type != EFI_BOOT_SERVICES_DATA)
> - continue;
> + if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
> +#ifdef CONFIG_X86_64
> + if (md->type != EFI_BOOT_SERVICES_CODE &&
> + md->type != EFI_BOOT_SERVICES_DATA)
> +#endif
> + continue;
> + }
>
> size = md->num_pages << EFI_PAGE_SHIFT;
> end = md->phys_addr + size;
> --
> 1.8.1.4
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists