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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 AC3D1C07E95 for ; Tue, 20 Jul 2021 17:39:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4A23360FE9 for ; Tue, 20 Jul 2021 17:39:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A23360FE9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 95F1B6B005D; Tue, 20 Jul 2021 13:39:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E7D76B006C; Tue, 20 Jul 2021 13:39:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 762366B0070; Tue, 20 Jul 2021 13:39:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0111.hostedemail.com [216.40.44.111]) by kanga.kvack.org (Postfix) with ESMTP id 404F86B005D for ; Tue, 20 Jul 2021 13:39:09 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id AEE5D231BB for ; Tue, 20 Jul 2021 17:39:07 +0000 (UTC) X-FDA: 78383677134.30.F86E04E Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by imf24.hostedemail.com (Postfix) with ESMTP id 800C3B0000B3 for ; Tue, 20 Jul 2021 17:39:06 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10051"; a="272409680" X-IronPort-AV: E=Sophos;i="5.84,255,1620716400"; d="scan'208";a="272409680" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 10:32:59 -0700 X-IronPort-AV: E=Sophos;i="5.84,255,1620716400"; d="scan'208";a="632388638" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.212.245.156]) ([10.212.245.156]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 10:32:57 -0700 Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP To: Joerg Roedel Cc: Erdem Aktas , Andy Lutomirski , 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 References: From: Andi Kleen Message-ID: Date: Tue, 20 Jul 2021 10:32:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Authentication-Results: imf24.hostedemail.com; dkim=none; spf=none (imf24.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=ak@linux.intel.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none) X-Rspamd-Server: rspam05 X-Stat-Signature: wqraedh3tzpzocc45jua76gcg8edgzb7 X-Rspamd-Queue-Id: 800C3B0000B3 X-HE-Tag: 1626802746-2747 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 7/20/2021 2:11 AM, Joerg Roedel wrote: > > I am not sure how it is implemented in TDX hardware, but for SNP the > guest _must_ _not_ double-validate or even double-invalidate memory. In TDX it just zeroes the data. If you can tolerate zeroing it's fine. Of course for most data that's not tolerable, but for kexec (minus kernel itself) it is. > > What I sent here is actually v2 of my proposal, v1 had a much more lazy > approach like you are proposing here. But as I learned what can happen > is this: > > * Hypervisor maps GPA X to HPA A > * Guest validates GPA X > Hardware enforces that HPA A always maps to GPA X > * Hypervisor remaps GPA X to HPA B > * Guest lazily re-validates GPA X > Hardware enforces that HPA B always maps to GPA X > > The situation we have now is that host pages A and B are validated for > the same guest page, and the hypervisor can switch between them at will, > without the guest being able to notice it. I don't believe that's possible on TDX > > This can open various attack vectors from the hypervisor towards the > guest, like tricking the guest into a code-path where it accidentially > reveals its secrets. Well things would certainly easier if you had a purge interface then. But for the kexec crash case it would be just attacks against the crash dump, which I assume are not a real security concern. The crash kexec mostly runs in its own memory, which doesn't need this, or is small enough that it can be fully pre-accepted. And for the previous memory view probably these issues are acceptable. That leaves the non crash kexec case, but perhaps it is acceptable to just restart the guest in such a case instead of creating complicated and fragile new interfaces. >> If the device filter is active it won't. > We are not going to pohibit dma_alloc_coherent() in SNP guests just > because we are too lazy to implement memory re-validation. dma_alloc_coherent is of course allowed, just not freeing. Or rather if you free you would need a pool to recycle there. If you have anything that free coherent dma frequently the performance would be terrible so you should probably avoid that at all costs anyways. But since pretty much all the current IO models rely on a small number of static bounce buffers that's not a problem. -Andi