linux-kernel - Re: [PATCH] dax/kmem: add build config for protected dax memory blocks

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] [day] [month] [year] [list]

Message-ID: <aXkxUR2By_GQ9Qqn@gourry-fedora-PF4VCD3F>
Date: Tue, 27 Jan 2026 16:42:41 -0500
From: Gregory Price <gourry@...rry.net>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-mm@...ck.org, linux-cxl@...r.kernel.org, nvdimm@...ts.linux.dev,
	linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
	kernel-team@...a.com, dan.j.williams@...el.com,
	vishal.l.verma@...el.com, dave.jiang@...el.com, david@...nel.org,
	mst@...hat.com, jasowang@...hat.com, xuanzhuo@...ux.alibaba.com,
	eperezma@...hat.com, osalvador@...e.de
Subject: Re: [PATCH] dax/kmem: add build config for protected dax memory
 blocks

On Tue, Jan 27, 2026 at 01:34:31PM -0800, Andrew Morton wrote:
> On Wed, 14 Jan 2026 21:42:22 -0500 Gregory Price <gourry@...rry.net> wrote:
> 
> > Since this protection may break userspace tools, it should
> > be an opt-in until those tools have time to update to the
> > new daxN.M/hotplug interface instead of memory blocks.
> > 
> > --- a/drivers/dax/Kconfig
> > +++ b/drivers/dax/Kconfig
> > @@ -78,4 +78,22 @@ config DEV_DAX_KMEM
> >  
> >  	  Say N if unsure.
> >  
> > +config DEV_DAX_KMEM_PROTECTED
> 
> Users must rebuild and redeploy kernels after having updated a
> userspace tool.  They won't thank us for this ;)
> 
> Isn't there something we can do to make this feature
> backward-compatible?
>

This feature is likely getting dropped in favor of pushing such policy
to a driver if it cares that much to prevent users toggling memory
blocks.  

I will likely re-spin this series in a week or so when other non-mm
changes flesh out a little clearer.  This will be removed and some
of the mm/memory-hotplug.c changes will be changed to prevent the
modification of an already extern'd function.

~Gregory