From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by mx.groups.io with SMTP id smtpd.web10.177451.1673898207809493347 for ; Mon, 16 Jan 2023 11:43:27 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20210112 header.b=ZcgKRE6T; spf=pass (domain: google.com, ip: 209.85.215.170, mailfrom: dionnaglaze@google.com) Received: by mail-pg1-f170.google.com with SMTP id g68so19253072pgc.11 for ; Mon, 16 Jan 2023 11:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QnxAd4xLU7p98OVD+hAsykoKTEdCqXWogG3RU5BW2po=; b=ZcgKRE6TB59mnjD/69kiQ20Z15m7bNSMriL7cCAPHuh6s0qMmw+VhH9/on66EdmyjG dw+fC/siS31TgmABCX7jG5ljxR34baQbn2QAFlOMyC6RoGGt0sl6Dd01TGoSs81kW41H /m/0cOLtBkTdCpNSq4jwfCUtu7SCSzahq6v+iqF2maHjILg/pM08hFgRULqBCmUyhUsq kIukAxQBh2juj0YJZlLd3PTYG7FL7Ki0fVwqAYNnBNQCB03cmbfOtUZqOzMyI5W+mrJE p22Uh2fLoOQWfDXIUAhqVxLH/MYPc9NlmffBKuwgjR/77qDogUgwsWcBzSpIgev0q2DU 4jBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QnxAd4xLU7p98OVD+hAsykoKTEdCqXWogG3RU5BW2po=; b=jY3bX/MieCASidi/WiJd1KOz2zHjt2AaV4qscnF2R2x0H1f2yF3N7k7yYBSEOxg2qm vmaxLD9wszfEdfLbeytC7TuEXYbdxXCdv04QJkUGOp3hyI/eiW9qZi3NY0IYLFoyX+4Z bXanMPhSZAQqCqtPpFDAXNTWYpQ/zK2NteerCTdNraJryXHnG1mqOWwwW4cVmvO483M8 ELAWMGIN2QR6Y6QClAm6ewiBEe4ZoprSobQsJ7P/G3MubwyDOcJrn3og64EvPErWf534 LjzgUUs0e8TicHIYAQ+z+HZXCwaL4sZ8daP3ncztZwXV0ouX5Fj8aMpnXHDj9iqG+Zu8 JuqQ== X-Gm-Message-State: AFqh2kpYwOZA+Y2hoBdKTFMw4Hp43nFNq03fjfJcWhUzjxFc0mCf/I2b 3nuJcmGKUKDCxNAZZ02etp5WnCZBWlc+AFyWA0H2sw== X-Google-Smtp-Source: AMrXdXvRa28f2drx0DONjUaAUAdPmnXdgxceoVRg7DzO+7/OGGo7wfvJ9qE3DzAJUOTUVpW5+88s6/wvOr8nM4thdqw= X-Received: by 2002:a63:db57:0:b0:478:e542:7d77 with SMTP id x23-20020a63db57000000b00478e5427d77mr12990pgi.101.1673898207101; Mon, 16 Jan 2023 11:43:27 -0800 (PST) MIME-Version: 1.0 References: <20230113212926.2904735-1-dionnaglaze@google.com> <20230113222024.rp2erl54vx3grdbd@box.shutemov.name> <20230116105648.63hsxnmj2juwudmu@sirius.home.kraxel.org> <20230116123057.wvr6rz7y3ubgcm5z@box.shutemov.name> <20230116134246.soworigs56bz5v7o@box.shutemov.name> In-Reply-To: <20230116134246.soworigs56bz5v7o@box.shutemov.name> From: "Dionna Glaze" Date: Mon, 16 Jan 2023 11:43:15 -0800 Message-ID: Subject: Re: [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI To: "Kirill A. Shutemov" Cc: Ard Biesheuvel , Gerd Hoffmann , "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, x86@kernel.org, jiewen.yao@intel.com, devel@edk2.groups.io, "Min M. Xu" , James Bottomley , Tom Lendacky , Erdem Aktas , Dave Hansen Content-Type: text/plain; charset="UTF-8" > > I still don't understand why we need to support every imaginable > > combination of firmware, bootloader and OS. Unaccepted memory only > > exists on a special kind of virtual machine, which provides very > > little added value unless you opt into the security and attestation > > features, which are all heavily based on firmware protocols. So why > > should care about a EFI-aware bootloader calling ExitBootServices() > > and subsequently doing a legacy boot of Linux on such systems? > > Why break what works? Some users want it. > The users that want legacy boot features will not be broken, they'll only get a safe view of the memory map. I don't think it's right to choose unsafe behavior for a legacy setup. > This patch adds complexity, breaks what works and the only upside will > turn into a dead weight soon. > > There's alternative to add option to instruct firmware to accept all > memory from VMM side. It will serve legacy OS that doesn't know about > unaccepted memory and it is also can be use by latency-sensitive users > later on (analog of qemu -mem-prealloc). > This means that users of a distro that has not enabled unaccepted memory support cannot simply start a VM with the usual command, but instead have to know a baroque extra flag to get access to all the memory that they configured the machine (and for a CSP customer, paid for). That's not a good experience. With GCE at least, you can't (shouldn't) associate the boot feature flag with a disk image because disks are mutable. If a customer upgrades their kernel after initially starting their VM, they can't remove the flag due to the way image annotations work. All of this headache goes away by adopting a small patch to the kernel that calls a 0-ary protocol interface and keeping safe acceptance behavior in the firmware. I think Gerd is right here that we should treat it as a transition feature that we can remove later. > -- > Kiryl Shutsemau / Kirill A. Shutemov -- -Dionna Glaze, PhD (she/her)