linux-kernel - Re: [PATCH] mm: thp: Deny THP for guest_memfd and secretmem in file_thp

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: <CAEvNRgGg245-TQn2HFSadZ7gmz-FxsAQ6=N14BUgiYGHhZeLeQ@mail.gmail.com>
Date: Tue, 10 Feb 2026 15:00:44 -0800
From: Ackerley Tng <ackerleytng@...gle.com>
To: "David Hildenbrand (Arm)" <david@...nel.org>, Deepanshu Kartikey <kartikey406@...il.com>
Cc: akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com, 
	baolin.wang@...ux.alibaba.com, Liam.Howlett@...cle.com, npache@...hat.com, 
	ryan.roberts@....com, dev.jain@....com, baohua@...nel.org, seanjc@...gle.com, 
	pbonzini@...hat.com, michael.roth@....com, vannapurve@...gle.com, 
	ziy@...dia.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	syzbot+33a04338019ac7e43a44@...kaller.appspotmail.com
Subject: Re: [PATCH] mm: thp: Deny THP for guest_memfd and secretmem in file_thp_enabled()

"David Hildenbrand (Arm)" <david@...nel.org> writes:

>>> BUT, something just occurred to me.
>>>
>>> We added the mc-handling in
>>>
>>> commit 98c76c9f1ef7599b39bfd4bd99b8a760d4a8cd3b
>>> Author: Jiaqi Yan <jiaqiyan@...gle.com>
>>> Date:   Wed Mar 29 08:11:19 2023 -0700
>>>
>>>       mm/khugepaged: recover from poisoned anonymous memory
>>>
>>> ..
>>>
>>> So I assume kernels before that would crash when collapsing?
>>>
>>> Looking at 5.15.199, it does not contain 98c76c9f1e [1].
>>>
>>> So I suspect we need a fix+stable backport.
>>>
>>> Who volunteers to try a secretmem reproducer on a stable kernel? :)
>>>
>>
>> I could give this a shot. 5.15.199 doesn't have AS_INACCESSIBLE. Should
>> we backport AS_INACCESSIBLE there or could the fix for 5.15.199 just be
>> special-casing secretmem like you suggested below?
>
> Yes. If there is no guest_memfd we wouldn't need it.
>

Seems like on 5.15.199 there's a hugepage_vma_check(), which will return
false since secretmem has vma->vm_ops defined [1], so secretmem VMAs are
skipped.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/mm/khugepaged.c?h=v5.15.199#n469

>>
>>>
>>> The following is a bit nasty as well but should do the trick until we rip
>>> out the CONFIG_READ_ONLY_THP_FOR_FS stuff.
>>>
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index 03886d4ccecc..4ac1cb36b861 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -40,6 +40,7 @@
>>>    #include <linux/pgalloc.h>
>>>    #include <linux/pgalloc_tag.h>
>>>    #include <linux/pagewalk.h>
>>> +#include <linux/secretmem.h>
>>>
>>>    #include <asm/tlb.h>
>>>    #include "internal.h"
>>> @@ -94,6 +95,10 @@ static inline bool file_thp_enabled(struct vm_area_struct *vma)
>>>
>>>           inode = file_inode(vma->vm_file);
>>>
>>> +       if (mapping_inaccessible(inode->i_mapping) ||
>>> +           secretmem_mapping(inode->i_mapping))
>>> +               return false;
>>> +

Regarding checking mapping, is there any chance of racing with inode
release? (Might the mapping be freed?)

>>
>> Regarding the degradation of filesystems that don't support large folios
>> yet: Do you mean having the collapse function respect AS_FOLIO_ORDER_MAX
>> would disable collapsing for filesystems that actually want pages to be
>> collapsed, but don't update max folio order and hence appear to not
>> support large folios yet?
>>
>> What about a check like this instead
>>
>> 	if (!mapping_large_folio_support())
>>          	return false;
>
> That would essentially disable CONFIG_READ_ONLY_THP_FOR_FS (support for
> THP before filesystems started supporting large folios officially), no?
>

I think I get what you mean now. I was thinking to also update the
filesystems to specify AS_FOLIO_ORDER_MAX, but I think that is better
separated out as a different patch series, and this should focus on just
fixing the bug.

> --
> Cheers,
>
> David