Re: [PATCH v20 7/9] arm64: Block hibernate and kexec while RMM is active

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Sep 30, 2026 at 10:12:36AM +0100, Suzuki K Poulose wrote:
> On 29/09/2026 23:26, sashiko-bot@kernel.org wrote:
> > > diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> > > index 424291c547f02..253f544a59731 100644
> > > --- a/arch/arm64/kernel/hibernate.c
> > > +++ b/arch/arm64/kernel/hibernate.c
> > 
> > [ ... ]
> > 
> > > @@ -341,6 +342,11 @@ int swsusp_arch_suspend(void)
> > >   		return -EBUSY;
> > >   	}
> > > +	if (is_rmm_active()) {
> > > +		pr_err("Can't hibernate: RMM is active.\n");
> > > +		return -EBUSY;
> > > +	}
> > > +
> > 
> > [Severity: High]
> > While this successfully prevents saving a hibernation image, is there a missing
> > check in the resume path, specifically arch_hibernation_header_restore() in
> > arch/arm64/kernel/hibernate.c?
> > 
> > If a hibernation image is present on disk (e.g., from a prior boot with RMM
> > disabled, but with a matching uts_version), subsys_initcall(arm64_init_rmi)
> > activates RMM and delegates memory to the Realm PAS early in boot.
> > 
> > Later, late_initcall_sync(software_resume_initcall) restores the image.
> > Because arch_hibernation_header_restore() lacks an is_rmm_active() check,
> > the image is accepted. The low-level resume path swsusp_arch_resume() then
> > blindly overwrites physical memory with the saved image.
> > 
> > Without an upstream guard during resume, won't this overwrite newly delegated
> > Realm PAS memory, triggering a fatal Granule Protection Fault?
> 
> That is a valid point, I have added a check there to bail out if the rmm
> is active.

I wonder whether adding something to hibernation_available() would be
better, though it would have to be a __weak arch_hibernation_available()
or something similar.

I think it blocks both the suspend and resume paths and also hides
"disk" from /sys/power/state.

-- 
Catalin