From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A188C7618E for ; Fri, 21 Apr 2023 13:30:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232331AbjDUNan (ORCPT ); Fri, 21 Apr 2023 09:30:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229843AbjDUNac (ORCPT ); Fri, 21 Apr 2023 09:30:32 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A84A613868 for ; Fri, 21 Apr 2023 06:30:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F15CD650A4 for ; Fri, 21 Apr 2023 13:30:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABC7FC43443; Fri, 21 Apr 2023 13:30:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682083814; bh=YO6d67EbEIrwfwGswrgU2nyKSaXVyTYf4KivmoLToEA=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=OKoguNMDRXWsqDH85Wd6YHRwFi7PX0HoUXliL4bkLINnTSWwKgS+CF533kl1te64v SK0tW90TDAhc0w6jy9AOMz10yTkUjZBEhgJ7JLWLTuLcTceJ0OugCvaV53tDvrcmth qPtSKWTyeiiw7ZNQf91hBiMnTaw31+N0ZB/pvVTYr3bORhR+rndCU4aUuQZm/3s7Qf Mea7AwMybgvt7yy9bLPBVFcXwFgonukFUdebz9b69Cc4rBJs8Iy0OpzoiDmq+CPjyM Tjs/2wMFJWR7hTgtB/pY5Bw1IcVlcbgmP3FaIzHKcwM+lL8hLCK2WWWnlK+PDoGADN cg5N8RiORp1NQ== Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 77BB527C0054; Fri, 21 Apr 2023 09:30:12 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute3.internal (MEProxy); Fri, 21 Apr 2023 09:30:12 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtgedgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtgfesthhqredtreerjeenucfhrhhomhepfdet nhguhicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenuc ggtffrrghtthgvrhhnpeeiteejleegjeekleegveeujeejvdehjeekveegudduudffueek jefffeeujeekhfenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghnugihodhmvghsmhhtphgr uhhthhhpvghrshhonhgrlhhithihqdduudeiudekheeifedvqddvieefudeiiedtkedqlh huthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuhigrdhluhhtohdruhhs X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 98C2231A0063; Fri, 21 Apr 2023 09:30:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-372-g43825cb665-fm-20230411.003-g43825cb6 Mime-Version: 1.0 Message-Id: <5694ea5d-da9a-413e-9499-02a54588a953@app.fastmail.com> In-Reply-To: <20230416120729.2470762-1-ardb@kernel.org> References: <20230416120729.2470762-1-ardb@kernel.org> Date: Fri, 21 Apr 2023 06:29:51 -0700 From: "Andy Lutomirski" To: "Ard Biesheuvel" , linux-efi@vger.kernel.org Cc: "Linux Kernel Mailing List" , "Evgeniy Baskov" , "Borislav Petkov" , "Dave Hansen" , "Ingo Molnar" , "Peter Zijlstra (Intel)" , "Thomas Gleixner" , "Alexey Khoroshilov" , "Peter Jones" , "Gerd Hoffmann" , "Dave Young" , "Mario Limonciello" , "Kees Cook" , "Tom Lendacky" , "Kirill A. Shutemov" , "Linus Torvalds" Subject: Re: [RFC PATCH 0/3] efi: Implement generic zboot support Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 16, 2023, at 5:07 AM, Ard Biesheuvel wrote: > This series is a proof-of-concept that implements support for the EFI > zboot decompressor for x86. It replaces the ordinary decompressor, and > instead, performs the decompression, KASLR randomization and the 4/5 > level paging switch while running in the execution context of EFI. I like the concept. A couple high-level questions, since I haven=E2=80=99= t dug into the code: Could zboot and bzImage be built into the same kernel image? That would= get this into distros, and eventually someone could modify the legacy p= ath to switch to long mode and invoke zboot (because zboot surely doesn=E2= =80=99t need actual UEFI =E2=80=94 just a sensible environment like what= UEFI provides.) Does zboot set up BSS correctly? I once went down a rabbit hole trying = to get the old decompressor to jump into the kernel with BSS already usa= ble and zeroed, and the result was an incredible mess =E2=80=94 IIRC the= decompressor does some in-place shenanigans that looked incompatible wi= th handling BSS without a rewrite. And so we clear BSS in C after jumpin= g to the kernel, which is gross. =E2=80=94Andy > > This simplifies things substantially, and makes it straight-forward to > abide by stricter future requirements related to the use of writable a= nd > executable memory under EFI, which will come into effect on x86 systems > that are certified as being 'more secure', and ship with an even shini= er > Windows sticker. > > This is an alternative approach to the work being proposed by Evgeny [= 0] > that makes rather radical changes to the existing decompressor, which > has accumulated too many features already, e.g., related to confidenti= al > compute etc. > > EFI zboot images can be booted in two ways: > - by EFI firmware, which loads and starts it as an ordinary EFI > application, just like the existing EFI stub (with which it shares > most of its code); > - by a non-EFI loader that parses the image header for the compression > metadata, and decompresses the image into memory and boots it. > > Realistically, the second option is unlikely to ever be used on x86, > given that it already has its existing bzImage, but the first option is > a good choice for distros that target EFI boot only (and some distros > switched to this format already for arm64). The fact that EFI zboot is > implemented in the same way on arm64, RISC-V, LoongArch and [shortly] > ARM helps with maintenance, not only of the kernel itself, but also the > tooling around it relating to kexec, code signing, deployment, etc. > > Series can be pulled from [1], which contains some prerequisite patches > that are only tangentially related. > > [0] https://lore.kernel.org/all/cover.1678785672.git.baskov@ispras.ru/ > [1]=20 > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=3D= efi-x86-zboot > > Cc: Evgeniy Baskov > Cc: Borislav Petkov > Cc: Andy Lutomirski > Cc: Dave Hansen > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Alexey Khoroshilov > Cc: Peter Jones > Cc: Gerd Hoffmann > Cc: Dave Young > Cc: Mario Limonciello > Cc: Kees Cook > Cc: Tom Lendacky > Cc: Kirill A. Shutemov > Cc: Linus Torvalds > > Ard Biesheuvel (3): > efi/libstub: x86: Split off pieces shared with zboot > efi/zboot: x86: Implement EFI zboot support > efi/zboot: x86: Clear NX restrictions on populated code regions > > arch/x86/Makefile | 18 +- > arch/x86/include/asm/efi.h | 10 + > arch/x86/kernel/head_64.S | 15 + > arch/x86/zboot/Makefile | 29 + > drivers/firmware/efi/Kconfig | 2 +- > drivers/firmware/efi/libstub/Makefile | 15 +- > drivers/firmware/efi/libstub/Makefile.zboot | 2 +- > drivers/firmware/efi/libstub/efi-stub-helper.c | 3 + > drivers/firmware/efi/libstub/x86-stub.c | 592 +---------------= --- > drivers/firmware/efi/libstub/x86-zboot.c | 322 ++++++++++ > drivers/firmware/efi/libstub/x86.c | 612 ++++++++++++++++= ++++ > drivers/firmware/efi/libstub/zboot.c | 3 +- > drivers/firmware/efi/libstub/zboot.lds | 5 + > 13 files changed, 1031 insertions(+), 597 deletions(-) > create mode 100644 arch/x86/zboot/Makefile > create mode 100644 drivers/firmware/efi/libstub/x86-zboot.c > create mode 100644 drivers/firmware/efi/libstub/x86.c > > --=20 > 2.39.2