__GFP_SENSITIVE represents that a page should not be mapped into the
ASI restricted address space.
This is added as a GFP flag instead of via some contextual hint, because
its presence is not ultimately expected to correspond to any such
existing context. If necessary, it should be possible to instead achieve
this optionality with something like __alloc_pages_sensitive(), but
this would be much more invasive to the overall kernel.
On startup, all pages are sensitive. Since there is currently no way to
create nonsensitive pages, temporarily set the flag unconditionally at
the top of the allocator.
__GFP_SENSITIVE is also added to GFP_USER since that's the most
important data that ASI needs to protect.
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
include/linux/gfp_types.h | 15 ++++++++++++++-
include/trace/events/mmflags.h | 1 +
mm/page_alloc.c | 7 +++++++
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
index 65db9349f9053c701e24bdcf1dfe6afbf1278a2d..5147dbd53eafdccc32cfd506569b04d5c082d1b2 100644
--- a/include/linux/gfp_types.h
+++ b/include/linux/gfp_types.h
@@ -58,6 +58,7 @@ enum {
#ifdef CONFIG_SLAB_OBJ_EXT
___GFP_NO_OBJ_EXT_BIT,
#endif
+ ___GFP_SENSITIVE_BIT,
___GFP_LAST_BIT
};
@@ -103,6 +104,11 @@ enum {
#else
#define ___GFP_NO_OBJ_EXT 0
#endif
+#ifdef CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION
+#define ___GFP_SENSITIVE BIT(___GFP_SENSITIVE_BIT)
+#else
+#define ___GFP_SENSITIVE 0
+#endif
/*
* Physical address zone modifiers (see linux/mmzone.h - low four bits)
@@ -299,6 +305,12 @@ enum {
/* Disable lockdep for GFP context tracking */
#define __GFP_NOLOCKDEP ((__force gfp_t)___GFP_NOLOCKDEP)
+/*
+ * Allocate sensitive memory, i.e. do not map it into ASI's restricted address
+ * space.
+ */
+#define __GFP_SENSITIVE ((__force gfp_t)___GFP_SENSITIVE)
+
/* Room for N __GFP_FOO bits */
#define __GFP_BITS_SHIFT ___GFP_LAST_BIT
#define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))
@@ -380,7 +392,8 @@ enum {
#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM | __GFP_NOWARN)
#define GFP_NOIO (__GFP_RECLAIM)
#define GFP_NOFS (__GFP_RECLAIM | __GFP_IO)
-#define GFP_USER (__GFP_RECLAIM | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
+#define GFP_USER (__GFP_RECLAIM | __GFP_IO | __GFP_FS | \
+ __GFP_HARDWALL | __GFP_SENSITIVE)
#define GFP_DMA __GFP_DMA
#define GFP_DMA32 __GFP_DMA32
#define GFP_HIGHUSER (GFP_USER | __GFP_HIGHMEM)
diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
index aa441f593e9a6b537d02189add91eb77bebc6a97..425385b7f073d05e9d660ad19cb7497f045adfb7 100644
--- a/include/trace/events/mmflags.h
+++ b/include/trace/events/mmflags.h
@@ -100,6 +100,7 @@ TRACE_DEFINE_ENUM(___GFP_LAST_BIT);
gfpflag_string(GFP_DMA), \
gfpflag_string(GFP_DMA32), \
gfpflag_string(__GFP_RECLAIM), \
+ gfpflag_string(__GFP_SENSITIVE), \
TRACE_GFP_FLAGS \
{ 0, NULL }
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 600d9e981c23d75fdd4aec118e34f3f49d3de2e0..0d1c28decd57b4a5e250acc0efc41669b7f67f5b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5152,6 +5152,13 @@ struct page *__alloc_frozen_pages_noprof(gfp_t gfp, unsigned int order,
gfp_t alloc_gfp; /* The gfp_t that was actually used for allocation */
struct alloc_context ac = { };
+ /*
+ * Temporary hack: Allocation of nonsensitive pages is not possible yet,
+ * allocate everything sensitive. The restricted address space is never
+ * actually entered yet so this is fine.
+ */
+ gfp |= __GFP_SENSITIVE;
+
/*
* There are several places where we assume that the order value is sane
* so bail out early if the request is out of bound.
--
2.50.1On 9/24/25 07:59, Brendan Jackman wrote: > +#ifdef CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION > +#define ___GFP_SENSITIVE BIT(___GFP_SENSITIVE_BIT) > +#else > +#define ___GFP_SENSITIVE 0 > +#endif This is clearly one of the inflection points of the series. To go any farther with this approach, I think it's critical to get a few acks on this hunk specifically. Well, maybe not formal acked-by's, but at least _clear_ agreement from at least one of: MEMORY MANAGEMENT - PAGE ALLOCATOR M: Andrew Morton <akpm@linux-foundation.org> M: Vlastimil Babka <vbabka@suse.cz> ... or this approach is dead in the water.
On Wed Oct 1, 2025 at 9:18 PM UTC, Dave Hansen wrote: > On 9/24/25 07:59, Brendan Jackman wrote: >> +#ifdef CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION >> +#define ___GFP_SENSITIVE BIT(___GFP_SENSITIVE_BIT) >> +#else >> +#define ___GFP_SENSITIVE 0 >> +#endif > > This is clearly one of the inflection points of the series. > > To go any farther with this approach, I think it's critical to get a few > acks on this hunk specifically. Well, maybe not formal acked-by's, but > at least _clear_ agreement from at least one of: > > MEMORY MANAGEMENT - PAGE ALLOCATOR > M: Andrew Morton <akpm@linux-foundation.org> > M: Vlastimil Babka <vbabka@suse.cz> > > ... or this approach is dead in the water. Yep, I agree. This is where the chicken-and-egg thing I mentioned in [0] comes into play though... [0] https://lore.kernel.org/all/DD7SCRK2OJI9.1EJ9GSEH9FHW2@google.com/
On Thu, Oct 02, 2025 at 02:34:33PM +0000, Brendan Jackman wrote:
> On Wed Oct 1, 2025 at 9:18 PM UTC, Dave Hansen wrote:
> > On 9/24/25 07:59, Brendan Jackman wrote:
> >> +#ifdef CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION
> >> +#define ___GFP_SENSITIVE BIT(___GFP_SENSITIVE_BIT)
> >> +#else
> >> +#define ___GFP_SENSITIVE 0
> >> +#endif
> >
> > This is clearly one of the inflection points of the series.
> >
> > To go any farther with this approach, I think it's critical to get a few
> > acks on this hunk specifically. Well, maybe not formal acked-by's, but
> > at least _clear_ agreement from at least one of:
> >
> > MEMORY MANAGEMENT - PAGE ALLOCATOR
> > M: Andrew Morton <akpm@linux-foundation.org>
> > M: Vlastimil Babka <vbabka@suse.cz>
> >
> > ... or this approach is dead in the water.
>
> Yep, I agree. This is where the chicken-and-egg thing I mentioned in [0]
> comes into play though...
>
> [0] https://lore.kernel.org/all/DD7SCRK2OJI9.1EJ9GSEH9FHW2@google.com/
Btw:
./include/linux/sockptr.h: In function ‘memdup_sockptr_noprof’:
./include/linux/gfp_types.h:306:41: error: ‘___GFP_SENSITIVE’ undeclared (first use in this function); did you mean ‘___GFP_SENSITIVE_BIT’?
306 | #define __GFP_SENSITIVE ((__force gfp_t)___GFP_SENSITIVE)
| ^~~~~~~~~~~~~~~~
./include/linux/slab.h:1049:76: note: in definition of macro ‘kmalloc_node_track_caller_noprof’
1049 | __kmalloc_node_track_caller_noprof(PASS_BUCKET_PARAMS(size, NULL), flags, node, caller)
| ^~~~~
./include/linux/sockptr.h:126:19: note: in expansion of macro ‘kmalloc_track_caller_noprof’
126 | void *p = kmalloc_track_caller_noprof(len, GFP_USER | __GFP_NOWARN);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/gfp_types.h:390:43: note: in expansion of macro ‘__GFP_SENSITIVE’
390 | __GFP_HARDWALL | __GFP_SENSITIVE)
| ^~~~~~~~~~~~~~~
./include/linux/sockptr.h:126:52: note: in expansion of macro ‘GFP_USER’
126 | void *p = kmalloc_track_caller_noprof(len, GFP_USER | __GFP_NOWARN);
| ^~~~~~~~
Perhaps it is time for a refresh and a new submission huh?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed Jan 28, 2026 at 3:38 PM UTC, Borislav Petkov wrote: > On Thu, Oct 02, 2025 at 02:34:33PM +0000, Brendan Jackman wrote: >> On Wed Oct 1, 2025 at 9:18 PM UTC, Dave Hansen wrote: >> > On 9/24/25 07:59, Brendan Jackman wrote: >> >> +#ifdef CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION >> >> +#define ___GFP_SENSITIVE BIT(___GFP_SENSITIVE_BIT) >> >> +#else >> >> +#define ___GFP_SENSITIVE 0 >> >> +#endif >> > >> > This is clearly one of the inflection points of the series. >> > >> > To go any farther with this approach, I think it's critical to get a few >> > acks on this hunk specifically. Well, maybe not formal acked-by's, but >> > at least _clear_ agreement from at least one of: >> > >> > MEMORY MANAGEMENT - PAGE ALLOCATOR >> > M: Andrew Morton <akpm@linux-foundation.org> >> > M: Vlastimil Babka <vbabka@suse.cz> >> > >> > ... or this approach is dead in the water. >> >> Yep, I agree. This is where the chicken-and-egg thing I mentioned in [0] >> comes into play though... >> >> [0] https://lore.kernel.org/all/DD7SCRK2OJI9.1EJ9GSEH9FHW2@google.com/ > > Btw: > > ./include/linux/sockptr.h: In function ‘memdup_sockptr_noprof’: > ./include/linux/gfp_types.h:306:41: error: ‘___GFP_SENSITIVE’ undeclared (first use in this function); did you mean ‘___GFP_SENSITIVE_BIT’? > 306 | #define __GFP_SENSITIVE ((__force gfp_t)___GFP_SENSITIVE) > | ^~~~~~~~~~~~~~~~ > ./include/linux/slab.h:1049:76: note: in definition of macro ‘kmalloc_node_track_caller_noprof’ > 1049 | __kmalloc_node_track_caller_noprof(PASS_BUCKET_PARAMS(size, NULL), flags, node, caller) > | ^~~~~ > ./include/linux/sockptr.h:126:19: note: in expansion of macro ‘kmalloc_track_caller_noprof’ > 126 | void *p = kmalloc_track_caller_noprof(len, GFP_USER | __GFP_NOWARN); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > ./include/linux/gfp_types.h:390:43: note: in expansion of macro ‘__GFP_SENSITIVE’ > 390 | __GFP_HARDWALL | __GFP_SENSITIVE) > | ^~~~~~~~~~~~~~~ > ./include/linux/sockptr.h:126:52: note: in expansion of macro ‘GFP_USER’ > 126 | void *p = kmalloc_track_caller_noprof(len, GFP_USER | __GFP_NOWARN); > | ^~~~~~~~ > > Perhaps it is time for a refresh and a new submission huh? Yeah, that time has long since passed, I'm sorry about the delay! I'm working on it as we speak. The submission I've been trying to post for the last few week is to add a __GFP_UNMAPPED flag. That will unblock the guest_memfd unmapped usecase. I got some design elements wrong and had to reimplement some stuff during January (I had an AI review my code and it pointed out that part of my pagetable management code was garbage. Spooky). Now I'm working on integrating the new version with the guest_memfd features to make sure it's actually fast (it's quite complicated so it had better be useful). Once that's done I'll hopefully be ready to post.... _THEN_ I can update the __GFP_SENSITIVE functionality on top of the __GFP_UNMAPPED functionality. The former means "don't map into ASI" and the latter means "don't map at all" so they overlap in terms of allocator stuff.l
On Wed, Jan 28, 2026 at 03:57:07PM +0000, Brendan Jackman wrote:
> Yeah, that time has long since passed, I'm sorry about the delay!
Nothing to be sorry for.
> I'm working on it as we speak. The submission I've been trying to
> post for the last few week is to add a __GFP_UNMAPPED flag. That will
> unblock the guest_memfd unmapped usecase.
>
> I got some design elements wrong and had to reimplement some stuff
> during January (I had an AI review my code and it pointed out that
> part of my pagetable management code was garbage. Spooky).
Did it say "garbage"? If so, yeah, you're using the lkml review profile :-P
> Now I'm working on integrating the new version with the guest_memfd features
> to make sure it's actually fast (it's quite complicated so it had better be
> useful). Once that's done I'll hopefully be ready to post....
>
> _THEN_ I can update the __GFP_SENSITIVE functionality on top of the
> __GFP_UNMAPPED functionality. The former means "don't map into ASI" and the
> latter means "don't map at all" so they overlap in terms of allocator
> stuff.l
Sounds good.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
© 2016 - 2026 Red Hat, Inc.