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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32848C07E9B for ; Tue, 20 Jul 2021 19:54:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A738A60234 for ; Tue, 20 Jul 2021 19:54:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A738A60234 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1E1526B0011; Tue, 20 Jul 2021 15:54:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 191F96B0036; Tue, 20 Jul 2021 15:54:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 00B0F6B006C; Tue, 20 Jul 2021 15:54:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0042.hostedemail.com [216.40.44.42]) by kanga.kvack.org (Postfix) with ESMTP id BF7D06B0011 for ; Tue, 20 Jul 2021 15:54:30 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4948C20BCE for ; Tue, 20 Jul 2021 19:54:29 +0000 (UTC) X-FDA: 78384018258.25.01E553F Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by imf19.hostedemail.com (Postfix) with ESMTP id 0873EB00047C for ; Tue, 20 Jul 2021 19:54:28 +0000 (UTC) Received: by mail-pj1-f44.google.com with SMTP id h6-20020a17090a6486b029017613554465so247036pjj.4 for ; Tue, 20 Jul 2021 12:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZeLArdOwF4c3/dM031IJ0PsQhPF9cHure1pZVMgRz14=; b=Ycdyq1Koqw5nqatustzX/3lxSMyaJ3MBd0LBcRK3vSZHgVkW5p3TptELx63aOLsZvj dSpcMfWs3+55T1t4bJzGjjnxwT+SuW5IkWd5Lx2Z8jh0RitqG2idOsaonGxj2fqo8R0y TM9Qy1fzy2zBMh0ZGkjm880ga1/5m309u/y18pMyZYmgTZRK8PE5CAJMJ2xygsNSaqcJ LLHdgb7Oc1TXfEKxLArgHccTQIjDSqpHVd7nlAnvApAK0LjqIgzbUYVry2qlHcZT9XGn jK9U4JMnLXhF3nj8lY6vkGvzoZmT7lyWiwZUYfniF4i2hS9WL7A3RILu0v5RqdY6qJhd AXhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZeLArdOwF4c3/dM031IJ0PsQhPF9cHure1pZVMgRz14=; b=fJQfi2yh4c5gse4TC9iStz7RRUCGyvk6G4DazYTvzPdMFCmx7kDvZTWIZFCE1qFjB4 lSfg6Xdp4BpChnXG1r+mEskaoiEmW7m+Pb1MLYcXUM4fC9Y078nUWoui400Nfv0fZPaw 3zJFTK/sc3qmz+W51+Z34APHyMYTnxYByfNDpdIifeLACMpbu090qp1mneHw6Kt1KyMw YOWY+Svk1Dms6rishXlhYQRx3DvlMoiOHgCFYwBnPkMkksyQfddMT1NSrf5A6Lt6ax/d 8Ovqlr+fO+0jJRpdFW+Y3q0jf+Rps7badsBXjUX9mqGgY+hNHunOqQxeKXBOIlMy7Kgc 2DTw== X-Gm-Message-State: AOAM531KX3BnN/DU1eSF8vfmwhU/CFBnppD5fBntVTHb87RVJrRxmgIm eP12Pzw+Ujzw2Xim68oek/d/wIOz+E+MKKbEnftjXA== X-Google-Smtp-Source: ABdhPJzUuzNf/3K19rxIA+H4yJeU72HxIaji1TTHMpDiABGGWGhdOGLMbUtX0qh/oukG/ldzaCSp4dHv6espN8e7ewI= X-Received: by 2002:a17:90b:787:: with SMTP id l7mr70312pjz.162.1626810867697; Tue, 20 Jul 2021 12:54:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erdem Aktas Date: Tue, 20 Jul 2021 12:54:16 -0700 Message-ID: Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP To: Andy Lutomirski Cc: Joerg Roedel , David Rientjes , Borislav Petkov , Sean Christopherson , Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" , Andi Kleen , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , "Peter Zijlstra (Intel)" , Paolo Bonzini , Ingo Molnar , "Kaplan, David" , Varad Gautam , Dario Faggioli , "the arch/x86 maintainers" , linux-mm@kvack.org, linux-coco@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0873EB00047C X-Stat-Signature: h478axf36pwwq1iyf7m9rgnp8nnb9de3 Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=Ycdyq1Ko; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of erdemaktas@google.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=erdemaktas@google.com X-HE-Tag: 1626810868-457479 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 Mon, Jul 19, 2021 at 8:30 PM Andy Lutomirski wrote: > What=E2=80=99s the attack you have in mind? With TDX, the guest using th= e wrong shared vs secure type should, at worst, cause > crashes. With SEV,= I can imagine it=E2=80=99s possible for a guest to read or write the ciphe= rtext of a private page, but actually > turning that into an attack seems like it would require convincing a gues= t to use the same page with both modes. There are a couple of things that can go wrong (maybe more): Imagine Guest set a page shared. It is assumed that the host should remove the SEPT entry but it does not have to, so that entry might stay there with a valid bit set. Guest should accept a page before it accesses it the first time or guest can accept a page as part of #VE handler when a PENDING page is accessed. Current guest patch series (v3) from intel does not have any #VE handler to accept pages on the fly. It seems like it has an assumption that all the pages are accepted by UEFI (I have not reviewed the code yet in detail). Now let's say the kernel wants to access a page for the first time, or after a kexec it wants to make sure all the pages are private. it needs to call tdx_hcall_gpa_intent or tdg_accept_page individually. If the page is already accepted, tdg_accept_page does not return any error in the current implementation in v3. Depending on how this page is being used, it's content is now "not zeroed" as opposed to what it is being expected. Converting this to an attack is not trivial but possible. I did not see any #VE implementation to handle SEPT violations when a page is in PENDING state. I am assuming that this needs to be supported at some point (If not then we need to discuss the use cases for such support). In such an implementation, hypervisor can inject a zeroed page anytime. This seems like a not big deal but IMO it is and it can be used as an attack vector to change conditions, masking variables etc. > >> At the risk of asking a potentially silly question, would it be > >> reasonable to treat non-validated memory as not-present for kernel > >> purposes and hot-add it in a thread as it gets validated? > > My concern with this is, it assumes that all the present memory is privat= e. UEFI might have some pages which are shared therefore also are present. > > > Why is this a problem? In TDX, I don=E2=80=99t think shared pages need a= ny sort of validation. The private memory needs acceptance, but only DoS sh= ould be possible by getting it wrong. If EFI passed in a messy map with sha= red and private transitions all over, there will be a lot of extents in the= map, but what actually goes wrong? I mean if the only attack vector is DoS (which is not part of the threat model that TDX is addressing), then why do we even need tdaccept? I thought we need tdaccept to prevent VMM to change the content of a page without guest knowing it. My comment was about if we assume all non-validated memory as not-present, how we were going to handle the shared pages transferred from UEFI to kernel. Those are not validated but the range is present. How can the guest kernel read those shared pages if it does not know that they need to be mapped as shared in the first place. Depending on how the guest kernel is handling shared to private page conversion or how it is initializing the private pages for the first time, a lot of things can go wrong but I need to look at the code to provide more concrete examples. -Erdem