linux-kernel - Re: Linux 6.18-rc6

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: <5903ee6c-3774-47d6-b14a-51201fd75c0f@kernel.org>
Date: Mon, 17 Nov 2025 20:17:47 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Wang <00107082@....com>, catalin.marinas@....com,
 lance.yang@...ux.dev, b-padhi@...com, akpm@...ux-foundation.org,
 linux-kernel@...r.kernel.org, Jan Polensky <japo@...ux.ibm.com>
Subject: Re: Linux 6.18-rc6

On 17.11.25 19:24, David Hildenbrand (Red Hat) wrote:
> On 17.11.25 18:59, Linus Torvalds wrote:
>> On Mon, 17 Nov 2025 at 09:53, David Hildenbrand (Red Hat)
>> <david@...nel.org> wrote:
>>>
>>> I had the same in mind for a second, but then I looked at
>>> kernel_init_pages() with the kasan_disable_current() handling and
>>> concluded that it's clearer to just disallow tag_clear_highpage() being
>>> abused in the first place and reduce the effective code footprint of
>>> post_alloc_hook().
>>
>> See, I had the exact opposite reaction: I think the one-liner is
>> better not just because it's simpler, but exactly *because* of the
>> mess that is kernel_init_pages().
> 
> Heh, I intuitively avoid runtime checks on the fast paths where avoidable :)
> 
>>
>> IOW, that one-liner is either correct *without* all that crud - and
>> it's unnecessary for the __GFP_ZEROTAGS case because that only happens
>> at init time - or it shows a bug in the arm64 code.
> 
> What sticks out is that we perform the tag_clear_highpage() before we do
> all the KASAN poison magic. And we perform the kernel_init_pages() after
> the kasan magic.
> 
> The clear_highpage() fallback in tag_clear_highpage() was just recently
> added by Catalin (in the same commit we are fixing here IIRC).
> 
> I am no expert on KASAN, but I would suspect that it is important for us
> to clear the pages after doing the
> kasan_unpoison_pages/page_kasan_tag_reset.
> 
> I'll have to dig into the history of tag_clear_highpage() a bit to
> understand how this would interact with non-hw-tag-based KASAN. IIRC,
> amd64 also supports SW-tag KASAN.

So, I briefly tried on x86 with KASAN and the one-liner. I was assuming 
that KASAN would complain because we are clearing the page before doing 
the kasan_unpoison_pages() (IOW, writing to a KASAN-poisoned page).

It didn't trigger, and I assume it is because clear_highpage() on x86 
will not be instrumented by KASAN (my theory).

The comment in kernel_init_pages() indicates that s390x uses memset() 
for that purpose and I would assume that that one would be instrumented.

So I'll give it a try on s390x with KASAN. I should be able to get my 
hands on a system later today.

-- 
Cheers

David