From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.18924.1674056783883520479 for ; Wed, 18 Jan 2023 07:46:24 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HGktXM+t; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) 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 EFEBA618B6 for ; Wed, 18 Jan 2023 15:46:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43A8FC4339C for ; Wed, 18 Jan 2023 15:46:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674056782; bh=lJ/kwmiQYsl9y9vng7yDw5HKTngvmR93U8NLEJb0qC8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=HGktXM+t0fav2jneq3mlMvIxWBD0QL/poes7B/slAUYayFIgsJRoq7GMyWxQHyQ30 DYwofhaZCBfUySVcz1+zOh/BO7XS/9vdrb5FbY0Ztp0gnnubaX/uCDceFDUC2B7naf XJHto2uEPugeT0p7yw/0hrAoP4vu0n3cl/zEIkwoQRFCYkonCQ2wvsSpjOSbQ8B7Ka 14JkWnDCqVeZr+L5JTwPVxT1syzgByDDMXLoOiFzlR/yYLvsLkB4MD5ThrGS3AqloN A8KHdzZHCPWrpesaPKVueVOIzTOdw9RqO+tVoWM7ppGc09qDM+DhL8ByhiJ9Mt74TE 86p41mhSUyR3A== Received: by mail-lf1-f51.google.com with SMTP id b3so52256865lfv.2 for ; Wed, 18 Jan 2023 07:46:22 -0800 (PST) X-Gm-Message-State: AFqh2kqpmH8fpWvI4u93shpv9tG6DUc2IGSLJoPTakgRBUzCLCZACp1j NobtSftLhupqf0X0WMLjdAheVTx+aIALgXZl9eE= X-Google-Smtp-Source: AMrXdXvKd2ozhrn+S6d4qTJhm2W4B4noZo8m76bKLACYxbKqjGgo6a44usnJhpG+sf2bB37FJHUokCJHIo3g/InSZOY= X-Received: by 2002:a19:c501:0:b0:4b8:9001:a694 with SMTP id w1-20020a19c501000000b004b89001a694mr380330lfe.426.1674056780228; Wed, 18 Jan 2023 07:46:20 -0800 (PST) MIME-Version: 1.0 References: <20230113212926.2904735-1-dionnaglaze@google.com> <20230113222024.rp2erl54vx3grdbd@box.shutemov.name> <20230116105648.63hsxnmj2juwudmu@sirius.home.kraxel.org> <1818a72f-31ef-07b0-d1b4-6a8904636db2@amd.com> In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 18 Jan 2023 16:46:09 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI To: Dave Hansen Cc: Tom Lendacky , Matthew Garrett , Mark Rutland , Borislav Petkov , Gerd Hoffmann , "Kirill A. Shutemov" , Dionna Glaze , 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 , Erdem Aktas , Dave Hansen Content-Type: text/plain; charset="UTF-8" On Wed, 18 Jan 2023 at 16:41, Dave Hansen wrote: > > On 1/18/23 07:09, Ard Biesheuvel wrote: > > However, I guess we're at a point where SEV and TDX really want > > different solutions, so I think divergence might be the way to > > proceed. > > I don't think they want different things really. > > TDX doesn't need this protocol. It sounds like SEV does need it, > though. That doesn't mean they really diverge. They're *both* going to > have to poke at this protocol knob to get the firmware to not accept the > memory. > No, on TDX, the firmware would never accept all memory. On SEV, it would only do so if the protocol has not been called prior to the call to ExitBootServices(). > This does slightly change the motivation for doing explicit unaccepted > memory support in the kernel. > Not on TDX. > I also don't know _quite_ how this will look to a guest. For instance, > will they see different memory maps based on which protocol they are > using? I assume so, but didn't see any of that explicitly mentioned in > this patch. The EFI memory map will not contain ranges of type EFI_UNACCEPTED_MEMORY if the memory was accepted on behalf of the OS by the firmware. That is the point, really, as non-enlightened OSes will ignore those.