Re: [PATCH v6 4/6] Drivers: hv: Mark shared memory as decrypted for CCA Realms

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] hv: arm64: set_memory_decrypted() in hv_common_cpu_init() hits BBML3 -EBUSY
--

commit 8d15e623ca43bf983a70fccbb187c60423dd18ef
Author: Kameron Carr <kameroncarr@linux.microsoft.com>

Drivers: hv: Mark shared memory as decrypted for CCA Realms

This commit introduces hv_isolation_type_cca() and extends
hv_common_cpu_init() to mark the per-CPU hypercall input and output pages as
decrypted on Arm CCA Realm guests. It also aligns the hypercall buffer
allocation size to PAGE_SIZE when calling set_memory_decrypted().

> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index 31256cb22b39e..a60c92cd83eac 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -476,6 +476,7 @@ int hv_common_cpu_init(unsigned int cpu)
>  	u64 msr_vp_index;
>  	gfp_t flags;
>  	const int pgcount = hv_output_page_exists() ? 2 : 1;
> +	const size_t alloc_size = ALIGN((size_t)pgcount * HV_HYP_PAGE_SIZE, PAGE_SIZE);
>  	void *mem;
>  	int ret = 0;
>  
> @@ -489,7 +490,7 @@ int hv_common_cpu_init(unsigned int cpu)
>  	 * online and then taken offline
>  	 */
>  	if (!*inputarg) {
> -		mem = kmalloc_array(pgcount, HV_HYP_PAGE_SIZE, flags);
> +		mem = kmalloc(alloc_size, flags);
>  		if (!mem)
>  			return -ENOMEM;
>  
> @@ -499,14 +500,16 @@ int hv_common_cpu_init(unsigned int cpu)
>  		}
>  
>  		if (!ms_hyperv.paravisor_present &&
> -		    (hv_isolation_type_snp() || hv_isolation_type_tdx())) {
> -			ret = set_memory_decrypted((unsigned long)mem, pgcount);
> +		    (hv_isolation_type_snp() || hv_isolation_type_tdx() ||
> +		     hv_isolation_type_cca())) {
> +			ret = set_memory_decrypted((unsigned long)mem,
> +						   alloc_size >> PAGE_SHIFT);
>  			if (ret) {
>  				/* It may be unsafe to free 'mem' */\
>  				return ret;
>  			}

[Severity: High]
Can calling set_memory_decrypted() from hv_common_cpu_init() fail with -EBUSY
and prevent secondary CPUs from coming online on BBML3-capable arm64 systems?

On arm64, when the boot CPU supports BBML3 and debug_pagealloc is disabled,
paging_init() -> map_mem() sets linear_map_requires_bbml3 = true and maps the
linear region with block/contiguous descriptors because is_realm_world()
makes can_set_direct_map() return true.

In arch/arm64/hyperv/mshyperv.c, hyperv_init() runs as an early_initcall()
during do_pre_smp_initcalls() and registers hv_common_cpu_init() for
CPUHP_AP_HYPERV_ONLINE:

	ret = cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE, "arm64/hyperv_init:online",
				hv_common_cpu_init, hv_common_cpu_die);

Next, smp_init() calls bringup_nonboot_cpus() before smp_cpus_done() ->
setup_system_features() -> setup_system_capabilities() finalizes the
ARM64_HAS_BBML3 capability. During bringup_nonboot_cpus(), each secondary CPU
is marked online in secondary_start_kernel() (making num_online_cpus() > 1)
and then executes CPUHP_AP_HYPERV_ONLINE -> hv_common_cpu_init() while
system_supports_bbml3() and system_capabilities_finalized() are still false.

That leads to the following call chain on the secondary CPU:

  hv_common_cpu_init()
    set_memory_decrypted()
      realm_set_memory_decrypted()
        __set_memory_enc_dec()
          __change_memory_common()
            update_range_prot()
              split_kernel_leaf_mapping()

In arch/arm64/mm/mmu.c:split_kernel_leaf_mapping(), splitting the linear map
in this window triggers a warning and returns -EBUSY:

	if (!linear_map_requires_bbml3 || is_kfence_address((void *)start))
		return 0;

	if (!system_supports_bbml3()) {
		if (system_capabilities_finalized())
			return 0;

		if (WARN_ON(!page_alloc_available))
			return -EBUSY;

		/*
		 * Boot-time: Started secondary cpus but don't know if they
		 * support BBML3 yet. Can't allow splitting in this window
		 * in case they don't.
		 */
		if (WARN_ON(num_online_cpus() > 1))
			return -EBUSY;
	}

When split_kernel_leaf_mapping() returns -EBUSY, hv_common_cpu_init() leaks
the mem buffer and returns -EBUSY from the CPUHP_AP_HYPERV_ONLINE callback,
aborting secondary CPU bringup.

Should the per-CPU hypercall buffers for possible CPUs be allocated and
decrypted earlier on the boot CPU (for example in hv_common_init() while
num_online_cpus() == 1), or after system capabilities have been finalized?

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