linux-kernel - Re: [PATCH v6 01/10] kho: allow to drive kho from within kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aPXoKRVAyGWCNj8I@kernel.org>
Date: Mon, 20 Oct 2025 10:43:37 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: akpm@...ux-foundation.org, brauner@...nel.org, corbet@....net,
	graf@...zon.com, jgg@...pe.ca, linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
	masahiroy@...nel.org, ojeda@...nel.org, pratyush@...nel.org,
	rdunlap@...radead.org, tj@...nel.org, jasonmiu@...gle.com,
	dmatlack@...gle.com, skhawaja@...gle.com
Subject: Re: [PATCH v6 01/10] kho: allow to drive kho from within kernel

On Sat, Oct 18, 2025 at 01:17:47PM -0400, Pasha Tatashin wrote:
> Allow to do finalize and abort from kernel modules, so LUO could

We surely don't want modules being able to drive that. Maybe

   allow kernel to drive finalize and abort without requiring triggers
   from the userspace

> drive the KHO sequence via its own state machine.
> 
> Signed-off-by: Pasha Tatashin <pasha.tatashin@...een.com>
> Reviewed-by: Pratyush Yadav <pratyush@...nel.org>
> ---
>  include/linux/kexec_handover.h | 15 +++++++
>  kernel/kexec_handover.c        | 74 ++++++++++++++++++++--------------
>  2 files changed, 59 insertions(+), 30 deletions(-)

...

> diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c
> index 76f0940fb485..76c34ea923f0 100644
> --- a/kernel/kexec_handover.c
> +++ b/kernel/kexec_handover.c
> @@ -1067,7 +1067,7 @@ static int kho_out_update_debugfs_fdt(void)
>  	return err;
>  }
>  
> -static int kho_abort(void)
> +static int __kho_abort(void)
>  {
>  	int err;
>  	unsigned long order;
> @@ -1100,7 +1100,27 @@ static int kho_abort(void)
>  	return err;
>  }
>  
> -static int kho_finalize(void)
> +int kho_abort(void)
> +{
> +	int ret = 0;
> +
> +	if (!kho_enable)
> +		return -EOPNOTSUPP;
> +
> +	guard(mutex)(&kho_out.lock);

Please include linux/cleanup.h explicitly

> +	if (!kho_out.finalized)
> +		return -ENOENT;
> +

...

> -unlock:
> -	mutex_unlock(&kho_out.lock);
> -	return ret;
> +	return (!!_val) ? kho_finalize() : kho_abort();

An 'if' would be cleared IMO:

	if (val)
		return kho_finalize();
	else
		return kho_abort();

and we can rename u64 _val to u64 val as we are dropping the boolean.

>  }

-- 
Sincerely yours,
Mike.