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,URIBL_BLOCKED,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 736E7C6377D for ; Thu, 22 Jul 2021 17:31:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CD7F7611C1 for ; Thu, 22 Jul 2021 17:31:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CD7F7611C1 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 5F7126B0036; Thu, 22 Jul 2021 13:31:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A7E26B005D; Thu, 22 Jul 2021 13:31:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4972B6B006C; Thu, 22 Jul 2021 13:31:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) by kanga.kvack.org (Postfix) with ESMTP id 2CBE06B0036 for ; Thu, 22 Jul 2021 13:31:42 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 48E75181AEF3C for ; Thu, 22 Jul 2021 17:31:40 +0000 (UTC) X-FDA: 78390915960.25.96B63F7 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf11.hostedemail.com (Postfix) with ESMTP id EBDA4F00240D for ; Thu, 22 Jul 2021 17:31:39 +0000 (UTC) Received: by mail-qt1-f177.google.com with SMTP id d1so4757829qto.4 for ; Thu, 22 Jul 2021 10:31:39 -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; bh=lmKN41ZlX4yC+pRjkhPFTz8I4eLfisxJp0th04qeWoE=; b=Bsx0A3a2hSEfKbHrLvURxTJdWaUlcLsubMHg1rcRtr381codtyK879fqK0fYC+uj3a 51VVMesdzai2m0l5tUcwfLdkSsWJumposeoAQ1Gcjl/UgSTdsMaJK1et0ySew/FwusqJ FjwJUvwGL2Ppk6bMizOrCHzsy3hwxcXjqrT3986iqVDSL5pBJukHRTrZFZuhMIEDZ4us AUqyX+9KsTZ/zfG0VQBbYqTl9H9+dsBp3dZPe84qbEbeT6m03K8e0hWwaTVcaczIa/Za dtfhyI1gOHbOnaMGg/M1Bs4WhqIpbNCsJ/SojV10rHy7EODuVaq/fWuxjtWI3/djMJ0B ZFTg== 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; bh=lmKN41ZlX4yC+pRjkhPFTz8I4eLfisxJp0th04qeWoE=; b=Wf3cpd7d4JOQ/bKjg5V4M+KJ8zbYmDqY18Hzjk7z2sCbkOylUpJ8vwfQ3phNef7hbT NjHdAWUxmElKeWev3Dx4wE/8U27/fcJu46NQyWC92+i5iwWobVzg8QITVDwurp7jbjg9 0XYtjNXMAOJFWk3uYX6uxN+xNn4ATX4R//j8oLS4TD1okRPlNoGGrLjNseBq4wU0XJrl Tln/omi6Pm/+GUa9qsqk0VhIVnpvx631AoSvDRewbzZC4NHuzw0athI4fBk0eEjgs1A+ Qu7/xh0KC5y67qew94tO1HQEJSN7cA9v8Ithg8q4XVz6626Fwe/lrI1B5hYVDF7DkWUI qlwg== X-Gm-Message-State: AOAM530xDlaLiO7TFyWpVyUiixRC5avmzDmvJA83eopjLRS+CcD8Dcq6 IMJ8l+qDHntryNNebaUFg/JO1xk26dEGzstHNf8i9w== X-Google-Smtp-Source: ABdhPJyqSn0RXww7pFw94yXrC6xAH7Xwkqei1MhLDJEtFuqLHYRonMkFw82kbNxsonV7Y8nZfkpm0y3fTswg5Yyv4rk= X-Received: by 2002:a05:622a:1907:: with SMTP id w7mr657809qtc.251.1626975098778; Thu, 22 Jul 2021 10:31:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marc Orr Date: Thu, 22 Jul 2021 10:31:27 -0700 Message-ID: Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP To: Andi Kleen Cc: Erdem Aktas , Andy Lutomirski , Joerg Roedel , David Rientjes , Borislav Petkov , Sean Christopherson , Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , "Kaplan, David" , Varad Gautam , Dario Faggioli , x86 , linux-mm@kvack.org, linux-coco@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=Bsx0A3a2; spf=pass (imf11.hostedemail.com: domain of marcorr@google.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=marcorr@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: q4yqytxmmdec7z9is6sh8ynse9x5cffk X-Rspamd-Queue-Id: EBDA4F00240D X-Rspamd-Server: rspam01 X-HE-Tag: 1626975099-930201 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 10:17 PM Andi Kleen wrote: > > > On 7/19/2021 6:51 PM, Erdem Aktas wrote: > > > > > There's one exception to this, which is the previous memory view in > > > crash kernels. But that's an relatively obscure case and there might be > > > other solutions for this. > > > > I think this is an important angle. It might cause reliability issues. > > if kexec kernel does not know which page is shared or private, it can > > use a previously shared page as a code page which will not work. It is > > also a security concern. Hosts can always cause crashes which forces > > guests to do kexec for crash dump. If the kexec kernel does not know > > which pages are validated before, it might be compromised with page > > replay attacks. > > First I suspect for crash it's not a real security problem if a > malicious hypervisor would inject zeroed pages. That means actual strong > checks against revalidation/reaccept are not needed. That still leaves > the issue of triggering an exception when the memory is not there. TDX > has an option to trigger a #VE in this case, but we will actually force > disable it to avoid #VE in the system call gap. But the standard crash > dump tools already know how to parse mem_map to distinguish different > types of pages. So they already would be able to do that. We just need > some kind of safety mechanism to prevent any crashes, but that should be > doable. Actually I'm not sure they're really needed because that's a > root operation. I'm not as familiar with TDX as SNP. So I'm not sure that I follow the exact security threat that Erdem was alluding to. That being said, I do want to chime in with the following: I think we should not assume that the guest getting into a certain state is "probably" not a real security issue. IMHO, we need to be completely certain that guest data cannot be compromised if we're going to remove the requirement that guest memory only be validated once in a certain state (e.g., from within a crash kernel). Perhaps it is the case that we're certain that guest data cannot be compromised from within a crash kernel -- but it's not what I read in the email exchange.