From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33F791C0DD6 for ; Fri, 1 Nov 2024 15:18:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730474296; cv=none; b=YVdl7z2LW+HnUrb1ypCaccFmZcnwSC719Y/nDn62GjvGJ4XT5dKxqI8nZbnstOdby163Ej//tWsPTohN8E8X05DG33nAPRhIuyw6HAC0marxCg940Qxwlfcwv8+F7T8APjxUySXp57cNXjyIu1pOGGSy678+glFPuGQqGb0WS04= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730474296; c=relaxed/simple; bh=xGkv3LzrhtoCbCqtDpE3y3Q0GFXGAU72Ny2WiKf/Iuk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=b3jM06v8P/gC3/GSGTgvAsyj82pc2dNqEJwGxzTyI8BG+/l35lMHyyb34krj95mIKhRbAZba/7tg6ncylgJAr9pFQBr3bCvIgpB79EX9590DamMqz1hb5VTkQSVt2GY3gZh0TiNg52911EI9mnPu31yQLT8wZSP27rEA6SuxpUU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=bYuZc2if; arc=none smtp.client-ip=209.85.128.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="bYuZc2if" Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-6e3705b2883so45538677b3.3 for ; Fri, 01 Nov 2024 08:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1730474293; x=1731079093; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=By0MMba+WbzG2cXuHlWeMQpST2oOpWmZSXA68XVHYo0=; b=bYuZc2ifWnC89m8jPwJZ+9o1aVJVUPtGrn+a2Tq6I7DPyGcA7YqMirJwCywfY7dDdV LulpNzMnigxZTsvXIDZqVd0UG19ynWGvrjwz5SRW/g2Y3nbuR/kASz3mqdwBJyyZSdij jLg+cW5GwRjt6NxPFfAOW9D/BPgCK2aHrRLlZQ2ogRpr/BBTq3vgBDnbUVkErVrPmxGF bdEiXB6uJMIDzWdMp3GEumYry8fh8R4gTLUOn89JMNi8cyiQ7KAcdZXj52mMsvzifjMd PimfOS64nkjk4Ng7RqN2hT6f6KWwDVzZO89CKJYuXA7RXYpYUiIs1IDUD6eg4ir1Wkv9 kAtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730474293; x=1731079093; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=By0MMba+WbzG2cXuHlWeMQpST2oOpWmZSXA68XVHYo0=; b=BZMAtdcBYktNXVwM4rT/1dthwcskIBqsyGs1q5Sh1nDEAPu3PYxfHu0+jWaZ4LWd4a V2CENr/8ZV2wb3MprtXRFPCU2CziyK7TtYM9wYn+HDVc6OqqICYgiKpebcLjHgNlI19E R4KZkOPdi36yVmmEj4KXwsj/t90cu/2DO+BIbYASmTADLJf3LGIv6CE+e48EUPPkbwDW kWbU6WvLA1RQJ3erpoX4PiSXytBfFF0YhyWSKN8iIM2JwJLFhaU6H5BKlSX0LXpiUN0v fldVE/kEZErv8K+OEACwHuO3RI0jAg2PgyYQXd/Kn7Mkl5MT+4RMAHZ/UaByw6RSEFiG kWfw== X-Forwarded-Encrypted: i=1; AJvYcCXcbIW3fRHmGrQgNP6DLw0o/74Z0+lrserQI1bXA7r4HD31Slxw5VIsdp9hc/JQySTLldA=@vger.kernel.org X-Gm-Message-State: AOJu0YwguhRyvOt7mABpxcbx2xQiIsD2Tb0BkFTijxATzRK0Ns+mqILt HtxmpEPLNEbIYxF2isKgRGzA8AoXqh1DFdhFZBnqs7lpOhVfYk1jp+3om1lygZ0hRm9OMl+M/U+ jwQ== X-Google-Smtp-Source: AGHT+IFdnwVveoc9N/MGUlZwVqfEB7IUicwB9rrAOOy2FhtDeXiq05HGyssNX0DfJOP/ZgHAaQZXrEGcvIk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a05:690c:6c8c:b0:6e3:1702:b3e6 with SMTP id 00721157ae682-6ea64b8c450mr251257b3.4.1730474293279; Fri, 01 Nov 2024 08:18:13 -0700 (PDT) Date: Fri, 1 Nov 2024 08:18:11 -0700 In-Reply-To: <2233397c-f423-40e3-8546-728b50ce0489@amazon.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <27646c08-f724-49f7-9f45-d03bad500219@amazon.co.uk> <2233397c-f423-40e3-8546-728b50ce0489@amazon.com> Message-ID: Subject: Re: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd From: Sean Christopherson To: Derek Manwaring Cc: roypat@amazon.co.uk, ackerleytng@google.com, agordeev@linux.ibm.com, aou@eecs.berkeley.edu, borntraeger@linux.ibm.com, bp@alien8.de, catalin.marinas@arm.com, chenhuacai@kernel.org, corbet@lwn.net, dave.hansen@linux.intel.com, david@redhat.com, gerald.schaefer@linux.ibm.com, gor@linux.ibm.com, graf@amazon.com, hca@linux.ibm.com, hpa@zytor.com, jgowans@amazon.com, jthoughton@google.com, kalyazin@amazon.com, kernel@xen0n.name, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, loongarch@lists.linux.dev, luto@kernel.org, mathieu.desnoyers@efficios.com, mhiramat@kernel.org, mingo@redhat.com, palmer@dabbelt.com, paul.walmsley@sifive.com, pbonzini@redhat.com, peterz@infradead.org, quic_eberman@quicinc.com, rostedt@goodmis.org, rppt@kernel.org, shuah@kernel.org, svens@linux.ibm.com, tabba@google.com, tglx@linutronix.de, vannapurve@google.com, will@kernel.org, x86@kernel.org, xmarcalx@amazon.com, David Kaplan Content-Type: text/plain; charset="us-ascii" +David Kaplan On Thu, Oct 31, 2024, Derek Manwaring wrote: > On 2024-10-31 at 10:42+0000 Patrick Roy wrote: > > On Thu, 2024-10-31 at 09:50 +0000, David Hildenbrand wrote: > > > On 30.10.24 14:49, Patrick Roy wrote: > > >> Most significantly, I've reduced the patch series to focus only on > > >> direct map removal for guest_memfd for now, leaving the whole "how to do > > >> non-CoCo VMs in guest_memfd" for later. If this separation is > > >> acceptable, then I think I can drop the RFC tag in the next revision > > >> (I've mainly kept it here because I'm not entirely sure what to do with > > >> patches 3 and 4). > > > > > > Hi, > > > > > > keeping upcoming "shared and private memory in guest_memfd" in mind, I > > > assume the focus would be to only remove the direct map for private memory? > > > > > > So in the current upstream state, you would only be removing the direct > > > map for private memory, currently translating to "encrypted"/"protected" > > > memory that is inaccessible either way already. > > > > > > Correct? > > > > Yea, with the upcomming "shared and private" stuff, I would expect the > > the shared<->private conversions would call the routines from patch 3 to > > restore direct map entries on private->shared, and zap them on > > shared->private. > > > > But as you said, the current upstream state has no notion of "shared" > > memory in guest_memfd, so everything is private and thus everything is > > direct map removed (although it is indeed already inaccessible anyway > > for TDX and friends. That's what makes this patch series a bit awkward > > :( ) > > 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. Removal of the direct map entries for guest private PFNs likely won't affect the ability of an attacker to glean information from the unencrypted data that's in the CPU caches, at least not on x86. Both TDX and SEV steal physical address bit(s) for tagging encrypted memory, and unless things have changed on recent AMD microarchitectures (I'm 99.9% certain Intel CPUs haven't changed), those stolen address bits are propagated into the caches. I.e. the encrypted and unencrypted forms of a given PFN are actually two different physical addresses under the hood. I don't actually know how SEV uses the stolen PA bits though. I don't see how it simply be the ASID, because IIUC, AMD CPUs allow for more unique SEV-capable ASIDs than uniquely addressable PAs by the number of stolen bits. But I would be very surprised if the tag for the cache isn't guaranteed to be unique per encryption key. David? 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3C2EFE6F06A for ; Fri, 1 Nov 2024 15:18:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:From:Subject:Message-ID:References: Mime-Version:In-Reply-To:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=N1eXnkYt1MgVbjBEwIMSlAhm4FwlwW+jRMNbUb+PS5Q=; b=4Zu4ClMsYhF9yn A25h7Y+1y/VIBZUsRhYmBR2MhDT7PG8gzalr5M9vrYs+hChsCuLSYq3PGbrJaJ0PqEnvSmlB97/ro 8ZNmEQJGTM3b65t5E9470o08quVFt5Mqh88ostiZgVsnjOUOJGgWauEn1k4LeJoLWInwYLYP8E5CE Ezc/DjQfqDN/jf6Q2Eb2cMzP29GPfNlQEZrYUvQ9F0qzv1WLYK49NX4I+1NGlW131ntTy6PoZIcun 21vZp9Svj006RRFn/FM/xkuwxqa7AOY8NL7niUaKYJ7Cd/S97fhSyOpPLzB48LfPm1rdAwIMCQrUS HlZoV3S8w6mxV2gYBjxg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t6tPl-00000007TtB-2IQh; Fri, 01 Nov 2024 15:18:18 +0000 Received: from mail-yw1-x114a.google.com ([2607:f8b0:4864:20::114a]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t6tPj-00000007TrU-18ng for linux-riscv@lists.infradead.org; Fri, 01 Nov 2024 15:18:16 +0000 Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-6e7fb84f999so34749577b3.2 for ; Fri, 01 Nov 2024 08:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1730474293; x=1731079093; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=By0MMba+WbzG2cXuHlWeMQpST2oOpWmZSXA68XVHYo0=; b=Dw8c23o9cZAv+JoUjw+QPEQmxnFFIuHIohH1FtGIujhr/p5d4i+Fq7jAHNFcdG2ODv NtcgShOGDj5MNzb6EiiNMfJrW1VfA4V7YEQZLKjEGsypsbj4vijCxXkdNC9YsgstAC18 gdEA8wE8Pt28Y2E+fMKHWPtkYYWQu8kzLO6Kq9FZPNjU4d5VJJsIkh4Ggy7tdwxLBuzy z4JUaDTQlabgoqH+r8Qq/7YtSmR/hC8POiIEt0b3oRPkBqTT6/SEjRTNQ8jlrL0evGQX Al/Oi/xywFK3Lg0MkgyCPWK2LuStdT+NZN6NUQVvd/dMF+B5o8Hc+HrMGE79q4reltWu P4fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730474293; x=1731079093; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=By0MMba+WbzG2cXuHlWeMQpST2oOpWmZSXA68XVHYo0=; b=fkNUAfPmPLJcTTzpgMebkX9wF6xYg/lsnUEE08F4syFcAzk5LcrJaMrLAeQ1BWYA+g FF8SdTZxu837zA3hauFhWqPpf87Y0tx9PBH6v4L3mFnrCoIlf7zoAoBSIwtVNsha82NR wWRIqaAFP5xPwF3jK6FwyAB40Oh5XvpM7jtPNhYM11dIAQlUsjC57F15Ey307z0WJaRw vCTZ1x863w4Wepm7MyAeBB9DceMrfkX3MGAjqdPs8eADRt9PjLCOpEL9wUeTGVMPCza7 FMUzqZ2qrD4pvA8xWvI2u1uRjV/SIf61ZCvsVx8OXv+QnOwkophmacAiQ7bhgIhQUn2S kvzQ== X-Forwarded-Encrypted: i=1; AJvYcCUQx0dGa4cqiRZq7C1pb6cuulSm9ZE7+fSVuLnGppL6611J7L6v8B0BY0vLpabQNvIPQCD9aLm3Q/oEIA==@lists.infradead.org X-Gm-Message-State: AOJu0YxVyJKzaU4ZhlZFs1wqxtfVTODFaxIm0Zp3c30HbjSOiIUc0l0h SdIn+kBLvPiGGi9W0tCjSBh+1sISXk00moIilJLbiBsaW5+Z3hoVp5++HYGtYir337bSiFeXQp7 BXw== X-Google-Smtp-Source: AGHT+IFdnwVveoc9N/MGUlZwVqfEB7IUicwB9rrAOOy2FhtDeXiq05HGyssNX0DfJOP/ZgHAaQZXrEGcvIk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a05:690c:6c8c:b0:6e3:1702:b3e6 with SMTP id 00721157ae682-6ea64b8c450mr251257b3.4.1730474293279; Fri, 01 Nov 2024 08:18:13 -0700 (PDT) Date: Fri, 1 Nov 2024 08:18:11 -0700 In-Reply-To: <2233397c-f423-40e3-8546-728b50ce0489@amazon.com> Mime-Version: 1.0 References: <27646c08-f724-49f7-9f45-d03bad500219@amazon.co.uk> <2233397c-f423-40e3-8546-728b50ce0489@amazon.com> Message-ID: Subject: Re: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd From: Sean Christopherson To: Derek Manwaring X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241101_081815_334338_3B87C731 X-CRM114-Status: GOOD ( 26.15 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jthoughton@google.com, luto@kernel.org, kvm@vger.kernel.org, david@redhat.com, peterz@infradead.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, kalyazin@amazon.com, svens@linux.ibm.com, linux-mm@kvack.org, pbonzini@redhat.com, linux-kselftest@vger.kernel.org, hpa@zytor.com, kernel@xen0n.name, shuah@kernel.org, agordeev@linux.ibm.com, linux-s390@vger.kernel.org, David Kaplan , corbet@lwn.net, will@kernel.org, chenhuacai@kernel.org, linux-riscv@lists.infradead.org, mingo@redhat.com, tabba@google.com, mathieu.desnoyers@efficios.com, gerald.schaefer@linux.ibm.com, borntraeger@linux.ibm.com, roypat@amazon.co.uk, linux-trace-kernel@vger.kernel.org, jgowans@amazon.com, aou@eecs.berkeley.edu, gor@linux.ibm.com, hca@linux.ibm.com, rostedt@goodmis.org, ackerleytng@google.com, xmarcalx@amazon.com, bp@alien8.de, loongarch@lists.linux.dev, paul.walmsley@sifive.com, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, palmer@dabbelt.com, mhiramat@kernel.org, graf@amazon.com, vannapurve@google.com, rppt@kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org +David Kaplan On Thu, Oct 31, 2024, Derek Manwaring wrote: > On 2024-10-31 at 10:42+0000 Patrick Roy wrote: > > On Thu, 2024-10-31 at 09:50 +0000, David Hildenbrand wrote: > > > On 30.10.24 14:49, Patrick Roy wrote: > > >> Most significantly, I've reduced the patch series to focus only on > > >> direct map removal for guest_memfd for now, leaving the whole "how to do > > >> non-CoCo VMs in guest_memfd" for later. If this separation is > > >> acceptable, then I think I can drop the RFC tag in the next revision > > >> (I've mainly kept it here because I'm not entirely sure what to do with > > >> patches 3 and 4). > > > > > > Hi, > > > > > > keeping upcoming "shared and private memory in guest_memfd" in mind, I > > > assume the focus would be to only remove the direct map for private memory? > > > > > > So in the current upstream state, you would only be removing the direct > > > map for private memory, currently translating to "encrypted"/"protected" > > > memory that is inaccessible either way already. > > > > > > Correct? > > > > Yea, with the upcomming "shared and private" stuff, I would expect the > > the shared<->private conversions would call the routines from patch 3 to > > restore direct map entries on private->shared, and zap them on > > shared->private. > > > > But as you said, the current upstream state has no notion of "shared" > > memory in guest_memfd, so everything is private and thus everything is > > direct map removed (although it is indeed already inaccessible anyway > > for TDX and friends. That's what makes this patch series a bit awkward > > :( ) > > 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. Removal of the direct map entries for guest private PFNs likely won't affect the ability of an attacker to glean information from the unencrypted data that's in the CPU caches, at least not on x86. Both TDX and SEV steal physical address bit(s) for tagging encrypted memory, and unless things have changed on recent AMD microarchitectures (I'm 99.9% certain Intel CPUs haven't changed), those stolen address bits are propagated into the caches. I.e. the encrypted and unencrypted forms of a given PFN are actually two different physical addresses under the hood. I don't actually know how SEV uses the stolen PA bits though. I don't see how it simply be the ASID, because IIUC, AMD CPUs allow for more unique SEV-capable ASIDs than uniquely addressable PAs by the number of stolen bits. But I would be very surprised if the tag for the cache isn't guaranteed to be unique per encryption key. David? _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv