linux-kernel - Re: [PATCH] iommu/io-pgtable-arm: Add misisng concatenated PGD cases

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] [day] [month] [year] [list]

Message-ID: <8e058f60-60da-47c2-9947-2ea26cca1639@arm.com>
Date: Wed, 10 Dec 2025 12:06:10 +0000
From: Robin Murphy <robin.murphy@....com>
To: Will Deacon <will@...nel.org>
Cc: Mostafa Saleh <smostafa@...gle.com>, iommu@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 joro@...tes.org, Tomasz Nowicki <tnowicki@...gle.com>
Subject: Re: [PATCH] iommu/io-pgtable-arm: Add misisng concatenated PGD cases

On 2025-12-10 12:42 am, Will Deacon wrote:
> On Tue, Dec 09, 2025 at 01:33:36PM +0000, Robin Murphy wrote:
>> On 2025-12-09 12:37 pm, Mostafa Saleh wrote:
>>> On Tue, Dec 09, 2025 at 11:34:34AM +0000, Robin Murphy wrote:
>>>> On 2025-11-30 7:45 pm, Mostafa Saleh wrote:
>>>>> arm_lpae_concat_mandatory() assumes that OAS >= IAS which is not
>>>>> correct for SMMUs supporting AArch32, and have OAS = 32/36 bits,
>>>>> as IAS would be 40 bits.
>>>>
>>>> But that is only when *using* AArch32 format. The bit in chapter 3.4 of the
>>>> SMMU architecture is talking about the maximum IAS that an SMMU
>>>> implementation needs to be able to accommodate based on its configuration,
>>>> but it does then attempt to clarify that the actual IPA size in use by any
>>>> given context should depend on the VMSA format in use:
>>>>
>>>> "VMSAv8-32 LPAE always supports an IPA size of 40 bits, whereas VMSAv8-64
>>>> and VMSAv9-128 limits the maximum IPA size to the maximum PA size."
>>>>
>>>> Rule R_SRKBC in the Arm ARM lays out the exact T0SZ constraints with this
>>>> AArch32/AArch64 detail.
>>>
>>> I see, thanks a lot for the explanation, I got confused by the this
>>> statement:
>>> Note: If AArch32 is implemented, IAS == MAX(40, OAS), otherwise IAS == OAS.
>>
>> Indeed, that appears confusingly contradictory; I've filed a bug.
> 
> I think the spec has always been worded like this. My reading is that, in
> isolation:
> 
>    - VMSAv8-32 LPAE always uses a 40-bit IAS
>    - VMSAv8-64 has IAS == OAS and this can be smaller than 40 bits
> 
> so if AArch32 is implemented, we know that the hardware supports at
> least a 40-bit IAS and in that case the VMSAv8-64 IAS can be bigger
> than the OAS.

No, the VMSAv8-64 IAS can never be bigger than OAS, as that would 
violate VMSA (see rules R_DTLMN and R_SRKBC). The SMMU spec seems mostly 
fixated on the notional maximum IAS that an SMMU must accommodate in 
general across all supported formats; the limitations of using any 
particular format must still apply though (similarly, the fact that 
AArch32 has a fixed 40-bit output doesn't mean that OAS and S2PS don't 
still matter for AArch64 format.)

Note that AArch32 is still free to use less than 40 bits of IAS if it 
wants to, by setting S2T0SZ appropriately, it's just guaranteed to 
support a *minimum* S2T0SZ of 24 regardless of OAS, unlike AArch64.

Cheers,
Robin.

> That seems consistent to me; where is the contradiction?
> 
> Will (jet-lagged so may well be talking rubbish!)