Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Critical] Calling `set_memory_decrypted()` on a `HV_HYP_PAGE_SIZE` kmalloc buffer causes out-of-bounds memory decryption or silent failure when `PAGE_SIZE > 4096`. - [High] Passing an MTE-tagged `kmalloc` pointer directly to `set_memory_decrypted()` without untagging it causes address validation failures and breaks CPU initialization. --
commit 3df67c547c1f3625047cb1aee50d949f7179dd45 Author: Kameron Carr <[email protected]> Drivers: hv: Mark shared memory as decrypted for CCA Realms In hv_common_cpu_init(), the per-CPU hypercall input/output pages need to be marked as decrypted (shared) for confidential VM isolation types. This is already done for SNP and TDX isolation; extend the same handling to Arm CCA Realm guests so that the host hypervisor can access the shared hypercall buffers. [ ... ] > diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c > index 6b67ac6167891..010c7d98b5de1 100644 > --- a/drivers/hv/hv_common.c > +++ b/drivers/hv/hv_common.c > @@ -499,7 +499,8 @@ int hv_common_cpu_init(unsigned int cpu) > } > > if (!ms_hyperv.paravisor_present && > - (hv_isolation_type_snp() || hv_isolation_type_tdx())) { > + (hv_isolation_type_snp() || hv_isolation_type_tdx() || > + hv_isolation_type_cca())) { > ret = set_memory_decrypted((unsigned long)mem, pgcount); [Severity: Critical] Will this decrypt out-of-bounds memory or fail if PAGE_SIZE is larger than 4096 bytes on ARM64? The buffer mem is allocated in hv_common_cpu_init() as 1 or 2 Hyper-V 4KB pages: mem = kmalloc_array(pgcount, HV_HYP_PAGE_SIZE, flags); However, set_memory_decrypted() expects pgcount to be the number of system pages. On ARM64 kernels configured with 16KB or 64KB pages, passing pgcount will decrypt 16KB-128KB of memory, potentially overrunning the 4KB or 8KB allocation and exposing unrelated adjacent slab memory to the hypervisor. Additionally, if the kmalloc buffer is not aligned to the system PAGE_SIZE, set_memory_decrypted() will trigger a WARN_ON(!PAGE_ALIGNED(addr)) and silently return 0 without decrypting anything, leaving the hypercall page encrypted. [Severity: High] Does this code handle MTE tags correctly when passing mem to set_memory_decrypted()? On ARM64 with MTE enabled (CONFIG_KASAN_HW_TAGS), kmalloc_array() returns an MTE-tagged pointer. The ARM64 set_memory_decrypted() implementation validates the address using __is_lm_address(addr): arch/arm64/mm/pageattr.c:__set_memory_enc_dec() { ... if (!__is_lm_address(addr)) return -EINVAL; ... } Because __is_lm_address() performs software-side arithmetic without stripping the tag, the MTE tag bits cause an arithmetic wrap-around. This evaluates to false, returning -EINVAL and failing the CPU initialization process. > if (ret) { > /* It may be unsafe to free 'mem' */ > return ret; -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
