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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <08790cc2-0db4-4920-8331-9061114e8645@kernel.org>
Date: Mon, 17 Nov 2025 19:24:37 +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 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.

> 
> Either way it's a win. Either it's simpler, or it gives us better coverage.
> 
> No?

Staring a bit more at the arm64 fallback in tag_clear_highpage() I agree 
that it might help to find arm64 issues we might run into in the fallback.

But the interaction of KASAN config options are not particularly easy to 
understand -- and if this would actually break non-arm configs. I'll 
have to dig ...

-- 
Cheers

David