[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DS0PR11MB7529EA8256BD06A96C8D1A85C308A@DS0PR11MB7529.namprd11.prod.outlook.com>
Date: Thu, 3 Aug 2023 03:07:23 +0000
From: "Liu, Yi L" <yi.l.liu@...el.com>
To: Nicolin Chen <nicolinc@...dia.com>,
Jason Gunthorpe <jgg@...dia.com>
CC: "joro@...tes.org" <joro@...tes.org>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"Tian, Kevin" <kevin.tian@...el.com>,
"robin.murphy@....com" <robin.murphy@....com>,
"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
"cohuck@...hat.com" <cohuck@...hat.com>,
"eric.auger@...hat.com" <eric.auger@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"mjrosato@...ux.ibm.com" <mjrosato@...ux.ibm.com>,
"chao.p.peng@...ux.intel.com" <chao.p.peng@...ux.intel.com>,
"yi.y.sun@...ux.intel.com" <yi.y.sun@...ux.intel.com>,
"peterx@...hat.com" <peterx@...hat.com>,
"jasowang@...hat.com" <jasowang@...hat.com>,
"shameerali.kolothum.thodi@...wei.com"
<shameerali.kolothum.thodi@...wei.com>,
"lulu@...hat.com" <lulu@...hat.com>,
"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"Duan, Zhenzhong" <zhenzhong.duan@...el.com>
Subject: RE: [PATCH v3 09/17] iommufd: Add IOMMU_HWPT_INVALIDATE
> From: Nicolin Chen <nicolinc@...dia.com>
> Sent: Thursday, August 3, 2023 10:17 AM
>
> On Mon, Jul 31, 2023 at 10:19:09AM -0300, Jason Gunthorpe wrote:
> > On Mon, Jul 31, 2023 at 10:07:32AM +0000, Liu, Yi L wrote:
> > > > > + goto out_put_hwpt;
> > > > > + }
> > > > > +
> > > > > + /*
> > > > > + * Copy the needed fields before reusing the ucmd buffer, this
> > > > > + * avoids memory allocation in this path.
> > > > > + */
> > > > > + user_ptr = cmd->data_uptr;
> > > > > + user_data_len = cmd->data_len;
> > > >
> > > > Uhh, who checks that klen < the temporary stack struct?
> > >
> > > Take vtd as an example. The invalidate structure is struct
> iommu_hwpt_vtd_s1_invalidate[1].
> > > The klen is sizeof(struct iommu_hwpt_vtd_s1_invalidate)[2].
> iommu_hwpt_vtd_s1_invalidate
> > > is also placed in the temporary stack struct (actually it is a union)[1]. So the klen
> should
> > > be <= temporary stack.
> >
> > Ohh, I think I would add a few comments noting that the invalidate
> > structs need to be added to that union. Easy to miss.
>
> Added here:
>
> - * Copy the needed fields before reusing the ucmd buffer, this
> - * avoids memory allocation in this path.
> + * Copy the needed fields before reusing the ucmd buffer, this avoids
> + * memory allocation in this path. Again, user invalidate data struct
> + * must be added to the union ucmd_buffer.
>
> > > It's not so explicit though. Perhaps worth to have a check like below in this patch?
> > >
> > > if (unlikely(klen > sizeof(union ucmd_buffer)))
> > > return -EINVAL;
> >
> > Yes, stick this in the domain allocate path with a WARN_ON. The driver
> > is broken to allocate a domain with an invalid size.
>
> And here too with a WARN_ON_ONCE.
>
> + /*
> + * Either the driver is broken by having an invalid size, or the user
> + * invalidate data struct used by the driver is missing in the union.
> + */
> + if (WARN_ON_ONCE(hwpt->domain->ops->cache_invalidate_user &&
> + (!hwpt->domain->ops->cache_invalidate_user_data_len ||
> + hwpt->domain->ops->cache_invalidate_user_data_len >
> + sizeof(union ucmd_buffer)))) {
> + rc = -EINVAL;
> + goto out_abort;
> +
> + }
>
> Though I am making this cache_invalidate_user optional here, I
> wonder if there actually could be a case that a user-managed
> domain doesn't need a cache_invalidate_user op...
If user-managed domain is the stage-1 domain in nested, then seems not
possible as cache invalidate is a must. But I think this logic is fine as not
all the domains allocated by the user is user-managed. It may be kernel
managed like the s2 domains.
Regards,
Yi Liu
Powered by blists - more mailing lists