linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Manwaring, Derek" <derekmn@amazon.com>
To: <elena.reshetova@intel.com>
Cc: <ackerleytng@google.com>, <agordeev@linux.ibm.com>,
	<aou@eecs.berkeley.edu>, <borntraeger@linux.ibm.com>,
	<bp@alien8.de>, <canellac@amazon.at>, <catalin.marinas@arm.com>,
	<chenhuacai@kernel.org>, <corbet@lwn.net>,
	<dave.hansen@intel.com>, <dave.hansen@linux.intel.com>,
	<david@redhat.com>, <derekmn@amazon.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>, <mlipp@amazon.at>,
	<palmer@dabbelt.com>, <paul.walmsley@sifive.com>,
	<pbonzini@redhat.com>, <peterz@infradead.org>,
	<quic_eberman@quicinc.com>, <rostedt@goodmis.org>,
	<roypat@amazon.co.uk>, <rppt@kernel.org>, <seanjc@google.com>,
	<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>
Subject: RE: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd
Date: Tue, 12 Nov 2024 20:31:29 -0700	[thread overview]
Message-ID: <96c24397-b081-4570-adb2-8d4443f3359c@amazon.com> (raw)
In-Reply-To: <DM8PR11MB57505F62D149EF153F89B8BAE75D2@DM8PR11MB5750.namprd11.prod.outlook.com>

On 2024-11-08 at 10:36, Elena Reshetova wrote:
> On 2024-11-06 at 17:04, Derek Manwaring wrote:
> > On 2024-11-04 at 08:33+0000, Elena Reshetova wrote:
> > > This statement *is* for integrity section. We have a separate TDX guidance
> > > on side-channels (including speculative) [3] and some speculative attacks
> > > that affect confidentiality (for example spectre v1) are listed as not covered
> > > by TDX but remaining SW responsibility (as they are now).
> >
> > Thanks for the additional info, Elena. Given that clarification, I
> > definitely see direct map removal and TDX as complementary.
>
> Jus to clarify to make sure my comment is not misunderstood.
> What I meant is that we cannot generally assume that confidentiality
> leaks from CoCo guests to host/VMM via speculative channels
> are completely impossible. Spectre V1 is a prime example of such a
> possible leak. Dave also elaborated on other potential vectors earlier.
>
> The usefulness of direct map removal for CoCo guests as a concrete
> mitigation for certain types of memory attacks must be precisely
> evaluated per each attack vector, attack vector direction (host -> guest,
> guest ->host, etc) and per each countermeasure that CoCo vendors
> provide for each such case. I don't know if there is any existing study
> that examines this for major CoCo vendors. I think this is what must
> be done for this work in order to have a strong reasoning for its usefulness.

Thanks, that makes sense. I'm a little hyperfocused on guest->host which
is the opposite direction of what is generally used for the CoCo threat
model. I think what both cases care about though is guest->guest. For
me, guest->host matters because it's a route for guest->guest (at least
in the non-CoCo world). There's some good discussion on this in David's
series on attack vector controls [1].

Like you mention, beyond direction it matters which CoCo countermeasures
are at play and how far they go during transient execution. That part is
not clear to me for the host->guest direction involving the direct map,
but agree any countermeasures like direct map removal should be
evaluated based on a better understanding of what those existing
countermeasures already cover and what attack is intended to be
mitigated.

Derek


[1] https://lore.kernel.org/lkml/LV3PR12MB92658EA6CCF18F90DAAA168394532@LV3PR12MB9265.namprd12.prod.outlook.com/


  reply	other threads:[~2024-11-13  3:31 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-30 13:49 Patrick Roy
2024-10-30 13:49 ` [RFC PATCH v3 1/6] arch: introduce set_direct_map_valid_noflush() Patrick Roy
2024-10-31  9:57   ` David Hildenbrand
2024-11-11 12:12     ` Vlastimil Babka
2024-11-12 14:48       ` Patrick Roy
2024-10-30 13:49 ` [RFC PATCH v3 2/6] kvm: gmem: add flag to remove memory from kernel direct map Patrick Roy
2024-10-31 13:56   ` Mike Day
2024-10-30 13:49 ` [RFC PATCH v3 3/6] kvm: gmem: implement direct map manipulation routines Patrick Roy
2024-10-31 14:19   ` Mike Day
2024-10-30 13:49 ` [RFC PATCH v3 4/6] kvm: gmem: add trace point for direct map state changes Patrick Roy
2024-10-30 13:49 ` [RFC PATCH v3 5/6] kvm: document KVM_GMEM_NO_DIRECT_MAP flag Patrick Roy
2024-10-30 13:49 ` [RFC PATCH v3 6/6] kvm: selftests: run gmem tests with KVM_GMEM_NO_DIRECT_MAP set Patrick Roy
2024-10-31  9:50 ` [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd David Hildenbrand
2024-10-31 10:42   ` Patrick Roy
2024-11-01  0:10     ` Manwaring, Derek
2024-11-01 15:18       ` Sean Christopherson
2024-11-01 18:32         ` Kaplan, David
2024-11-01 16:06       ` Dave Hansen
2024-11-01 16:56         ` Manwaring, Derek
2024-11-01 17:20           ` Dave Hansen
2024-11-01 18:31             ` Manwaring, Derek
2024-11-01 18:43               ` Dave Hansen
2024-11-01 19:29                 ` Manwaring, Derek
2024-11-01 19:39                   ` Dave Hansen
2024-11-04  8:33           ` Reshetova, Elena
2024-11-06 17:04             ` Manwaring, Derek
2024-11-08 10:36               ` Reshetova, Elena
2024-11-13  3:31                 ` Manwaring, Derek [this message]
2024-11-04 12:18     ` David Hildenbrand
2024-11-04 13:09       ` Patrick Roy
2024-11-04 21:30         ` David Hildenbrand
2024-11-12 14:40           ` Patrick Roy
2024-11-12 14:52             ` David Hildenbrand
2024-11-15 16:59               ` Patrick Roy
2024-11-15 17:10                 ` David Hildenbrand
2024-11-15 17:23                   ` Patrick Roy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=96c24397-b081-4570-adb2-8d4443f3359c@amazon.com \
    --to=derekmn@amazon.com \
    --cc=ackerleytng@google.com \
    --cc=agordeev@linux.ibm.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=canellac@amazon.at \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=elena.reshetova@intel.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=graf@amazon.com \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=jgowans@amazon.com \
    --cc=jthoughton@google.com \
    --cc=kalyazin@amazon.com \
    --cc=kernel@xen0n.name \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=luto@kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mlipp@amazon.at \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=quic_eberman@quicinc.com \
    --cc=rostedt@goodmis.org \
    --cc=roypat@amazon.co.uk \
    --cc=rppt@kernel.org \
    --cc=seanjc@google.com \
    --cc=shuah@kernel.org \
    --cc=svens@linux.ibm.com \
    --cc=tabba@google.com \
    --cc=tglx@linutronix.de \
    --cc=vannapurve@google.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xmarcalx@amazon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox