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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1347626792.14222.1.camel@mfleming-mobl1.ger.corp.intel.com>
Date:	Fri, 14 Sep 2012 13:46:32 +0100
From:	Matt Fleming <matt.fleming@...el.com>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Len Brown <lenb@...nel.org>, Olof Johansson <olof@...om.net>,
	Matthew Garrett <mjg@...hat.com>,
	David Howells <dhowells@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCHv3 0/4] Fix ACPI BGRT support for images located in EFI
 boot services memory

On Sat, 2012-09-08 at 15:06 -0700, Josh Triplett wrote:
> The ACPI BGRT lets the OS access the BIOS logo image and its position on the
> screen at boot time, allowing it to maintain that image on the screen until
> ready to display something else, making boot more seamless.  This series fixes
> support for accessing the boot logo image via the BGRT when the BIOS stores it
> in EFI boot services memory, as recommended by the ACPI 5.0 spec.  Linux needs
> to copy the image out of boot services memory before reclaiming boot services
> memory.
> 
> The first patch cleans up the existing x86-specific efi_enter_virtual_mode
> function to have a stub version on non-x86 platforms, to eliminate an ifdef in
> init/main.c.   The second patch refactors EFI initialization to defer freeing
> boot services memory until much later in the boot process, and in particular
> until after we have ACPI available.  The third patch adds a helper function to
> look up existing EFI boot services mappings, to avoid re-mapping them.  The
> fourth patch moves BGRT initialization to before the reclamation of boot
> services memory, copies the logo at that point, and reworks the existing BGRT
> driver to use that existing copy.
> 
> v2: Made the new internal function efi_unmap_memmap static.  Incorporated
>     feedback from H. Peter Anvin and Matt Fleming: added stubs for
>     x86-specific EFI functions called from init/main.c to eliminate the
>     corresponding ifdefs in start_kernel; deferred
>     efi_free_boot_services even later, to just before free_initmem.
> 
> v3: Moved efi_free_boot_services back to right after EFI initialization, to
>     avoid a WARN from check_early_ioremap_leak about not calling
>     early_iounmap soon enough.
> 
> Josh Triplett (4):
>   efi: Add a stub for efi_enter_virtual_mode on non-x86
>   efi: Defer freeing boot services memory until after ACPI init
>   efi: Add a function to look up existing IO memory mappings
>   efi: Fix the ACPI BGRT driver for images located in EFI boot services
>     memory

I thought I'd replied to this but I can't find it anywhere. I think my
MUA ate my ACK.

Acked-by: Matt Fleming <matt.fleming@...el.com>

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ