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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AB9AC43334 for ; Wed, 20 Jul 2022 17:03:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8C4026B0071; Wed, 20 Jul 2022 13:03:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 873876B0073; Wed, 20 Jul 2022 13:03:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73A526B0074; Wed, 20 Jul 2022 13:03:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 649ED6B0071 for ; Wed, 20 Jul 2022 13:03:53 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3E6FE1C5BCB for ; Wed, 20 Jul 2022 17:03:53 +0000 (UTC) X-FDA: 79708100346.22.D6F0927 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf22.hostedemail.com (Postfix) with ESMTP id B9630C0093 for ; Wed, 20 Jul 2022 17:03:52 +0000 (UTC) Received: by mail-yb1-f169.google.com with SMTP id i14so33179168yba.1 for ; Wed, 20 Jul 2022 10:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YOA19tVTAiTzTuOKYOjsbz3H5LWG3tc39ee1PdsInaY=; b=eH8DfSUXfgZbV4o8x2tqd+uHCK00gNxyeV23UnRyl2NEqFrrv5LwU2PG2xBhksRNcP qS7iLrMIZpsxtaEQ/qBskkcrdLuCYYgMzLi+TtbuSs4f5MgiwniXAlxCsETB6+1IRAmE rMTt6csKOwhCtw0ESoG2dWiOJS/Ce4cmZCfR74QtEUlVZTimDvnzoGl7jkYN6DsnUUf1 /W3fid4i309QeRCWguiNIhdqU9ADeJR3BpajeUJx5/Y+QufmNFVk+GCEY16adfuvEO3h Fv3C1jB+2yMiBwC5Lr1BTkWHTDH4MrmxTcKUycRCIE8UUlUCcTG8SNOuGKPBPBgFHuRX TTZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YOA19tVTAiTzTuOKYOjsbz3H5LWG3tc39ee1PdsInaY=; b=0h2WlgvCSuozIgZa4Y5BMNvXaZyuq7xMItJblduuZLvNDlqnkmv/60lbfxEQeSdPBl EWQ20GBBSEBfk+qhhulLuDFB0BehREYPgl1giq2zVwmegaPvFU3gVpLJZ1/ClT3G224v dI27PEMhtKyGwbyeH2XLJwT3V9llnPBNuv+qf4i+Kc0Xl3Th48n4EM8cYx7/LZalbde9 e1V71jB/usa0BOzJ8at8KXx+yYCwLHNC3JW7bRaK5VwinOBtx+tp8X0xh9radhSAh5fv ffC4vbIz8cspFSA3qa7L2N1wKeQVd8qioZA2dphzp91dTQufDigblHmFUMXuli2kNnUT 8nQQ== X-Gm-Message-State: AJIora/eswk8BcyYduD7JhLEBLANkngajHz+rlOIwrKJGRae/xuMrgOT vDg0VnX/jkUpEnLAE7G5Zpwqwb3yTyfT6qMajzkwJg== X-Google-Smtp-Source: AGRyM1uXDNpNChJqMpeAj68PB9QtQc3sH/drFsMIMDp7snrUyeSTOG30AnpLZhkLxTTfI4lMQ6NISaGgHQQJP5Q7AZQ= X-Received: by 2002:a05:6902:1082:b0:670:9307:b0eb with SMTP id v2-20020a056902108200b006709307b0ebmr5042788ybu.335.1658336631697; Wed, 20 Jul 2022 10:03:51 -0700 (PDT) MIME-Version: 1.0 References: <22d54786-bc12-ecc5-2b37-cbaa56090aa8@intel.com> In-Reply-To: From: Marc Orr Date: Wed, 20 Jul 2022 10:03:40 -0700 Message-ID: Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory To: Borislav Petkov Cc: Dave Hansen , Ard Biesheuvel , Dionna Amalie Glaze , "Kirill A. Shutemov" , Peter Gonda , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Mike Rapoport , David Hildenbrand , Marcelo Cerri , tim.gardner@canonical.com, Khalid ElMously , philip.cox@canonical.com, "the arch/x86 maintainers" , Linux Memory Management List , linux-coco@lists.linux.dev, linux-efi , LKML , "Yao, Jiewen" Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=eH8DfSUX; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of marcorr@google.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=marcorr@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658336632; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YOA19tVTAiTzTuOKYOjsbz3H5LWG3tc39ee1PdsInaY=; b=fnvQ9fir1IcpjgryZ/rPdlt1fOJM+u0pRGvfdum5PjP6WYcxlk+7H2AXhE66CgxAq4D8YB iDZjz5Qwv9upr8jGm4nDSaNzX0/7ptQtOXrSnDFFZbQyGjwcT2UhbMS381/o7P6QndLBYF 3pUVNFjEYJeDkw0xzKFLn0OA0GhB+Ms= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658336632; a=rsa-sha256; cv=none; b=YqzR4goaTeSUyXPkhpjniAadd/BDSEcl0raiQA9ar+t7xcCI3dVrO+Lq6EKLmU25UeaGRQ xfMiOPDQAbyn1sUS0sWJXm8WVoAS80TEwJ57/DNXp+/ALAlPhhFKsthcGKLJsj86mSHAzq pHSgNvyvIvD9yZqTT/sd50henwhn9BM= X-Stat-Signature: 76gdhjhc3scd7ratuqcu75twf47ujq4q X-Rspamd-Queue-Id: B9630C0093 X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=eH8DfSUX; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of marcorr@google.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=marcorr@google.com X-Rspamd-Server: rspam11 X-HE-Tag: 1658336632-794365 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jul 19, 2022 at 10:44 PM Borislav Petkov wrote: > > On Tue, Jul 19, 2022 at 05:26:21PM -0700, Marc Orr wrote: > > These feature tags are a mess to keep track of. > > Well, looking at those tags, it doesn't look like you'll stop using them > anytime soon. > > And once all the required SNP/TDX features are part of the guest image, > - including unaccepted memory - if anything, you'll have less tags. > > :-) Yeah, once all of the features are a part of the guest image AND any older images with SNP/TDX minus the features are deprecated. I agree. > > - Do we anticipate (many) more features for confidential compute in > > the future that require code in both the guest FW and guest kernel? If > > yes, then designing a FW-kernel feature negotiation could be useful > > beyond this situation. > > Good question. > > > - Dave's suggestion to "2. Boot some intermediate thing like a > > bootloader that does acceptance ..." is pretty clever! So if upstream > > thinks this FW-kernel negotiation is not a good direction, maybe we > > (Google) can pursue this idea to avoid introducing yet another tag on > > our images. > > Are those tags really that nasty so that you guys are looking at > upstream changes just to avoid them? Generally, no. But the problem with tags is that distros tag their images wrong sometimes. And that leads to problems. For example, I just got a bug assigned to me yesterday about some ARM image tagged as SEV_CAPABLE. Oops. Lol :-). (Though, I'm pretty sure we won't try to boot an ARM image on a non-ARM host anyway; but it's still wrong...) That being said, this lazy accept problem is sort of a special case, since it requires deploying code to the guest FW and the guest kernel. I'm still relatively new at all of this, but other than the SNP/TDX-enlightenment patches themselves, I haven't really seen any other examples of this. So that goes back to my previous question. Is this going to happen a lot more? If not, I can definitely see value in the argument to skip the complexity of the FW/kernel feature negotiation. Another thing I thought of since my last reply, that's mostly an internal solution to this problem on our side: Going back to Dave's 10k-foot view of the different angles of how to solve this. For "1. Deal with that at the host level configuration", I'm thinking we could tag the images with their internal guest kernel version. For example, if an image has a 5.15 kernel, then we could have a `KERNEL_5_15` tag. This would then allow us to have logic in the guest FW like: if (guest_kernel_is_at_least(/*major=*/5, /*minor=*/15) enable_lazy_accept = true; One detail I actually missed in all of this, is how the guest image tag gets propagated into the guest FW in this approach. (Apologies for this, as that's a pretty big oversight on my part.) Dionna: Have you thought about this? Presumably this requires some sort of paravirt for the guest to ask the host. And for any paravirt interface, now we need to think about if it degrades the security of the confidential VMs. Though, using it to get the kernel version to decide whether or not to accept the memory within the guest UEFI or mark it as unaccepted seems fine from a security angle to me. Also, tagging images with their underlying kernel versions still seems susceptible to mis-labeling. But this seems like it can be mostly "fixed" via automation (e.g., write a tool to boot the guest and ask it what it's kernel version is and use the result to attach the tag). Also, tagging the images with their kernel version seems like a much more general solution to these sorts of issues. Thoughts?