Re: [PATCH 2/6] firmware: arm_rmm: Add wrappers for direct RMI calls

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Uninitialized stack variable read in `rmi_granule_tracking_get` and `rmi_features` on systems without SMCCC conduit.
--

--- Patch [2]: [PATCH 2/6] firmware: arm_rmm: Add wrappers for direct RMI calls ---
commit 429eeeda61aa453a82790a92c189fa7325a46943
Author: Steven Price <steven.price@arm.com>

firmware: arm_rmm: Add wrappers for direct RMI calls

This commit adds inline wrapper functions for direct RMI calls to the Realm
Management Monitor (RMM) via SMCCC, dealing with boilerplate and return codes.

> diff --git a/include/linux/arm-rmi-cmds.h b/include/linux/arm-rmi-cmds.h
> new file mode 100644
> index 0000000000000..c038c1d685fad
> --- /dev/null
> +++ b/include/linux/arm-rmi-cmds.h

[ ... ]

> +static inline int rmi_granule_tracking_get(unsigned long start,
> +					   unsigned long end,
> +					   unsigned long *out_category,
> +					   unsigned long *out_state,
> +					   unsigned long *out_top)
> +{
> +	struct arm_smccc_res res;
> +
> +	arm_smccc_1_1_invoke(SMC_RMI_GRANULE_TRACKING_GET, start, end, &res);
> +
> +	if (out_category)
> +		*out_category = res.a1;
> +	if (out_state)
> +		*out_state = res.a2;
> +	if (out_top)
> +		*out_top = res.a3;

[Severity: Medium]
Could this copy uninitialized stack memory into the caller's output pointers
if the SMCCC conduit is unavailable?

When arm_smccc_1_1_invoke is executed on a platform without an active
conduit, it falls back to __fail_smccc_1_1():

include/linux/arm-smccc.h:arm_smccc_1_1_invoke() {
        ...
        default:
                __fail_smccc_1_1(__VA_ARGS__);
                method = SMCCC_CONDUIT_NONE;
                break;
        ...
}

This fallback only initializes res.a0 to SMCCC_RET_NOT_SUPPORTED, leaving
res.a1, res.a2, and res.a3 completely uninitialized.

Because these values are read unconditionally here, this could trigger KMSAN
warnings or leak stack garbage into the output pointers. Should these
assignments be gated behind a check that res.a0 == RMI_SUCCESS?

> +
> +	return res.a0;
> +}

[ ... ]

> +static inline int rmi_features(unsigned long index, unsigned long *out)
> +{
> +	struct arm_smccc_res res;
> +
> +	arm_smccc_1_1_invoke(SMC_RMI_FEATURES, index, &res);
> +
> +	if (out)
> +		*out = res.a1;

[Severity: Medium]
Does this have the same uninitialized memory read issue when the SMCCC
conduit is not supported?

> +	return res.a0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715142739.80398-1-steven.price@arm.com?part=2