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 32D6BE6F06E for ; Fri, 1 Nov 2024 16:56:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A77A36B008C; Fri, 1 Nov 2024 12:56:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A4E3E6B0093; Fri, 1 Nov 2024 12:56:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93D086B0095; Fri, 1 Nov 2024 12:56:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 772DE6B008C for ; Fri, 1 Nov 2024 12:56:26 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 355B2C0B27 for ; Fri, 1 Nov 2024 16:56:26 +0000 (UTC) X-FDA: 82738128900.15.9F75340 Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) by imf06.hostedemail.com (Postfix) with ESMTP id C26AB180022 for ; Fri, 1 Nov 2024 16:56:03 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=JhNAo0Rk; spf=pass (imf06.hostedemail.com: domain of "prvs=028377251=derekmn@amazon.com" designates 207.171.190.10 as permitted sender) smtp.mailfrom="prvs=028377251=derekmn@amazon.com"; dmarc=pass (policy=quarantine) header.from=amazon.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730480138; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KmcSGZZTBepw/haBxjfNfgGPXnl3daZOBZVZzzq5xe4=; b=xVMx2Yu2QfbfZMeHw2PR7jcpEpuHcgB1P//eNYUaxsgipO5ICg+qIFSchunE2t0fBdFMH/ K5AQ1Of1tMDVQffXeuzOCY78zzWw8+eefGLwwKyUuyzyAySSSBqIl/hHUFAx3ovsuRa1tC hDBh9ix/yEaFcJz4863WnE5SAsS1oxY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730480138; a=rsa-sha256; cv=none; b=nOO9/5E0rr86WzyvUWXAaZj23wV2kEPGNRITlFr/UrtP/Iz7jThb6DLuNn4Ja2xe8KugzY OhIx2c2ai/eOQBEUriaNcwfBwYUS5NOgy+qPG8YT75/c/l9jdzb3AtXCzrlSeN8T465evL dZ8aoz65jF8eeF2SfyycrMGwxEutvWg= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=JhNAo0Rk; spf=pass (imf06.hostedemail.com: domain of "prvs=028377251=derekmn@amazon.com" designates 207.171.190.10 as permitted sender) smtp.mailfrom="prvs=028377251=derekmn@amazon.com"; dmarc=pass (policy=quarantine) header.from=amazon.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1730480184; x=1762016184; h=message-id:date:mime-version:to:cc:references:subject: from:in-reply-to:content-transfer-encoding; bh=KmcSGZZTBepw/haBxjfNfgGPXnl3daZOBZVZzzq5xe4=; b=JhNAo0RkuYPwWT6NXXRY5Lqd72sRW+3PGX6JEpcCAc4sj2HvdujQLzMM bMckwXygDSoMCyxiKLED27RiN3ssl77ATmHMCV6h8ET9Phf9DD3IZ0N6p oe5SKdfO4S282m6+bhfEw5pw/GHynFeaRZZbAWNLNgYmn1KdyCwgRbo3f Y=; X-IronPort-AV: E=Sophos;i="6.11,250,1725321600"; d="scan'208";a="381765496" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.25.36.210]) by smtp-border-fw-33001.sea14.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2024 16:56:22 +0000 Received: from EX19MTAUWA001.ant.amazon.com [10.0.38.20:55997] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.34.72:2525] with esmtp (Farcaster) id 6a9142ea-5ddd-46d3-9d40-2688c563fdd9; Fri, 1 Nov 2024 16:56:21 +0000 (UTC) X-Farcaster-Flow-ID: 6a9142ea-5ddd-46d3-9d40-2688c563fdd9 Received: from EX19D003UWC002.ant.amazon.com (10.13.138.169) by EX19MTAUWA001.ant.amazon.com (10.250.64.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Fri, 1 Nov 2024 16:56:20 +0000 Received: from [192.168.208.156] (10.106.101.42) by EX19D003UWC002.ant.amazon.com (10.13.138.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.35; Fri, 1 Nov 2024 16:56:17 +0000 Message-ID: <7bd627df-0303-4ded-b8c8-ceb84fb20f0d@amazon.com> Date: Fri, 1 Nov 2024 09:56:12 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <784d1522-0451-4844-a334-8b7d49019437@intel.com> Subject: Re: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd Content-Language: en-US From: "Manwaring, Derek" In-Reply-To: <784d1522-0451-4844-a334-8b7d49019437@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.106.101.42] X-ClientProxiedBy: EX19D038UWB002.ant.amazon.com (10.13.139.185) To EX19D003UWC002.ant.amazon.com (10.13.138.169) X-Stat-Signature: nboysadf4pwi8fiqnikp1su1xs1yfwbb X-Rspam-User: X-Rspamd-Queue-Id: C26AB180022 X-Rspamd-Server: rspam02 X-HE-Tag: 1730480163-914906 X-HE-Meta: U2FsdGVkX1/+iZhHq0xnWmCr1S1c9x80NklxyBjJxE5cEqTEc648YtKwzjv3QPwjjzecn+YlbVp3JLOSpxhd52cVtDUQzEGbMRwzHr8iA35kT8O3j5NOkdyTew6eMKH5/X8POlODmNfIotbs/HGsao78iaN7q6vx93FYjb7O+PcIF1dZ6iJ5x6luX0GdJp1dRj0XlGdN56lQ4g6RA07u+0ACfnUBeSXa2VZ/aL+DraHPBrC8uldpLf+1poLkDEeQGZcFCzDfoymoU+L8klNxQTubI8nJTskQqKxE3vuzJHlfhwH2lt9XLdNsJa0MLZt4zx8LBwzFAKaSCPzmIzbdd4Tr3zu38qNIcHVbk0DeqBNhmcT2CN1voVVpFeF0nevP5iBrL+RbAzVZjXK4VhcDmPykhh46mU9bkwTKCi/dkheMP69aNVgL9nozbQ+oX8jzFd7oAgYJSBVRSoZ6N5Fda4w9bPDJ1KgrZwIzKutQHiL/kFxqK57OJQ9m2stBUQ9jO9i7eCN0BtfzAM3X73uY6wfJB79R8QtkDg4Sq3PlAUJsqjF56H6+2v2Qd35/hNdR45elgQz61zoIjy4TmRvYHTTsXhpzc6+6lmI6ACKd/DTe2z8vS+qPmW8YiubpgWLe9BMCeelKLXXdJCjRxw1SXes/TrzN2Xgc780OzokdOUYIJ349bsx1c/pn/ngFQiQWGdeAXQTlhDMav5/pRbB6X+xpVb3mjkHzll3CqdgGJFg4n9tGT2kI6BBCTeSqlg/MF03omxyuXXuik4//2sA8YfGtECFvzoxtCFrx16Gk6V3mRTXC3bm5Z8s90VqMzVkk2VHutARAZLiou1hbIkA1inkO6goEeo8GjWEWO3fAWkZfw1bDzRvpEBZV1XF8gCdm3jeTfDtV0z334UMcspsBWW/CGnl1zI5z9KSoReEJxPrt/83QMOg+hxt7qJgW98soh6wAZKc9ZgoI97DRwh+ jybtRcnE Pr4uZH+mXBaIq4Uvi9+ZewdB6+0T12sjRCMsObVEQHLYRvLdiEoIWrQoOWd8LHyL0+PY+BTewRXQMPiTefKM7PEJRDdHmElqPMrst13DoFdxL8UYYNzr2YpbOwDrI1139325z+I86sXj9XaqM89w7mNCkH6HXjCkma64nVhyjfY1hk1+jduF5Sf92d3ThxxU7LFa+pNF8r7fm/ocPVoSwxM6N041kgeF8L+s8n8myJ6sAPAF5WZ5QxO4HrrSOZx1hhNW57rPQtJaK81Hh0roOp41LY1rJTgTIQGRvxP6IDNZvigbT68qylZLNC36+kM0KGXSlPWatZEgKfqXFaIO3jAMxUH3f3+HIm0KmBQt7IXlogVxyjJlGJDVqLOOrCohqsoeE8dmtnOjFf3+fCvb+j3ts0unjFsTmKvGkY6+aKpi3lhDBQ9Tcs+BJDVP29mskYEXB/07hs7ciBlY7iBrESZu/9FVEe6SFwRM3gOZLUwYEvUod96pZIEjyvl26dplQzUxebPdbqBam3UDuQMMAXMebOQ7IwcM2evkVpIsbMyBKN+PLwwuZwEU5EFJzgd2I/qTC7gVkGMIjyuo9RHTONbm+Fhp7RdvU5Jjo+2WTSS8eRJeAS5BB/0N+NtNpVXLkBWdnBm7L9uwYnuGonJioPfc9HZFv4XA58SvrquU6Z5jVJmBzJuCMG/Mwz+kt7wco3/pXnRBQJnKn0CepNggz3k0mbbebRf/65j+Cpbic/fQJvm9TDGZyrcWsstvk+YhhC77jk9x91jICNh1ACcbKflTTOg== 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: List-Subscribe: List-Unsubscribe: +Elena On 2024-11-01 at 16:06+0000, Dave Hansen wrote: > On 10/31/24 17:10, Manwaring, Derek wrote: > > TDX and SEV encryption happens between the core and main memory, so > > cached guest data we're most concerned about for transient execution > > attacks isn't necessarily inaccessible. > > > > I'd be interested what Intel, AMD, and other folks think on this, but I > > think direct map removal is worthwhile for CoCo cases as well. > > I'm not sure specifically which attacks you have in mind.  [...] > > I _think_ you might be thinking of attacks like MDS where some random > microarchitectural buffer contains guest data after a VM exit and then > an attacker extracts it.  Direct map removal doesn't affect these > buffers and doesn't mitigate an attacker getting the data out. Right, the only attacks we can thwart with direct map removal are transient execution attacks on the host kernel whose leak origin is "Mapped memory" in Table 1 of the Quarantine paper [2]. Maybe the simplest hypothetical to consider here is a new spectre v1 gadget in the host kernel. > The main thing I think you want to keep in mind is mentioned in the "TDX > Module v1.5 Base Architecture Specification"[1]: > > > Any software except guest TD or TDX module must not be able to > > speculatively or non-speculatively access TD private memory, > > That's a pretty broad claim and it involves mitigations in hardware and > the TDX module. > > 1. https://cdrdv2.intel.com/v1/dl/getContent/733575 Thank you, I hadn't seen that. That is a very strong claim as far as preventing speculative access; I didn't realize Intel claimed that about TDX. The comma followed by "to detect if a prior corruption attempt was successful" makes me wonder a bit if the statement is not quite as broad as it sounds, but maybe that's just meant to relate it to the integrity section? > If the attack is mitigated when the > data is _mapped_, then it's > certainly not possible _unmapped_. > > So why bother with direct map removal for TDX?  A VMM write to TD > private data causes machine checks.  So any kernel bug that even > accidentally writes to kernel memory can bring the whole system down. > Not nice. Fair enough. It hasn't been clear to me if there is a machine check when the host kernel accesses guest memory only transiently. I was assuming there is not. But if other mitigations completely prevent even speculative access of TD private memory like you're saying, then agree nothing to gain from direct map removal in the TDX case. Derek [2] https://download.vusec.net/papers/quarantine_raid23.pdf