linux-kernel - RE: [PATCH v2 2/2] kfence: allow change number of object by early parameter

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 for Android: free password hash cracker in your pocket

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

Message-ID: <7334df3287534327a3e4a09c5c8d9432@honor.com>
Date: Thu, 18 Dec 2025 10:18:02 +0000
From: yuanlinyu <yuanlinyu@...or.com>
To: Marco Elver <elver@...gle.com>
CC: Alexander Potapenko <glider@...gle.com>, Dmitry Vyukov
	<dvyukov@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Huacai Chen
	<chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>,
	"kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "loongarch@...ts.linux.dev"
	<loongarch@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 2/2] kfence: allow change number of object by early
 parameter

> From: Marco Elver <elver@...gle.com>
> Sent: Thursday, December 18, 2025 4:57 PM
> To: yuanlinyu <yuanlinyu@...or.com>
> Cc: Alexander Potapenko <glider@...gle.com>; Dmitry Vyukov
> <dvyukov@...gle.com>; Andrew Morton <akpm@...ux-foundation.org>;
> Huacai Chen <chenhuacai@...nel.org>; WANG Xuerui <kernel@...0n.name>;
> kasan-dev@...glegroups.com; linux-mm@...ck.org; loongarch@...ts.linux.dev;
> linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v2 2/2] kfence: allow change number of object by early
> parameter
> 
> On Thu, Dec 18, 2025 at 02:39PM +0800, yuan linyu wrote:
> > when want to change the kfence pool size, currently it is not easy and
> > need to compile kernel.
> >
> > Add an early boot parameter kfence.num_objects to allow change kfence
> > objects number and allow increate total pool to provide high failure
> > rate.
> >
> > Signed-off-by: yuan linyu <yuanlinyu@...or.com>
> > ---
> >  include/linux/kfence.h  |   5 +-
> >  mm/kfence/core.c        | 122
> +++++++++++++++++++++++++++++-----------
> >  mm/kfence/kfence.h      |   4 +-
> >  mm/kfence/kfence_test.c |   2 +-
> >  4 files changed, 96 insertions(+), 37 deletions(-)
> >
> > diff --git a/include/linux/kfence.h b/include/linux/kfence.h
> > index 0ad1ddbb8b99..920bcd5649fa 100644
> > --- a/include/linux/kfence.h
> > +++ b/include/linux/kfence.h
> > @@ -24,7 +24,10 @@ extern unsigned long kfence_sample_interval;
> >   * address to metadata indices; effectively, the very first page serves as an
> >   * extended guard page, but otherwise has no special purpose.
> >   */
> > -#define KFENCE_POOL_SIZE ((CONFIG_KFENCE_NUM_OBJECTS + 1) * 2 *
> PAGE_SIZE)
> > +extern unsigned int __kfence_pool_size;
> > +#define KFENCE_POOL_SIZE (__kfence_pool_size)
> > +extern unsigned int __kfence_num_objects;
> > +#define KFENCE_NUM_OBJECTS (__kfence_num_objects)
> >  extern char *__kfence_pool;
> >
> 
> You have ignored the comment below in this file:
> 
> 	/**
> 	 * is_kfence_address() - check if an address belongs to KFENCE pool
> 	 * @addr: address to check
> 	 *
> 	[...]
> 	 * Note: This function may be used in fast-paths, and is performance
> critical.
> 	 * Future changes should take this into account; for instance, we want to
> avoid
>    >>	 * introducing another load and therefore need to keep
> KFENCE_POOL_SIZE a
>    >>	 * constant (until immediate patching support is added to the kernel).
> 	 */
> 	static __always_inline bool is_kfence_address(const void *addr)
> 	{
> 		/*
> 		 * The __kfence_pool != NULL check is required to deal with the case
> 		 * where __kfence_pool == NULL && addr < KFENCE_POOL_SIZE.
> Keep it in
> 		 * the slow-path after the range-check!
> 		 */
> 		return unlikely((unsigned long)((char *)addr - __kfence_pool) <
> KFENCE_POOL_SIZE && __kfence_pool);
> 	}

Do you mean performance critical by access global data ?
It already access __kfence_pool global data.
Add one more global data acceptable here ?

Other place may access global data indeed ?


I don't know if all linux release like ubuntu enable kfence or not.
I only know it turn on default on android device.


> 
> While I think the change itself would be useful to have eventually, a
> better design might be needed. It's unclear to me what the perf impact

Could you share the better design idea ?

> is these days (a lot has changed since that comment was written). Could
> you run some benchmarks to analyze if the fast path is affected by the
> additional load (please do this for whichever arch you care about, but
> also arm64 and x86)?
> 
> If performance is affected, all this could be guarded behind another
> Kconfig option, but it's not great either.

what kind of option ? 
It already have kconfig option to define the number of objects, here just provide
a parameter for the same option which user can change.

> 
> > --
> > 2.25.1