From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751307AbdH1G76 (ORCPT ); Mon, 28 Aug 2017 02:59:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51654 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750873AbdH1G7z (ORCPT ); Mon, 28 Aug 2017 02:59:55 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6B5A9C057FA8 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=bhe@redhat.com Date: Mon, 28 Aug 2017 14:59:51 +0800 From: Baoquan He To: Naoya Horiguchi Cc: Kees Cook , linux-kernel@vger.kernel.org, x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Ingo Molnar , izumi.taku@jp.fujitsu.com, Thomas Garnier , fanc.fnst@cn.fujitsu.com, Matt Fleming , "Jun'ichi Nomura" , Ard Biesheuvel Subject: Re: [PATCH v4] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice Message-ID: <20170828065951.GB23855@x1> References: <1503570831-9683-1-git-send-email-n-horiguchi@ah.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1503570831-9683-1-git-send-email-n-horiguchi@ah.jp.nec.com> User-Agent: Mutt/1.7.0 (2016-08-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 28 Aug 2017 06:59:55 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Naoya, Thanks for this fix. I saw NEC had reported a bug to rhel previously, and the bug truly will corrupt OS, it can be fixed by this patch. This patch looks good to me, just a small concern, please see below inline comment. On 08/24/17 at 07:33pm, Naoya Horiguchi wrote: > KASLR chooses kernel location from E820_TYPE_RAM regions by walking over > e820 entries now. E820_TYPE_RAM includes EFI_BOOT_SERVICES_CODE and > EFI_BOOT_SERVICES_DATA, so those regions can be the target. According to > UEFI spec, all memory regions marked as EfiBootServicesCode and > EfiBootServicesData are available for free memory after the first call > of ExitBootServices(). So such regions should be usable for kernel on > spec basis. > > In x86, however, we have some workaround for broken firmware, where we > keep such regions reserved until SetVirtualAddressMap() is done. > See the following code in should_map_region(): > > static bool should_map_region(efi_memory_desc_t *md) > { > ... > /* > * Map boot services regions as a workaround for buggy > * firmware that accesses them even when they shouldn't. > * > * See efi_{reserve,free}_boot_services(). > */ > if (md->type == EFI_BOOT_SERVICES_CODE || > md->type == EFI_BOOT_SERVICES_DATA) > return false; > > This workaround suppressed a boot crash, but potential issues still > remain because no one prevents the regions from overlapping with kernel > image by KASLR. > > So let's make sure that EFI_BOOT_SERVICES_{CODE|DATA} regions are never > chosen as kernel memory for the workaround to work fine. Furthermore, > we choose kernel address only from EFI_CONVENTIONAL_MEMORY because it's > the only memory type we know to be free. Here, I think it's better to present why EFI_CONVENTIONAL_MEMORY is the only memory type we should choose. EFI_BOOT_SERVICES_xxx has been clear to us why it's not good. It might be worth to saying something about EFI_LOADER_xxx why it's not ok to choose. Maybe one sentence to mention it and take pgd as exampel as Matt ever said. Thanks Baoquan > v3 -> v4: > - update comment and patch description to mention why only > EFI_CONVENTIONAL_MEMORY is chosen. > - use efi_early_memdesc_ptr() > - I decided not to post cleanup patches (patch 2/2 in previous series) > because it's not necessary to fix the issue. > > v2 -> v3: > - skip EFI_LOADER_CODE and EFI_LOADER_DATA in region scan > > v1 -> v2: > - switch efi_mirror_found to local variable > - insert break when EFI_MEMORY_MORE_RELIABLE found > --- > arch/x86/boot/compressed/kaslr.c | 35 ++++++++++++++++++++++++++--------- > 1 file changed, 26 insertions(+), 9 deletions(-) > > diff --git tip/x86/boot/arch/x86/boot/compressed/kaslr.c tip/x86/boot_patched/arch/x86/boot/compressed/kaslr.c > index 7de23bb..ba5e9e5 100644 > --- tip/x86/boot/arch/x86/boot/compressed/kaslr.c > +++ tip/x86/boot_patched/arch/x86/boot/compressed/kaslr.c > @@ -597,19 +597,36 @@ process_efi_entries(unsigned long minimum, unsigned long image_size) > for (i = 0; i < nr_desc; i++) { > md = efi_early_memdesc_ptr(pmap, e->efi_memdesc_size, i); > if (md->attribute & EFI_MEMORY_MORE_RELIABLE) { > - region.start = md->phys_addr; > - region.size = md->num_pages << EFI_PAGE_SHIFT; > - process_mem_region(®ion, minimum, image_size); > efi_mirror_found = true; > - > - if (slot_area_index == MAX_SLOT_AREA) { > - debug_putstr("Aborted EFI scan (slot_areas full)!\n"); > - break; > - } > + break; > } > } > > - return efi_mirror_found; > + for (i = 0; i < nr_desc; i++) { > + md = efi_early_memdesc_ptr(pmap, e->efi_memdesc_size, i); > + > + /* > + * According to spec, EFI_BOOT_SERVICES_{CODE|DATA} are also > + * available for kernel image, but we don't include them for > + * the workaround for buggy firmware. > + * Only EFI_CONVENTIONAL_MEMORY is guaranteed to be free. > + */ > + if (md->type != EFI_CONVENTIONAL_MEMORY) > + continue; > + > + if (efi_mirror_found && > + !(md->attribute & EFI_MEMORY_MORE_RELIABLE)) > + continue; > + > + region.start = md->phys_addr; > + region.size = md->num_pages << EFI_PAGE_SHIFT; > + process_mem_region(®ion, minimum, image_size); > + if (slot_area_index == MAX_SLOT_AREA) { > + debug_putstr("Aborted EFI scan (slot_areas full)!\n"); > + break; > + } > + } > + return true; > } > #else > static inline bool > -- > 2.7.0 >