Received-SPF: pass (google.com: domain of linux-kernel+bounces-188245-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Fri, 24 May 2024 11:07:56 +0800
From: Yan Zhao <yan.y.zhao@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
CC: Alex Williamson <alex.williamson@redhat.com>, "Tian, Kevin"
	<kevin.tian@intel.com>, "Vetter, Daniel" <daniel.vetter@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>, "pbonzini@redhat.com"
	<pbonzini@redhat.com>, "seanjc@google.com" <seanjc@google.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"luto@kernel.org" <luto@kernel.org>, "peterz@infradead.org"
	<peterz@infradead.org>, "tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>, "bp@alien8.de" <bp@alien8.de>,
	"hpa@zytor.com" <hpa@zytor.com>, "corbet@lwn.net" <corbet@lwn.net>,
	"joro@8bytes.org" <joro@8bytes.org>, "will@kernel.org" <will@kernel.org>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>, "baolu.lu@linux.intel.com"
	<baolu.lu@linux.intel.com>, "Liu, Yi L" <yi.l.liu@intel.com>
Subject: Re: [PATCH 4/5] vfio/type1: Flush CPU caches on DMA pages in
 non-coherent domains
Message-ID: <ZlAEjMIpSG8PoMnc@yzhao56-desk.sh.intel.com>
Reply-To: Yan Zhao <yan.y.zhao@intel.com>
References: <ZkG9IEQwi7HG3YBk@yzhao56-desk.sh.intel.com>
 <BN9PR11MB52766D78684F6206121590B98CED2@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20240516143159.0416d6c7.alex.williamson@redhat.com>
 <20240517171117.GB20229@nvidia.com>
 <BN9PR11MB5276250B2CF376D15D16FF928CE92@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20240521160714.GJ20229@nvidia.com>
 <20240521102123.7baaf85a.alex.williamson@redhat.com>
 <20240521163400.GK20229@nvidia.com>
 <Zk1lZNCPywTmythz@yzhao56-desk.sh.intel.com>
 <20240522122605.GS20229@nvidia.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20240522122605.GS20229@nvidia.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?N0f0j4qFH4pIwrHdGhudZxBU9NKEFQOSnCgj6EOUm6ktjUgFasTuSdoDbvoi?=
 =?us-ascii?Q?uD/CLa7wV8zZLx3DCdKJVk+lv2LrG+JkS1qeIfV88WE5fVEYKDadm5ajb9Ed?=
 =?us-ascii?Q?xQydPjzbsVfk9umLLC2Gg1haOyTd01fLFU9HZXxAeqLvWTnK0tjM5Tm//0in?=
 =?us-ascii?Q?E+4nUhGX0luZSwzOSIrpN+V/bKIdaLLkh5eqmunBc2DfqVGo7McERUrvJqC8?=
 =?us-ascii?Q?hwwsqikBUm5KAZWYeeUrSJ9MsduSWyotdd5S4LHMcA305ZijCiAecBuqKQr9?=
 =?us-ascii?Q?AhpPCGZ2a3euGT4ACp8bq8CEVU8w35ZU4AP8ixyrqapkWfBlSD/5SDrO0K5G?=
 =?us-ascii?Q?DCyxPHV2RDKDCt1K76ZT7uWI6k1BV3HjQj5ASoV6F1AQ/sFb/LOcTqhEKJtH?=
 =?us-ascii?Q?WLDkkSSjW+eUo5fhedloyVQ/OVxmq13oRJVlO1lp39/57b7uHFxBk78scp2B?=
 =?us-ascii?Q?aQP2c5qv4CQsyOZeyqY6n9hauNmVEM2zkR+OCrG9xnMwLmY92qL8cXBHc+jC?=
 =?us-ascii?Q?om7azgMNvSg1gaky3s4tw9f0buB1CuOA4RrM0RRljWUDbdCAWYWXH/6wBf8w?=
 =?us-ascii?Q?OiN7PG9pQty/BBamII4JLyat/SUZH8bG4So+jNE4j/nJJ45OS/1Tupm9VPwz?=
 =?us-ascii?Q?l0OBzu0yN896p/iQupJils6+aX4g/03kePcTLmRDTTCPeu2F/XrV4Er1FwYJ?=
 =?us-ascii?Q?9GX2vHJcemkv8Y+8n7SfnBoiteYoin/QMSskSFV7OOtCco1sO582wZXXsZHc?=
 =?us-ascii?Q?CwwFqtDZx+z1jIRPoCp/cWnk1lknM18LWImr1Py+S0Jcbrna5o4FNErPM3g0?=
 =?us-ascii?Q?a41TL7HNYxZ4X/vuhuDpnKHkxbvrnjSULvzOHa0n4lC87lxOzusCuxFiyqBo?=
 =?us-ascii?Q?uEcA0kAp62EvBXXqWohKCHET+f+qRR8zhosNgpLX3hvBSgCi9UnMlmLvOG12?=
 =?us-ascii?Q?1H9zice79cFxlBf300cWHR2+2FVonlZq5bq/EndynWqnl7cNh4wQ/kx/kMdO?=
 =?us-ascii?Q?yuzpuU+HKC339wHmCCTrrMFWEVWa2LMeEBmat29TRlpEfGK6izF6VyHWhj5/?=
 =?us-ascii?Q?c42clHFl0GkrYN2vvL8yQAcV0+hCE4ifONtqOdbMm6S+wlpMmbSRa6WH9rG4?=
 =?us-ascii?Q?juIHCZB9Bg/eplRquXFPb1OWB5PfmY+LLeKrLSOOrYX7w7cK06Y7A6frW2Bw?=
 =?us-ascii?Q?Kbt69kSxSUqLoHle0DgQL/cUkqIWA+MIj/pp7UieI5TdgqW5UvFeiFzYCz66?=
 =?us-ascii?Q?DTCS+kHnH/UCi4PgbGfH/OEh0xoNArYXaWqmiahzYy7gkpbDjf1edgetwV73?=
 =?us-ascii?Q?JgtXfxXytBSS8Z3pYJn8rBWdAf7KL4yyKLtorkV+KknWbQUM7LFtLWtGUurb?=
 =?us-ascii?Q?EECOccZeJpP4OL/DFdmSaglQP/Ie6Fa5vG1IAYVGVacBqzFn6DL8Ig41crWJ?=
 =?us-ascii?Q?pYME6waMgNDTLJ/u3hJZAE+PxWNB0y+4gOP+pEWolBgdRTaiVgJOoYrbrgIF?=
 =?us-ascii?Q?s8IgzDqf2lAOIin94dVWVRsKJGnvRhKcOLiiRG/cxgisz4juSKEQnbjTpR/R?=
 =?us-ascii?Q?sgpYTCVqczDVAREuPCCEP3RQyYpoOC36X3KoRpm8?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 97b5dfe9-3c37-4a8c-70eb-08dc7b9ed56e
X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB5966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2024 03:08:49.7537
 (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: SC2t6naCXjAo4VSqDfLurV13FqjlVCbKqppqKlDpugSytmTCTikr219OKPIJceYiQAIDzwxHLkSWGUMTJNmOUw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB8273
X-OriginatorOrg: intel.com

On Wed, May 22, 2024 at 09:26:05AM -0300, Jason Gunthorpe wrote:
> On Wed, May 22, 2024 at 11:24:20AM +0800, Yan Zhao wrote:
> > On Tue, May 21, 2024 at 01:34:00PM -0300, Jason Gunthorpe wrote:
> > > On Tue, May 21, 2024 at 10:21:23AM -0600, Alex Williamson wrote:
> > > 
> > > > > Intel GPU weirdness should not leak into making other devices
> > > > > insecure/slow. If necessary Intel GPU only should get some variant
> > > > > override to keep no snoop working.
> > > > > 
> > > > > It would make alot of good sense if VFIO made the default to disable
> > > > > no-snoop via the config space.
> > > > 
> > > > We can certainly virtualize the config space no-snoop enable bit, but
> > > > I'm not sure what it actually accomplishes.  We'd then be relying on
> > > > the device to honor the bit and not have any backdoors to twiddle the
> > > > bit otherwise (where we know that GPUs often have multiple paths to get
> > > > to config space).
> > > 
> > > I'm OK with this. If devices are insecure then they need quirks in
> > > vfio to disclose their problems, we shouldn't punish everyone who
> > > followed the spec because of some bad actors.
> > Does that mean a malicous device that does not honor the bit could read
> > uninitialized host data?
> 
> Yes, but a malicious device could also just do DMA with the PF RID and
> break everything. VFIO substantially trusts the device already, I'm
> not sure trusting it to do no-snoop blocking is a big reach.
There are minor differences between the two trusts though.
With no-snoop, the page is possible to be critical data previously used by
kernel core.
But with a fake RID, a malicious device can at least access memory allowed
for other devices.