Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1262907ybf; Thu, 27 Feb 2020 07:43:32 -0800 (PST) X-Google-Smtp-Source: APXvYqygHykEOeCYTalz9J9BzM5TTZtqKtDPuFkJHVYEjBI+7dqxmsitD1DEKHjrCxX/4ILIuwcm X-Received: by 2002:a9d:138:: with SMTP id 53mr247169otu.334.1582818212295; Thu, 27 Feb 2020 07:43:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582818212; cv=none; d=google.com; s=arc-20160816; b=k20i0Rc5XdSRF1rDD4mqKQkO8tY7kI/b6ljn64vExFRNCCJA1mzdRODz6bgoLjr0in sU9HMgIqma4WUZ9WyEM9+KsV0hlGWvITMA1lV122HhtuSblmNEDEus0kZlWtNpg/cpo8 tz0vu50R/gRjpakKi7025dw1SXMM2nkjcLXllJ9zdzlWuvjDhaVQeOJ4buJ1S2I3D6Fw uwIcy51eFioj5M+aRxhrJpOjvFRauQZf1N9aPtR5UQ3oDCuxfA+6ehhsZWyNn+CeelFg OOgoa0e4+g51j1aAVlWkHjL/nmcSbQZ1na65gOkDunChCkImWcmVCPbgsmtQWvycj9LD 3Czg== 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=Ky4iV8KvpFnf5XR+ohqW3o+qDdLzs3iYPxTnXhZD1io=; b=GHSU31z7kHuh/ndzruvhSPp/paInTVEeGTIQET7euhlrc2I/VOHdFLQWQtVY+6Y7lJ 11M9zKB8Um6TfzTiGcZDIE6SmUwCT3GnKirU+K6YB4ou9cxRJ39xYQLOoNgHs4Nmz3c3 iSj0QpzDJqsmWMawgaSDWKB5IXeRzVONfUhwiSpUuEWZMXqRhKKgx0ENo69U7PxKkxhf KoB1cJnxxYX2gH6tKd/xF0UL/cp4dX0CHI6zvjeY5qfgUbMyq8+0JbofaR8xiAEthdCU j7/ViwKbdeki4i00+3Y+UPZAI67R+S62HOnSHlBGVqXdRzokH5w47WqfNk+8Q0wQ5ZdP J87A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=DNFTwP3X; 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 a22si1832754otp.84.2020.02.27.07.43.04; Thu, 27 Feb 2020 07:43:32 -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=DNFTwP3X; 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 S1729697AbgB0PVs (ORCPT + 99 others); Thu, 27 Feb 2020 10:21:48 -0500 Received: from mail.kernel.org ([198.145.29.99]:35498 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729471AbgB0PVs (ORCPT ); Thu, 27 Feb 2020 10:21:48 -0500 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.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 D9BFA246A1 for ; Thu, 27 Feb 2020 15:21:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582816907; bh=T9dOLKG0py6qkERLpwlSZyviHQ5P0/AANhjFWasQW80=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DNFTwP3XbjZEMxBVDzd/quWeQ2/givNf4BqjbJUoBPmedhklbXBelhZr8GpvLHpCE SDoAFGlNWK/md5syoNfAGLlhELV6qjO70qCIiIDrLn0GuT8lh91ANWgt+HCVgwq4Fw T4DZ6SqgsMZW6AdxaIywRMs8s2xuTpeuZboaNmT0= Received: by mail-wr1-f45.google.com with SMTP id y17so3841308wrn.6 for ; Thu, 27 Feb 2020 07:21:46 -0800 (PST) X-Gm-Message-State: APjAAAW0z2PUxSOlR7I3lieV29m7EMYxN9+KAiVpU6TsMnYy0zxq0pI0 DYsayUT/gcTR2inMhVyjP8p1n5Tn6yZL2+rt7ASjtw== X-Received: by 2002:a05:6000:110b:: with SMTP id z11mr5530464wrw.252.1582816905187; Thu, 27 Feb 2020 07:21:45 -0800 (PST) MIME-Version: 1.0 References: <20200226204515.2752095-1-nivedita@alum.mit.edu> <20200226230031.3011645-2-nivedita@alum.mit.edu> <20200227081229.GA29411@gmail.com> <20200227151643.GA3498170@rani.riverdale.lan> In-Reply-To: <20200227151643.GA3498170@rani.riverdale.lan> From: Ard Biesheuvel Date: Thu, 27 Feb 2020 16:21:32 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/1] x86/boot/compressed: Fix reloading of GDTR post-relocation To: Arvind Sankar Cc: Ingo Molnar , linux-efi , Thomas Gleixner , "the arch/x86 maintainers" , Linux Kernel Mailing List , Borislav Petkov 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 Thu, 27 Feb 2020 at 16:16, Arvind Sankar wrote: > > On Thu, Feb 27, 2020 at 09:12:29AM +0100, Ingo Molnar wrote: > > > > * Arvind Sankar wrote: > > > > > Commit ef5a7b5eb13e ("efi/x86: Remove GDT setup from efi_main") > > > introduced GDT setup into the 32-bit kernel's startup_32, and reloads > > > the GDTR after relocating the kernel for paranoia's sake. > > > > > > Commit 32d009137a56 ("x86/boot: Reload GDTR after copying to the end of > > > the buffer") introduced a similar GDTR reload in the 64-bit kernel. > > > > > > The GDTR is adjusted by init_size - _end, however this may not be the > > > correct offset to apply if the kernel was loaded at a misaligned address > > > or below LOAD_PHYSICAL_ADDR, as in that case the decompression buffer > > > has an additional offset from the original load address. > > > > > > This should never happen for a conformant bootloader, but we're being > > > paranoid anyway, so just store the new GDT address in there instead of > > > adding any offsets, which is simpler as well. > > > > > > Signed-off-by: Arvind Sankar > > > Fixes: ef5a7b5eb13e ("efi/x86: Remove GDT setup from efi_main") > > > Fixes: 32d009137a56 ("x86/boot: Reload GDTR after copying to the end of the buffer") > > > > Have you or anyone else observed this condition practice, or have a > > suspicion that this could happen - or is this a mostly theoretical > > concern? > > > > Thanks, > > > > Ingo > > Right now it's a theoretical concern. > > I'm working on another patch, to tell the EFI firmware PE loader what > the kernel's preferred address is, so that we can avoid having to > relocate the kernel in the EFI stub in most cases (ie if the PE loader > manages to load us at that address). With those changes, the required > adjustment won't be init_size - _end any more, and while fixing it up > there, I noticed that it could already be the case that the required > adjustment is different. > Do you mean setting the image address in the PE/COFF header to the preferred address?