linux-kernel - Re: [PATCH] Remove warning in efi_enter_virtual

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] [day] [month] [year] [list]

Date:	Fri, 19 Apr 2013 12:15:23 +0100
From:	Bryan O'Donoghue <bryan.odonoghue.lkml@...us-software.ie>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	matt@...sole-pimps.org, matthew.garrett@...ula.com,
	linux-efi@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, darren.hart@...el.com,
	josh@...htriplett.org, hpa@...or.com, mingo@...nel.org,
	tglx@...utronix.de
Subject: Re: [PATCH] Remove warning in efi_enter_virtual_mode V2

On 19/04/13 06:58, Greg KH wrote:
>> This patch gives the option to switch off that behavior - if your BIOS
>> has neither BGRT - nor bugs that require mapping of EFI boot code/data
>
> No, never add new boot options, no users, or distros, know to set them.
> Isn't there some way we can dynamically determine this instead?

Peter, Greg.

There are three issues to consider here

1: Some UEFI BIOS is buggy and the EFI_RUNTIME_SERVICES code - actually 
touches EFI_BOOT_MEMORY. Boot memory should be completely untouched 
after an entity calls ExitBootServices() - typically done by an EFI 
aware bootloader before handing off to Linux.

2: Existing code maps EFI_BOOT_MEMORY in arch/x86/platform/efi/efi.c.
Initially it looked to me as though you could probe for ACPI::BGRT - 
look for an ACPI object sometimes stored in EFI_BOOT_MEMORY and use that 
to determine if EFI_BOOT_MEMORY should be mapped. I wasn't aware #1 
above was also a concern. So just probing for something - doesn't appear 
to fly

3: Standards compliant EFI BIOS - like the reference EFI 2.3.1 code we 
have on my project, has neither of the two above problems to work around

So we can.

1. Just silently map EFI_BOOT_MEMORY - even on unbuggy platforms like #3 
- or we can

2. Introduce some sort of intelligence - a parameter somewhere to tell 
the efi_enter_virtual mode if/when to map EFI_BOOT_MEMORY.

3. Just go the suggested route from Josh
#ifdef CONFIG_X86_64
			if (md->type != EFI_BOOT_SERVICES_CODE &&
			    md->type != EFI_BOOT_SERVICES_DATA)
#endif

Option #3 - so long as it doesn't break ia32::BGRT systems works for me.
--
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/