[PATCH v2] KVM: s390: pv: ignore ultravisor donated storage for kmemleak

[PATCH v2] KVM: s390: pv: ignore ultravisor donated storage for kmemleak

[Christian Borntraeger]

ignore ultravisor base storage memory that was donated early on for
kmemleak to avoid kernel crashes when accessing such memory.

Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
v1->v2: rebase on linux/master
 arch/s390/kernel/uv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c
index a284f98d9716..7dde37c365a9 100644
--- a/arch/s390/kernel/uv.c
+++ b/arch/s390/kernel/uv.c
@@ -16,6 +16,7 @@
 #include <linux/swap.h>
 #include <linux/pagewalk.h>
 #include <linux/backing-dev.h>
+#include <linux/kmemleak.h>
 #include <asm/facility.h>
 #include <asm/sections.h>
 #include <asm/uv.h>
@@ -70,6 +71,7 @@ void __init setup_uv(void)
 			uv_info.uv_base_stor_len);
 		goto fail;
 	}
+	kmemleak_ignore_phys(__pa(uv_stor_base));
 
 	if (uv_init(__pa(uv_stor_base), uv_info.uv_base_stor_len)) {
 		memblock_free(uv_stor_base, uv_info.uv_base_stor_len);
-- 
2.53.0

Re: [PATCH v2] KVM: s390: pv: ignore ultravisor donated storage for kmemleak

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete fix: Kmemleak will crash the host when scanning KVM PV variable storage (stor_var)
--

--- Patch [1]: [PATCH v2] KVM: s390: pv: ignore ultravisor donated storage for kmemleak ---
commit f3ecf0128072e5354e12f9c00c85c0768e09acaa
Author: Christian Borntraeger <borntraeger@linux.ibm.com>

KVM: s390: pv: ignore ultravisor donated storage for kmemleak

This commit fixes host kernel crashes that occur when kmemleak scans the 
ultravisor base storage memory. It explicitly tells kmemleak to ignore the 
donated memory by calling kmemleak_ignore_phys().

> diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c
> index a284f98d97168..7dde37c365a99 100644
> --- a/arch/s390/kernel/uv.c
> +++ b/arch/s390/kernel/uv.c

[ ... ]

> @@ -70,6 +71,7 @@ void __init setup_uv(void)
>  			uv_info.uv_base_stor_len);
>  		goto fail;
>  	}
> +	kmemleak_ignore_phys(__pa(uv_stor_base));

[Severity: High]
This isn't a bug introduced by this patch, but does the same problem apply to
the per-VM variable storage allocated in KVM?

Looking at kvm_s390_pv_alloc_vm(), it allocates stor_var using vzalloc():

arch/s390/kvm/pv.c:kvm_s390_pv_alloc_vm() {
    ...
	kvm->arch.pv.stor_var = vzalloc(vlen);
	if (!kvm->arch.pv.stor_var)
		goto out_err;
    ...
}

This memory is tracked by kmemleak and is subsequently donated to the
Ultravisor in kvm_s390_pv_init_vm():

arch/s390/kvm/pv.c:kvm_s390_pv_init_vm() {
    ...
	uvcb.conf_virt_stor_origin = (u64)kvm->arch.pv.stor_var;
    ...
	cc = uv_call_sched(0, (u64)&uvcb);
    ...
}

Once donated, the underlying physical pages become secure and inaccessible to
the host. Will the kmemleak background thread scanning the vmalloc space attempt
to read this secure memory and trigger a hardware exception, just like it does
for uv_stor_base? 

Could a call to kmemleak_ignore(kvm->arch.pv.stor_var) be needed here to make
the fix complete and prevent similar host crashes?

>  
>  	if (uv_init(__pa(uv_stor_base), uv_info.uv_base_stor_len)) {
>  		memblock_free(uv_stor_base, uv_info.uv_base_stor_len);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717133136.5188-1-borntraeger@linux.ibm.com?part=1