Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA

[Robin Murphy]

On 12/05/2026 1:40 pm, Jason Gunthorpe wrote:
> On Tue, May 12, 2026 at 09:57:14AM +0000, Joonwon Kang wrote:
> > > There is a bit more going on though, I think that is what Joonwon is
> > > mentioning by asking about ST64B and ST64BV. I *think* the answer is:
> > >
> > > - ST64B uses a posted write
> > > - ST64BV can be restricted so EL0 cannot execute it, it uses a
> > >    non-posted write (AI tells me via EnASR)
> > > - ST64BV0 can be used by EL0, always uses a non-posted write, and always
> > >    uses ACCDATA_EL1
> > >
> > > Which is similar to Intel.
> >
> > Ah, I missed that ST64BV is currently being trapped to EL1 while ST64B is
> > not [1]. However, I am not sure if the trap is to disallow EL0 to use it.
> > Can it be instead to pass the response value of the non-posted write to
> > EL0 while using the EL0-given PASID as-is? If so, I believe EL0 still can
> > specify arbitrary PASID as it wants via ST64BV.
>
> I think if an OS implements things this way it is would security
> broken as far as ENQCMD compatible HW goes.

Yes, I think it's rather the point that the EnALS/EnASR traps to EL1 
allow EL1 to sanitise the data that ST64B/ST64BV are sending, and do 
exactly things like substituting a valid PASID. ST64BV0 offers a way of 
doing so _without_ needing the overhead of trapping, but conversely that 
needs the EnAS0 opt-in all the way down to indicate both EL1's awareness 
of programming ACCDATA_EL1 appropriately and EL2/3's awareness of 
context-switching it.

I've not looked closely at what exactly the arm64 arch code is doing 
today and how well it actually fits the expected ENQCMD usage model, but 
I can well believe it might need a bit of tweaking.

Thanks,
Robin.

> > Since I guess ST64B* instructions are to serve generic purposes not only
> > for communication with accelerators with SIOV but also with any memory
> > location or device without SIOV, I am not sure if it is always okay to
> > make those instructions work the way Jason mentioned.
>
> The end point has to use the posted vs non-posted write distinction
> for security.
>
> > > The device only processes the PASID from a non-posted write,
> >
> > Regarding ST64B, are the ARM devices behind ARM SMMU v3 supposed to work
> > this way too? If not, EL0 can specify arbitrary PASID via ST64B with the
> > kernel today [1].
>
> If you want ENQCMD compatible semantics then yes you have to do all of
> these things, it is part of the security design.
>
> Jason