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: Sat, 26 Sep 2015 11:15:57 -0700 From: Ard Biesheuvel <ard.biesheuvel@...aro.org> To: "H. Peter Anvin" <hpa@...or.com> Cc: Andy Lutomirski <luto@...capital.net>, Ingo Molnar <mingo@...nel.org>, Matt Fleming <matt@...eblueprint.co.uk>, Thomas Gleixner <tglx@...utronix.de>, Matt Fleming <matt.fleming@...el.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>, "Lee, Chun-Yi" <jlee@...e.com>, Borislav Petkov <bp@...e.de>, Leif Lindholm <leif.lindholm@...aro.org>, Peter Jones <pjones@...hat.com>, James Bottomley <JBottomley@...n.com>, Matthew Garrett <mjg59@...f.ucam.org>, Dave Young <dyoung@...hat.com>, stable <stable@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>, Denys Vlasenko <dvlasenk@...hat.com>, Brian Gerst <brgerst@...il.com>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime On 26 September 2015 at 10:20, H. Peter Anvin <hpa@...or.com> wrote: > I think it "works" because the affected BIOSes don't put spaces between the chunks. I have discussed this with Matt. > Forgive the ASCII art but perhaps an illustration might help: before the 2.5 feature, PE/COFF runtime images were remapped as illustrated here: PA VA +---------------+ +---------------+ | | | | | PE/COFF .text | | EFI | | | | Runtime | +- - - - - - - -+ => | Services |----+ | | | Code | | : : | PE/COFF .data | | | | : : | | | | | +---------------+ +---------------+ +---------------+ | | | | | | | | | EFI | : : : : | | Runtime | : : : : +--->| Services | | | | | | Code | +---------------+ +---------------+ | | | | | | | | | PE/COFF .text | | EFI | +---------------+ | | | Runtime | : gap : +- - - - - - - -+ => | Services |---+ +---------------+ | | | Code | | | | | PE/COFF .data | | | | | EFI | | | | | | | Runtime | +---------------+ +---------------+ +---->| Services | | | | | | Code | : : : : | | : : : : | | : : : : +---------------+ : : : : : : Since the affected symbol references only exist between PE/COFF .text and PE/COFF .data, there is never a problem since each is PE/COFF image is mapped as a single region. However, with the new feature enabled, this no longer holds: PA VA +---------------+ +---------------+ | | | | | PE/COFF .text | | RtServices |----+ | | | Code | | +- - - - - - - -+ => +---------------+ | +---------------+ | | | RtServices | +--->| RtServices | | PE/COFF .data | | Data | | Code | | | | |----+ +---------------+ +---------------+ +---------------+ | : gap : | | | | | +---------------+ : : : : +--->| RtServices | : : : : | Data | | | | | +---------------+ +---------------+ +---------------+ : gap : | | | | +---------------+ | PE/COFF .text | | RtServices |-------->| RtServices | | | | Code | | Code | +- - - - - - - -+ => +---------------+ +---------------+ | | | RtServices | : gap : | PE/COFF .data | | Data |---+ +---------------+ | | | | | | RtServices | +---------------+ +---------------+ +---->| Data | | | | | | | : : : : +---------------+ : : : : : : : : : : : : The illustration uses gaps, but obviously, this applies equally to inverting the mapping order, since the PE/COFF .text and .data sections will end up out of order. -- Ard. > On September 26, 2015 10:01:14 AM PDT, Andy Lutomirski <luto@...capital.net> wrote: >>On Fri, Sep 25, 2015 at 10:56 PM, Ingo Molnar <mingo@...nel.org> wrote: >>> >>> So this commit worries me. >>> >>> This bug is a good find, and the fix is obviously needed and urgent, >>but I'm not >>> sure about the implementation at all. (I've Cc:-ed a few more x86 low >>level >>> gents.) >>> >>> * Matt Fleming <matt@...eblueprint.co.uk> wrote: >>>> + /* >>>> + * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE >>>> + * config table feature requires us to map all entries >>>> + * in the same order as they appear in the EFI memory >>>> + * map. That is to say, entry N must have a lower >>>> + * virtual address than entry N+1. This is because the >>>> + * firmware toolchain leaves relative references in >>>> + * the code/data sections, which are split and become >>>> + * separate EFI memory regions. Mapping things >>>> + * out-of-order leads to the firmware accessing >>>> + * unmapped addresses. >>>> + * >> >>I'm clearly missing something. What is EFI doing that it doesn't care >>how big the gap between sections is but it still requires them to be >>in order? It's not as though x86_64 has an addressing mode that >>allows only non-negative offsets. >> >>--Andy > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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