linux-kernel - Re: [PATCH] lib/raid6: Replace custom zero page with ZERO

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

Message-Id: <20250315233329.0b42e28a9f11e2c1b8b17ea0@linux-foundation.org>
Date: Sat, 15 Mar 2025 23:33:29 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Song Liu
 <song@...nel.org>, Yu Kuai <yukuai3@...wei.com>, linux-raid@...r.kernel.org
Subject: Re: [PATCH] lib/raid6: Replace custom zero page with ZERO_PAGE

On Sun, 16 Mar 2025 13:51:50 +0800 Herbert Xu <herbert@...dor.apana.org.au> wrote:

> > Is there any possibility that the MD drivers will point DMA hardware at
> > the global zero page, thereby invalidating that page from CPU caches in
> > some manner?
> 
> The only spots that can hand this off to DMA are:

Cool, thanks for checking.

> crypto/async_tx/async_pq.c:                     srcs[i] = (void*)raid6_empty_zero_page;
> crypto/async_tx/async_raid6_recov.c:                            ptrs[i] = (void *) raid6_empty_zero_page;
> crypto/async_tx/async_raid6_recov.c:                            ptrs[i] = (void*)raid6_empty_zero_page;
> 
> But they all turn out to be synchronous fallback code paths that
> do not involve DMA at all.

And all three cast a pointer to a void* ;)