Thread (45 messages) 45 messages, 3 authors, 2023-08-15

Re: [PATCH v5 5/9] iommu/arm-smmu-v3: Refactor write_ctx_desc

From: Jason Gunthorpe <jgg@nvidia.com>
Date: 2023-08-15 12:57:36
Also in: linux-iommu, lkml

On Tue, Aug 15, 2023 at 08:36:55PM +0800, Michael Shavit wrote:
On Tue, Aug 15, 2023 at 8:30 PM Jason Gunthorpe [off-list ref] wrote:
quoted
On Tue, Aug 15, 2023 at 08:03:40PM +0800, Michael Shavit wrote:
quoted
On Tue, Aug 15, 2023 at 7:38 PM Jason Gunthorpe [off-list ref] wrote:
quoted
On Tue, Aug 15, 2023 at 01:20:04PM +0800, Michael Shavit wrote:
quoted
On Thu, Aug 10, 2023 at 11:39 PM Jason Gunthorpe [off-list ref] wrote:
quoted
Actually, I don't think this even works as nothing on the PASID path
adds to the list that arm_smmu_write_ctx_desc_devices() iterates over ??

Then the remaining two calls:

arm_smmu_share_asid(struct mm_struct *mm, u16 asid)
        arm_smmu_write_ctx_desc_devices(smmu_domain, 0, cd);

        This is OK only if the sketchy assumption that the CD
        we extracted for a conflicting ASID is not asigned to a PASID.

static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
        arm_smmu_write_ctx_desc_devices(smmu_domain, mm->pasid, &quiet_cd);

        This doesn't work because we didn't add the master to the list
        during __arm_smmu_sva_bind and this path is expressly working
        on the PASID binds, not the RID binds.
Actually it is working on the RID attached domain (as returned by
iommu_get_domain_for_dev() at sva_bind time) not the SVA domain
here...
That can't be right, the purpose of that call and arm_smmu_mm_release is to
disable the PASID that is about the UAF the mm's page table.

Jason
For the sake of this message, let's call "primary domain" whatever RID
domain was attached to a master at the time set_dev_pasid() was called
on that master. That RID domain is locked in while SVA is enabled and
cannot be detached.

The arm-smmu-v3-sva.c implementation creates a mapping between an SVA
domain and this primary domain (through the sva domain's mm). In
arm_smmu_mm_release, the primary domain is looked up and
arm_smmu_write_ctx_desc() is called on all masters that this domain is
attached to.
My question is still the same - how does arm_smmu_mm_release update the
Contex descriptor table entry for the *PASID*

The RID on PASID 0 hasn't change and doesn't need updating.

Jason
arm_smmu_mm_release looks-up the CD table(s) to write using the
primary domain's device list, and finds the index into those CD
table(s) to write to using mm->pasid.
Oh.. I don't think I caught that detail that at this point the
arm_smmu_write_ctx_desc_devices() argument must always be the rid
domain. Maybe add a comment to describe that? And lets try to undo
that later :(

Thanks,
Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help