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: Wed, 25 Jan 2017 21:31:53 +0100 (CET) From: Jiri Kosina <jkosina@...e.cz> To: Matt Fleming <matt@...eblueprint.co.uk>, Ard Biesheuvel <ard.biesheuvel@...aro.org> cc: Waiman Long <waiman.long@....com>, Borislav Petkov <bp@...e.de>, Laura Abbott <labbott@...hat.com>, Vojtech Pavlik <vojtech@....cz>, Hanka Pavlikova <hanka@....cz>, linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org Subject: Re: [PATCH] x86/efi: always map first physical page into EFI pagetables [ CCing mailinglists that got eaten by my newly configured mail setup, sorry for that ] On Wed, 25 Jan 2017, Jiri Kosina wrote: > From: Jiri Kosina <jkosina@...e.cz> > > Commit 129766708 ("x86/efi: Only map RAM into EFI page tables if in > mixed-mode") stopped creating 1:1 mapping for all RAM in case of running > in native 64bit mode. > > It turns out though that there are 64bit EFI implementations in the wild > (this particular problem has been reported on Lenovo Yoga 710-11IKB) which > still make use of first physical page for their own private use (which is > what legacy BIOS used to do, but EFI specification doesn't grant any such > right to EFI BIOS ... oh well). > > In case there is no mapping for this particular frame in EFI pagetables, > as soon as firmware tries to make use of it, triple fault occurs and the > system reboots (in case of Yoga 710-11IKB this is very early during boot). > > Fix that by always mapping the first page of physical memory into EFI > pagetables. > > Note: just reverting 129766708 is not enough on v4.9-rc1+ to fix the > regression on affected hardware, as commit ab72a27da ("x86/efi: > Consolidate region mapping logic") later made the first physical frame not > to be mapped anyway. > > Fixes: 129766708 ("x86/efi: Only map RAM into EFI page tables if in mixed-mode") > Cc: stable@...nel.org # v4.8+ > Cc: Waiman Long <waiman.long@....com> > Cc: Borislav Petkov <bp@...e.de> > Cc: Laura Abbott <labbott@...hat.com> > Cc: Vojtech Pavlik <vojtech@....cz> > Reported-by: Hanka Pavlikova <hanka@....cz> > Signed-off-by: Jiri Kosina <jkosina@...e.cz> > --- > > Thanks a lot to Matt for excellent hint how to debug EFI failures > > arch/x86/platform/efi/efi_64.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c > index 319148b..02ae2ab 100644 > --- a/arch/x86/platform/efi/efi_64.c > +++ b/arch/x86/platform/efi/efi_64.c > @@ -269,6 +269,17 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) > efi_scratch.use_pgd = true; > > /* > + * Certain firmware versions are way too sentimental and still believe > + * they are exclusive and unquestionable owners of first physical page. > + * Create 1:1 mapping for this page to avoid triple faults during early > + * boot with such firmware. > + */ > + if (kernel_map_pages_in_pgd(pgd, 0x0, 0x0, 1, _PAGE_RW)) { > + pr_err("Failed to create 1:1 mapping of first page\n"); > + return 1; > + } > + > + /* > * When making calls to the firmware everything needs to be 1:1 > * mapped and addressable with 32-bit pointers. Map the kernel > * text and allocate a new stack because we can't rely on the > -- > Jiri Kosina > SUSE Labs > > -- Jiri Kosina SUSE Labs
Powered by blists - more mailing lists