Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Host call structure `uuid_hc` is allocated in protected memory, which will cause the RMM to reject the RSI_HOST_CALL. --
commit ec503a8b7982b956b2d7e06ff213250087e22275 Author: Kameron Carr <[email protected]> firmware: smccc: Detect hypervisor via RSI host call in CCA Realms Modify arm_smccc_hypervisor_has_uuid() to check is_realm_world() and use rsi_host_call() to query the hypervisor vendor UUID when inside a Realm. This introduces a file-static rsi_host_call buffer serialized by a spinlock to handle the request. > diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c > index bdee057db2fd3..6b465e65472b0 100644 > --- a/drivers/firmware/smccc/smccc.c > +++ b/drivers/firmware/smccc/smccc.c [ ... ] > @@ -67,12 +73,45 @@ s32 arm_smccc_get_soc_id_revision(void) > } > EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision); > > +#ifdef CONFIG_ARM64 > +static struct rsi_host_call uuid_hc; > +static DEFINE_SPINLOCK(uuid_hc_lock); > + > +/* > + * Helper function to get the hypervisor UUID via an RsiHostCall. > + */ > +static bool arm_smccc_realm_get_hypervisor_uuid(struct arm_smccc_res *res) > +{ > + guard(spinlock_irqsave)(&uuid_hc_lock); > + > + memset(&uuid_hc, 0, sizeof(uuid_hc)); > + uuid_hc.gprs[0] = ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID; > + > + if (rsi_host_call(__pa_symbol(&uuid_hc)) != RSI_SUCCESS) [Severity: High] Will the RMM reject this host call because uuid_hc is located in protected memory? In ARM CCA (Realms), the memory passed to the RMM for an RSI_HOST_CALL needs to be in the unprotected (shared) state, as the untrusted host hypervisor must be able to read and write to it. Since uuid_hc is statically allocated, it resides in the kernel's protected BSS section. Calling rsi_host_call() with this physical address will likely result in RSI_ERROR_INPUT and break hypervisor UUID discovery. Additionally, because memory decryption operates at page granularity, applying set_memory_decrypted() to a static variable would decrypt adjacent, unrelated kernel data and expose it to the untrusted host. Should this instead use a dedicated, dynamically allocated page that is safely marked as decrypted? > + return false; > + > + res->a0 = uuid_hc.gprs[0]; > + res->a1 = uuid_hc.gprs[1]; > + res->a2 = uuid_hc.gprs[2]; > + res->a3 = uuid_hc.gprs[3]; > + return true; > +} > +#endif -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
