linux-kernel - Re: [PATCH] iommu: arm-smmu-impl: add NXP hook to preserve bootmappings

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

Date:   Wed, 25 Nov 2020 18:10:21 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     laurentiu.tudor@....com, will@...nel.org, joro@...tes.org,
        linux-arm-kernel@...ts.infradead.org,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Cc:     diana.craciun@....com
Subject: Re: [PATCH] iommu: arm-smmu-impl: add NXP hook to preserve
 bootmappings

On 2020-11-25 15:50, laurentiu.tudor@....com wrote:
> From: Laurentiu Tudor <laurentiu.tudor@....com>
> 
> Add a NXP specific hook to preserve SMMU mappings present at
> boot time (created by the boot loader). These are needed for
> MC firmware present on some NXP chips to continue working
> across kernel boot and SMMU initialization.
> 
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@....com>
> ---
>   drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 33 ++++++++++++++++++++++
>   1 file changed, 33 insertions(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> index 7fed89c9d18a..ca07d9d4be69 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> @@ -187,6 +187,36 @@ static const struct arm_smmu_impl mrvl_mmu500_impl = {
>   	.reset = arm_mmu500_reset,
>   };
>   
> +static int nxp_cfg_probe(struct arm_smmu_device *smmu)
> +{
> +	int i, cnt = 0;
> +	u32 smr;
> +
> +	for (i = 0; i < smmu->num_mapping_groups; i++) {
> +		smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
> +
> +		if (FIELD_GET(ARM_SMMU_SMR_VALID, smr)) {

I bet this is fun over kexec...

Note that the Qualcomm special case got a bit of a free pass since it 
involves working around a totally broken hypervisor, plus gets to play 
the "nobody sane will run an enterprise distro on their phone" card to 
an extent; I don't think the likes of Layerscape kit get it quite so easy ;)

> +			smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
> +			smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr);
> +			smmu->smrs[i].valid = true;
> +
> +			smmu->s2crs[i].type = S2CR_TYPE_BYPASS;
> +			smmu->s2crs[i].privcfg = S2CR_PRIVCFG_DEFAULT;
> +			smmu->s2crs[i].cbndx = 0xff;
> +
> +			cnt++;
> +		}
> +	}
> +
> +	dev_notice(smmu->dev, "\tpreserved %d boot mapping%s\n", cnt,
> +		   cnt == 1 ? "" : "s");

That gets you around the initial SMMU reset, but what happens for the 
arbitrarily long period of time between the MC device getting attached 
to a default domain and the MC driver actually probing and (presumably) 
being able to map and reinitialise its firmware?

> +
> +	return 0;
> +}
> +
> +static const struct arm_smmu_impl nxp_impl = {
> +	.cfg_probe = nxp_cfg_probe,
> +};

I believe you're mostly using MMU-500, so you probably don't want to 
simply throw out the relevant errata workarounds.

>   struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
>   {
> @@ -226,5 +256,8 @@ struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
>   	if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
>   		smmu->impl = &mrvl_mmu500_impl;
>   
> +	if (of_property_read_bool(np, "nxp,keep-boot-mappings"))
> +		smmu->impl = &nxp_impl;

Normally you'd get a "what about ACPI?" here, but given the number of 
calls and email threads we've had specifically about trying to make ACPI 
support for these platforms work, that gets upgraded to at least a "WHAT 
ABOUT ACPI!?" :P

But seriously, the case of device firmware in memory being active before 
handover to Linux is *literally* the original reason behind IORT RMRs. 
We already know we need a way to specify the equivalent thing for DT 
systems, such that both can be handled commonly. I really don't want to 
have to support a vendor-specific mechanism for not-even-fully-solving a 
completely generic issue, sorry.

Robin.

> +
>   	return smmu;
>   }
>