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 B5FD1C04A68 for ; Thu, 28 Jul 2022 22:02:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7D096B0071; Thu, 28 Jul 2022 18:02:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2C8A8E0001; Thu, 28 Jul 2022 18:02:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ACD226B0073; Thu, 28 Jul 2022 18:02:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9DA656B0071 for ; Thu, 28 Jul 2022 18:02:05 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6473AA15E7 for ; Thu, 28 Jul 2022 22:02:05 +0000 (UTC) X-FDA: 79737882210.14.759C7D8 Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf24.hostedemail.com (Postfix) with ESMTP id DB60D180039 for ; Thu, 28 Jul 2022 22:02:04 +0000 (UTC) Received: by mail-yb1-f170.google.com with SMTP id j63so5366715ybb.13 for ; Thu, 28 Jul 2022 15:02:04 -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=KKJMz2p0fMbqbmhUA2NRK8taNgQHWFCPCykk0R/nVkQ=; b=BIAqjFwuvscZyaQvaO2Pp5Tm2K8Fcr9ETnXvpU5e3wVsse21Jc6+b/sSURRzcM4QRX f+AUZdMnE7et9mw5oGUM8bOIP7AqPCPEFZ5JFqKRH4odWmwDZ0FjP8rMMLUG8y3aCwAh lwgedBwQkhfs5enr6DiCZ/gKqdYfyYsGa6781lN44ppqnMvdnKWZaI1L0KYuIh0w3h/W Ex4VAWe01YlKol56ws7q0/gUwiDhufvbMAS97qfg8YmOtZ7iNvuxcaVvr0OuapoWpqSG zk5SMyBnMxjyNUeOtF5G284TFqrCbKyKwnrUsp1SvrzycKfu/wMWOIfliAogPsiP7m2l e2ug== 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=KKJMz2p0fMbqbmhUA2NRK8taNgQHWFCPCykk0R/nVkQ=; b=GCFb8snMJB24N6ItA+kjt7KKoaYMxGTYkk36d/MUiQOC/WkR3vbW7O25Hd6NFynrH+ ZY4W0uKHNb9A+lz5hJGIy/7Zd82OQuAeVVNu3UJgxN36rF26XyqVIGVxlZX5CSd+OXd8 z3jGTWfXfQzYSrZpUpJmGQYajSuVy3VFblxEa/Gu3qIlHL45YOVyTT99tkICHNbUuFsI Eqf1dp+l/66Q9dMjGpNuyMoWI/EAFLH7aG9EEUgTu6N2vryEkpXkekveJESyH5+rQfUU jVG4QpTSYCYNqPzP/ZOFEO9SgWFSq3MkJJM87w1aFLExNicTH0JGmgtOsz4BQNKEufx5 ItbA== X-Gm-Message-State: ACgBeo0mSmQn+PcYq2eRB26xytxXVNVwrWC5VUemQWNUdeujsQIHvj8n C5d0+8/6lfY1IZuqapq0nG/cphN7rk/MuzrDLtK1Vg== X-Google-Smtp-Source: AA6agR6CsM1GKbxoIN8NWcO7GQfLofiour4J2FuUY6Juif22kb1aJ6rJGRSLyGPjmgf+UOW6vfxySZ2NKkNcgLC9zMk= X-Received: by 2002:a05:6902:128d:b0:670:9009:f859 with SMTP id i13-20020a056902128d00b006709009f859mr549949ybu.321.1659045723977; Thu, 28 Jul 2022 15:02:03 -0700 (PDT) MIME-Version: 1.0 References: <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> <20220718172159.4vwjzrfthelovcty@black.fi.intel.com> <22d54786-bc12-ecc5-2b37-cbaa56090aa8@intel.com> In-Reply-To: From: Dionna Amalie Glaze Date: Thu, 28 Jul 2022 15:01:52 -0700 Message-ID: Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory To: Ard Biesheuvel Cc: Dave Hansen , Marc Orr , Borislav Petkov , "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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659045724; a=rsa-sha256; cv=none; b=e6QKSCLNW2LQx/4xZ9MvgkqTF0TrrL56enwiauBXOakE7M9oJoXXJsBn5vH54m1n7d7ebP E3D2DnFKNmACFWz7AiOetUeDK/f6MMVk3MrOD734FVNcexVNFb2H/0kBf+KsxaSYOmMSuW HazMXVs+SPHMdv0t3G0xmcabe7s3tcA= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BIAqjFwu; spf=pass (imf24.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659045724; 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=KKJMz2p0fMbqbmhUA2NRK8taNgQHWFCPCykk0R/nVkQ=; b=7sUWc4L2b33k06tlON+IFKoQcg0I1/8fKZHpjlt6xw+jEEgZ2GwCiV5qNEcFUssqpEXSdA 5WepKv/RQEFtXwba6cmNJYd7BoFVt8y/48rl+0EZugSk8xX49hcIMlYLUNKK2X9ELm0/uy AnU4S8BH49ByNwyVwf+NqYbHchDRCt0= X-Rspamd-Queue-Id: DB60D180039 X-Rspam-User: X-Stat-Signature: a4rtg49o5zj395ozcd3zsuh7p8qi49t7 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BIAqjFwu; spf=pass (imf24.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam08 X-HE-Tag: 1659045724-686510 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: > > What I strongly object to is inventing a new bespoke way for the > firmware to make inferences about the capabilities of the image by > inspecting fields in the file representation of the image (which is > not guaranteed by EFI to be identical to its in-memory representation, > as, e.g., the PE/COFF header could be omitted by a loader without > violating the spec) > > As for the intermediate thing: yes, that would be a valuable thing to > have in OVMF (and I will gladly take EDK2 patches that implement > this). However, I'm not sure how you decide whether or not this thing > should be active or not, doesn't that just move the problem around? This does just move the problem around, but it makes correct behavior the default instead of silently ignoring most of the VM's memory and booting regularly. I have the driver mostly written to change the behavior to accept all by default unless a driver has been installed to set a particular boolean to make it not. Still that's yet another thing as you say. I agree with everyone that this situation just stinks. "Can't you just boot it?" was asked before, and yes we can, but at the scale of a CSP managing anybody's image uploads, that not-insignificant cost has to be paid by someone. It's a hard problem to route the image to the right kind of machine that's expected to be able to run it... it's a big ol' mess. One thing is for sure: these patches shouldn't be blocked by the "how do we detect it" question. I'm glad to see so much engagement with this problem, but I fear I might have delayed its progress towards a merge. I know AMD has a follow-up to add SEV-SNP accept_memory support to finish this all up. I'll try to get the ear of all the distributions that are tracking towards providing SEV-SNP-supported images for CSPs to get them on the release that includes these patches. I'll also see about upstreaming that EFI driver and EDK2 changes in case there's a slip in the kernel release and we need this workaround. -- -Dionna Glaze, PhD (she/her)