linux-kernel - RE: [RFC PATCH 5/6] iommu/amd: Introduce helper functions to setup GCR3TRPMode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 15 Dec 2023 07:39:43 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>, Suravee Suthikulpanit
	<suravee.suthikulpanit@....com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>, "joro@...tes.org"
	<joro@...tes.org>, "Liu, Yi L" <yi.l.liu@...el.com>, "nicolinc@...dia.com"
	<nicolinc@...dia.com>, "eric.auger@...hat.com" <eric.auger@...hat.com>,
	"vasant.hegde@....com" <vasant.hegde@....com>, "jon.grimm@....com"
	<jon.grimm@....com>, "santosh.shukla@....com" <santosh.shukla@....com>,
	"Dhaval.Giani@....com" <Dhaval.Giani@....com>, "pandoh@...gle.com"
	<pandoh@...gle.com>, "loganodell@...gle.com" <loganodell@...gle.com>
Subject: RE: [RFC PATCH 5/6] iommu/amd: Introduce helper functions to setup
 GCR3TRPMode

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Wednesday, December 13, 2023 9:53 PM
> 
> On Tue, Dec 12, 2023 at 10:01:38AM -0600, Suravee Suthikulpanit wrote:
> > +/*
> > + * For GCR3TRPMode, user-space provides GPA for the GCR3 Root Pointer
> Table.
> > + */
> > +int amd_iommu_set_gcr3tbl_trp(struct amd_iommu *iommu, struct
> pci_dev *pdev,
> > +			      u64 gcr3_tbl, u16 glx, u16 guest_paging_mode)
> > +{
> > +	struct iommu_dev_data *dev_data = dev_iommu_priv_get(&pdev-
> >dev);
> > +	struct dev_table_entry *dev_table = get_dev_table(iommu);
> > +	struct gcr3_tbl_info *gcr3_info = &dev_data->gcr3_info;
> > +	int devid = pci_dev_id(pdev);
> > +	u64 data0 = dev_table[devid].data[0];
> > +	u64 data1 = dev_table[devid].data[1];
> > +	u64 data2 = dev_table[devid].data[2];
> > +	u64 tmp;
> 
> Like I said in my other email, this whole function is conceptually
> wrong - you can't read the DTE to learn the parent domain's
> contribution to the nesting DTE and you can't write to the DTE during
> allocation of a domain!
> 

Agree. DTE is updated only at attach/detach. domain allocation should
involve things only about the domain itself.