Received-SPF: pass (google.com: domain of linux-kernel+bounces-102681-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Thu, 14 Mar 2024 08:12:12 +0800
From: Yan Zhao <yan.y.zhao@intel.com>
To: Sean Christopherson <seanjc@google.com>
CC: Kevin Tian <kevin.tian@intel.com>, "jgg@nvidia.com" <jgg@nvidia.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Lai Jiangshan <jiangshanlai@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>, Josh Triplett
	<josh@joshtriplett.org>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"rcu@vger.kernel.org" <rcu@vger.kernel.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, Yiwei Zhang <zzyiwei@google.com>
Subject: Re: [PATCH 5/5] KVM: VMX: Always honor guest PAT on CPUs that
 support self-snoop
Message-ID: <ZfJA3AaLga5OXoL1@yzhao56-desk.sh.intel.com>
Reply-To: Yan Zhao <yan.y.zhao@intel.com>
References: <20240309010929.1403984-1-seanjc@google.com>
 <20240309010929.1403984-6-seanjc@google.com>
 <Ze5bee/qJ41IESdk@yzhao56-desk.sh.intel.com>
 <Ze-hC8NozVbOQQIT@google.com>
 <BN9PR11MB527600EC915D668127B97E3C8C2B2@BN9PR11MB5276.namprd11.prod.outlook.com>
 <ZfB9rzqOWmbaOeHd@google.com>
 <ZfD++pl/3pvyi0xD@yzhao56-desk.sh.intel.com>
 <BN9PR11MB527688657D92896F1B19C2F98C2A2@BN9PR11MB5276.namprd11.prod.outlook.com>
 <ZfFp6HtYSmO4Q6sW@yzhao56-desk.sh.intel.com>
 <ZfHBqNzaoh36PXDn@google.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZfHBqNzaoh36PXDn@google.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?v8mrDjiDAD+ST57HaSZz/gYvpr8ZrlYPkejqir7rHSrcyqGK5G2koc50OFBI?=
 =?us-ascii?Q?TgsUQGKzojWHycgV4Cm0dpHxBneYMqFypShVOyx9vPsVslIUnDazfid3BB2A?=
 =?us-ascii?Q?FQkYYV/7v2xM/+WiAwRWXrbHjghpInhUNwY8YfbVN0dwgjDR5sS9GbvRTq2E?=
 =?us-ascii?Q?fITuc8US01sKfkPG/NLRu315QzcuKQiKSJCSzED2c8nv3TcnD+dQVE8T/rFq?=
 =?us-ascii?Q?iH2XLJ4DDycbiLIyHlTwGS2YzFQ0QaR/LnoPOeIGsXO10EbxkoAVXyRiyhOq?=
 =?us-ascii?Q?jWOKavpzse26roJuWj84kAJSdp7hfBa21Sby97IqB77F0VMcnX0i8zrQYvwC?=
 =?us-ascii?Q?qQRprIkfntp3jvpGGTH8mpl47dlQNJFSGbB2sSp5PW2UdgDEypKiQRpsA5G8?=
 =?us-ascii?Q?Z94Y9yHpWwgyF2dMWf3QhnqWl5WtlQ1e3W5YwLukYWOg9eqlGE5kGsll6TyG?=
 =?us-ascii?Q?eLnBv5vWFBPAHXC1o/cVpeUujCdleLn85vbEKz55J26QA1DemW+NNG3CL0wi?=
 =?us-ascii?Q?R0DxxBisLASSxk3rB0bZb3/XINaRQk/xLHopePLJhQVi/a7hEIfuPjyy4BUR?=
 =?us-ascii?Q?tQnQijoGsljdA0Z4ZnjdsGj6F/cCYg8x4sEARZ+XjTvRtPXgAyc//yldnfS4?=
 =?us-ascii?Q?meIOyp5mAM6wkO4IdmdIXVWoZh2Hs4nUSY7DYOCtdad+tGtXGmlc6AKTpMh6?=
 =?us-ascii?Q?zLAXAgVCM3VKHiBTDmpHHuz/QX+4VwaAaMRcFjQHtqYsemB+Y5OfazhGlRUT?=
 =?us-ascii?Q?WwLgrPrYne/7b37aZC+KWgDIZoxWA9fSSCvV6VeS1bGZhS0hI2GnCTe4M1mM?=
 =?us-ascii?Q?i60aBmhSx9BoxB7ZDqH2XZ9o3UK8PKGSDKeW70LEIYNJ/u28cV16pfWFrR0p?=
 =?us-ascii?Q?Zs9VlCRTPWraart35hOYRK76gTXwoB9igHCfNlafyipzk0xI0t36P+tzhzts?=
 =?us-ascii?Q?KRwnmenbF/C+/ikZpz9BkpeBPVBwiGsMtGKsWk/E1USlDxJY9EcmHJw4CWPs?=
 =?us-ascii?Q?YgLRvQI+OQoj1y8KXY8/UW+sfIL8DmyLbu2+u7lhjsEd2zS0xrI7KeNYB8sx?=
 =?us-ascii?Q?+FqYMEmEsIgZD11iu45dw/HCImmlSpb0alkdG7FOqdFhq/hwsGTZK2mcR06q?=
 =?us-ascii?Q?8c3INFCVdfU9FfXAY87kfcVDKCUQkgA9+mQ2TmSTm0YQPMuoSnyUmZ80J4hp?=
 =?us-ascii?Q?6xS9WNfI47i0dM4YMMyJRbPVznVlhYhxenace0q7ZvN+bIKP9SCOG+/k3Oqc?=
 =?us-ascii?Q?5voKsDAk2g8fF5YH+59PVQ9N8/GmGRvuidp+m1isQTCX11qtR4vPuVAy+uUd?=
 =?us-ascii?Q?bjzjnbJ/f8u9nctFA+foy7K2OA3Ou6c3ng9lnDYHDQJMor1HS6ffaMWA3rsO?=
 =?us-ascii?Q?HJEnp5+hukhEHxrvTbqe2+7kUrh4pNu3oAeFbP6fHjxt9Nmjn4HlBkuaIzR5?=
 =?us-ascii?Q?1JltIUfeXulqH/HYxBV7NTjlpaflqXouKI3i0RkA4jr2edkJ3BMxnN7di13+?=
 =?us-ascii?Q?8+q1LVm0bGIc8veeR99IHpAv4fp6jD9S1952+Icw/1TSwyvkUHjnVzqWEK3m?=
 =?us-ascii?Q?NT2FYu0o8CBb7hadc8SdcbTGdYV7u15sSigHrxmD?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 2344c3bb-cbcc-4c35-ef3c-08dc43bf9418
X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB5966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 00:42:08.3808
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: VhcWwZlhh9CmvZfmayOctydH5F4rUEUDvJepOUHDQayYsJKcyeOuncgdb7LLHKtc5xWHhz6wWUi9qMdMKqXasA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB6099
X-OriginatorOrg: intel.com

On Wed, Mar 13, 2024 at 08:09:28AM -0700, Sean Christopherson wrote:
> On Wed, Mar 13, 2024, Yan Zhao wrote:
> > > We'll certain fix the security hole on CPUs w/ self-snoop. In this case
> > > CPU accesses are guaranteed to be coherent and the vulnerability can
> > > only be exposed via non-coherent DMA which is supposed to be fixed
> > > by your coming series. 
> > > 
> > > But for old CPUs w/o self-snoop the hole can be exploited using either CPU
> > > or non-coherent DMA once the guest PAT is honored. As long as nobody
> > > is willing to actually fix the CPU path (is it possible?) I'm kind of convinced
> > We can cook a patch to check CPU self-snoop and force WB in EPT even for
> > non-coherent DMA if no self-snoop. Then back porting such a patch together
> > with the IOMMU side mitigation for non-coherent DMA.
> 
> Please don't.  This is a "let sleeping dogs lie" situation.
> 
>   let sleeping dogs lie - avoid interfering in a situation that is currently
>   causing no problems but might do so as a result of such interference.
> 
> Yes, there is technically a flaw, but we have zero evidence that anyone cares or
> that it is actually problematic in practice.  On the other hand, any functional
> change we make has a non-zero changes of breaking existing setups that have worked
> for many years. 
> 
> > Otherwise, IOMMU side mitigation alone is meaningless for platforms of CPU of
> > no self-snoop.
> > 
> > > by Sean that sustaining the old behavior is probably the best option...
> > Yes, as long as we think exposing secuirty hole on those platforms is acceptable. 
> 
> Yes, I think it's acceptable.  Obviously not ideal, but given the alternatives,
> I think it is a reasonable risk.
> 
> Being 100% secure is simply not possible.  Security is often about balancing the
> risk/threat against the cost.  In this case, the risk is low (old hardware,
> uncommon setup for untrusted guests, small window of opportunity, and limited
> data exposure), whereas the cost is high (decent chance of breaking existing VMs).
Ok, thanks for explanation!
I still have one last question: if in future there are CPUs with no selfsnoop
(for some unknown reason, or just paranoid), do we allow this unsafe honoring of
guest memory type for non-coherent DMAs?