Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp3892042ybf; Tue, 3 Mar 2020 15:10:34 -0800 (PST) X-Google-Smtp-Source: ADFU+vsQZcDoiZwS3MHePbaYmb1lEv1BVA8YLcmwCU1zFWHuDOZ7q+DzdnA0ieXpJQ1zGtzc+WJL X-Received: by 2002:a9d:77c3:: with SMTP id w3mr163114otl.245.1583277034393; Tue, 03 Mar 2020 15:10:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583277034; cv=none; d=google.com; s=arc-20160816; b=mDpuNfDJmeoZOIin59RpYKbAJqNJOuxc1EFkRJ9LS7MPvxyRtPr6LmcVuFrSZSFjkM 6ovl+wDtHuQhQIFK50iqZi1lFyy8A0n3ZaXVnGz24MbOFVte+2gJeICz28sb0SltSZtC 5Fr+YnXBPkijkFlEbPSPMDVLZspbUlFiIjIBfkCkEr0g3i0Elqw4T5wP+Ut3qjkBI7NY VGZFeCa8QuUzRyd2DQ4uUCrz3UQqrX/u9oQFYM9JOsvwwW/eCzjk4kUI/3+aKGBIImL4 e69xbX5ERdxD+ek0+W9Eufa1vLnjiVAkfdRgpthC8MO+Z1zHON4g8HcRpddsjZ0g7TUR Kn6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=u+FVlIWcag3w/ipm8CUQ93rHuMsA76p9IQoV2YOAwJ0=; b=nMXXKj4zh7wWrltZ349uQ9j3Gzh0xi16o6/DIUJ9/9gqyUs3RXHgHieDagxtpUQrMC BZXgdFNfDzgIX6lyPB66ibmrff/GoT722WNXoENsRyBFl8UkSoMI0FDtB1rP42dnvSxR 1P1S8AMsR56DE78MHbr8Aj1qdw3M8t3AFZZPSZ2+eIwfgXjdc25tceAIEupjkZHStEAR eJ3VI3Px+NpDPCsP712O5erb8Vw93JZlX6r6K+KLMA2AEX8P6/ra2ETfnXiCmnE9Jqvl AQXxL0ca7o0EkWFRrX4eFcJvqPVXJA2pG2PCKu2vevcb9qL4wFD2A+P+jJgtK9pQu8aL vAtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=As1PTPsa; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y15si46569oto.19.2020.03.03.15.10.21; Tue, 03 Mar 2020 15:10:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=As1PTPsa; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728200AbgCCXIr (ORCPT + 99 others); Tue, 3 Mar 2020 18:08:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:45198 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728098AbgCCXIq (ORCPT ); Tue, 3 Mar 2020 18:08:46 -0500 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BA3F320CC7 for ; Tue, 3 Mar 2020 23:08:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583276926; bh=Zhexf+t5rjSF6lDODnx2yi8LXcdCC2u1PQcGluLFGWg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=As1PTPsaIVmtgakMmyV/XuMuwdtOmMHI06rRAxtxmr7oz83soPqjZ0zrLoC+4PjPQ fw1vnQNLbbiAjTHSw+848wXYMMN2pO/Mtg6IgLYePfQ22WUtxzgNM9kvFlfqvpJCvo YAcTDjjjCOVsV98ad/Qo05ea0B6fXXSAiYFk0H2A= Received: by mail-wm1-f45.google.com with SMTP id m3so4669741wmi.0 for ; Tue, 03 Mar 2020 15:08:45 -0800 (PST) X-Gm-Message-State: ANhLgQ3liKcj3+6+yPcH1BKtlmkrlsYrLBv9udpY6H0HRhTAsZWC0skt E4GBsgm+xMSdErvCevRcpmb3yNd4TnYEeftd0ZMtDg== X-Received: by 2002:a7b:cb93:: with SMTP id m19mr765473wmi.133.1583276924026; Tue, 03 Mar 2020 15:08:44 -0800 (PST) MIME-Version: 1.0 References: <20200301230537.2247550-1-nivedita@alum.mit.edu> <20200303221205.4048668-1-nivedita@alum.mit.edu> <20200303221205.4048668-6-nivedita@alum.mit.edu> In-Reply-To: <20200303221205.4048668-6-nivedita@alum.mit.edu> From: Ard Biesheuvel Date: Wed, 4 Mar 2020 00:08:33 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 5/5] efi/x86: Don't relocate the kernel unless necessary To: Arvind Sankar Cc: linux-efi , "the arch/x86 maintainers" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 3 Mar 2020 at 23:12, Arvind Sankar wrote: > > Add alignment slack to the PE image size, so that we can realign the > decompression buffer within the space allocated for the image. > > Only relocate the kernel if it has been loaded at an unsuitable address: > * Below LOAD_PHYSICAL_ADDR, or > * Above 64T for 64-bit and 512MiB for 32-bit > > For 32-bit, the upper limit is conservative, but the exact limit can be > difficult to calculate. > Could we get rid of the call to efi_low_alloc_above() in efi_relocate_kernel(), and just allocate top down with the right alignment? I'd like to get rid of efi_low_alloc() et al if we can. > Signed-off-by: Arvind Sankar > --- > arch/x86/boot/tools/build.c | 16 +++++------- > drivers/firmware/efi/libstub/x86-stub.c | 33 ++++++++++++++++++++++--- > 2 files changed, 36 insertions(+), 13 deletions(-) > > diff --git a/arch/x86/boot/tools/build.c b/arch/x86/boot/tools/build.c > index 3d03ad753ed5..db528961c283 100644 > --- a/arch/x86/boot/tools/build.c > +++ b/arch/x86/boot/tools/build.c > @@ -238,21 +238,17 @@ static void update_pecoff_text(unsigned int text_start, unsigned int file_sz, > > pe_header = get_unaligned_le32(&buf[0x3c]); > > -#ifdef CONFIG_EFI_MIXED > /* > - * In mixed mode, we will execute startup_32() at whichever offset in > - * memory it happened to land when the PE/COFF loader loaded the image, > - * which may be misaligned with respect to the kernel_alignment field > - * in the setup header. > + * The PE/COFF loader may load the image at an address which is > + * misaligned with respect to the kernel_alignment field in the setup > + * header. > * > - * In order for startup_32 to safely execute in place at this offset, > - * we need to ensure that the CONFIG_PHYSICAL_ALIGN aligned allocation > - * it creates for the page tables does not extend beyond the declared > - * size of the image in the PE/COFF header. So add the required slack. > + * In order to avoid relocating the kernel to correct the misalignment, > + * add slack to allow the buffer to be aligned within the declared size > + * of the image. > */ > bss_sz += CONFIG_PHYSICAL_ALIGN; > init_sz += CONFIG_PHYSICAL_ALIGN; > -#endif > > /* > * Size of code: Subtract the size of the first sector (512 bytes) > diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c > index e71b8421e088..fbc4354f534c 100644 > --- a/drivers/firmware/efi/libstub/x86-stub.c > +++ b/drivers/firmware/efi/libstub/x86-stub.c > @@ -17,6 +17,9 @@ > > #include "efistub.h" > > +/* Maximum physical address for 64-bit kernel with 4-level paging */ > +#define MAXMEM_X86_64_4LEVEL (1ull << 46) > + > static efi_system_table_t *sys_table; > extern const bool efi_is64; > extern u32 image_offset; > @@ -717,6 +720,7 @@ unsigned long efi_main(efi_handle_t handle, > struct boot_params *boot_params) > { > unsigned long bzimage_addr = (unsigned long)startup_32; > + unsigned long buffer_start, buffer_end; > struct setup_header *hdr = &boot_params->hdr; > efi_status_t status; > unsigned long cmdline_paddr; > @@ -728,10 +732,33 @@ unsigned long efi_main(efi_handle_t handle, > efi_exit(handle, EFI_INVALID_PARAMETER); > > /* > - * If the kernel isn't already loaded at the preferred load > - * address, relocate it. > + * If the kernel isn't already loaded at a suitable address, > + * relocate it. > + * > + * It must be loaded above LOAD_PHYSICAL_ADDR. > + * > + * The maximum address for 64-bit is 1 << 46 for 4-level paging. This > + * is defined as the macro MAXMEM, but unfortunately that is not a > + * compile-time constant if 5-level paging is configured, so we instead > + * define our own macro for use here. > + * > + * For 32-bit, the maximum address is complicated to figure out, for > + * now use KERNEL_IMAGE_SIZE, which will be 512MiB, the same as what > + * KASLR uses. > + * > + * Also relocate it if image_offset is zero, i.e. we weren't loaded by > + * LoadImage, but we are not aligned correctly. > */ > - if (bzimage_addr - image_offset != hdr->pref_address) { > + > + buffer_start = ALIGN(bzimage_addr - image_offset, > + hdr->kernel_alignment); > + buffer_end = buffer_start + hdr->init_size; > + > + if ((buffer_start < LOAD_PHYSICAL_ADDR) || > + (IS_ENABLED(CONFIG_X86_32) && buffer_end > KERNEL_IMAGE_SIZE) || > + (IS_ENABLED(CONFIG_X86_64) && buffer_end > MAXMEM_X86_64_4LEVEL) || > + (image_offset == 0 && !IS_ALIGNED(bzimage_addr, > + hdr->kernel_alignment))) { > status = efi_relocate_kernel(&bzimage_addr, > hdr->init_size, hdr->init_size, > hdr->pref_address, > -- > 2.24.1 >