Re: [PATCH v5 5/6] arm64: hyperv: Route hypercalls through RSI host call in CCA Realms

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] arm64: hyperv: kcalloc fails to guarantee 256-byte alignment for rsi_host_call
- [Medium] arm64: hyperv: missing NULL pointer guard on hv_hostcall_array causes recursive panic
--

commit 2c893995afa956ce0fb20a1d090c6e04fba71575
Author: Kameron Carr <kameroncarr@linux.microsoft.com>

arm64: hyperv: Route hypercalls through RSI host call in CCA Realms

This commit updates the Hyper-V hypercall wrappers to check if the kernel
is running in a CCA Realm. If so, it routes the hypercalls through the RSI
host call interface using the per-CPU hv_hostcall_array.

> diff --git a/arch/arm64/hyperv/hv_core.c b/arch/arm64/hyperv/hv_core.c
> index e33a9e3c366a1..2f6fc1469c54f 100644
> --- a/arch/arm64/hyperv/hv_core.c
> +++ b/arch/arm64/hyperv/hv_core.c
> @@ -12,11 +12,43 @@

[ ... ]

> +static u64 hv_do_rsi_hypercall(u64 control, u64 input1, u64 input2)
> +{
> +	struct rsi_host_call *hostcall;
> +	unsigned long flags;
> +	u64 ret;
> +
> +	if (!hv_hostcall_array)
> +		return HV_STATUS_INVALID_HYPERCALL_INPUT;
> +
> +	local_irq_save(flags);
> +	hostcall = &hv_hostcall_array[smp_processor_id()];
> +	memset(hostcall, 0, sizeof(*hostcall));
> +	hostcall->gprs[0] = HV_FUNC_ID;
> +	hostcall->gprs[1] = control;
> +	hostcall->gprs[2] = input1;
> +	hostcall->gprs[3] = input2;
> +
> +	if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS)

[Severity: High]
Does this physical address satisfy the RMM's 256-byte alignment requirement?

If hv_hostcall_array was allocated with kcalloc() (e.g., in hyperv_init()),
the allocation might not guarantee strict 256-byte alignment when SLUB
debugging or KASAN is enabled due to redzone shifts. If the resulting
address is misaligned, could the RMM reject the SMC host call and return an
error that eventually triggers a BUG_ON() and kernel panic?

[ ... ]

> @@ -76,24 +117,44 @@ EXPORT_SYMBOL_GPL(hv_do_fast_hypercall16);
>  void hv_set_vpreg(u32 msr, u64 value)
>  {
>  	struct arm_smccc_res res;
> +	struct rsi_host_call *hostcall;
> +	unsigned long flags;
> +	u64 status;
>  
> -	arm_smccc_1_1_hvc(HV_FUNC_ID,
> -		HVCALL_SET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
> -			HV_HYPERCALL_REP_COMP_1,
> -		HV_PARTITION_ID_SELF,
> -		HV_VP_INDEX_SELF,
> -		msr,
> -		0,
> -		value,
> -		0,
> -		&res);
> +	if (is_realm_world()) {
> +		local_irq_save(flags);
> +		hostcall = &hv_hostcall_array[smp_processor_id()];
> +		memset(hostcall, 0, sizeof(*hostcall));

[Severity: Medium]
Is it safe to access hv_hostcall_array here without a NULL check?

In hv_do_rsi_hypercall() above, there is a check for !hv_hostcall_array. If
Hyper-V initialization fails and sets hv_hostcall_array to NULL, but the
panic notifier remains registered, a later kernel panic could invoke
hyperv_report_panic() which calls hv_set_vpreg(). Without a guard,
this memset() could cause a recursive fault and break the crash handler.

[ ... ]

> @@ -108,29 +169,55 @@ void hv_get_vpreg_128(u32 msr, struct hv_get_vp_registers_output *result)
>  {
>  	struct arm_smccc_1_2_regs args;
>  	struct arm_smccc_1_2_regs res;
> +	struct rsi_host_call *hostcall;
> +	unsigned long flags;
> +	u64 status;
>  
> -	args.a0 = HV_FUNC_ID;
> -	args.a1 = HVCALL_GET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
> -			HV_HYPERCALL_REP_COMP_1;
> -	args.a2 = HV_PARTITION_ID_SELF;
> -	args.a3 = HV_VP_INDEX_SELF;
> -	args.a4 = msr;
> +	if (is_realm_world()) {
> +		local_irq_save(flags);
> +		hostcall = &hv_hostcall_array[smp_processor_id()];
> +		memset(hostcall, 0, sizeof(*hostcall));

[Severity: Medium]
Could this also cause a NULL pointer dereference if hv_hostcall_array
was freed and set to NULL during an early boot failure?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002215725.2015959-1-kameroncarr@linux.microsoft.com?part=5