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

[Robin Murphy <robin.murphy@arm.com>]

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