linux-kernel - Re: [RFC PATCH v2 2/4] percpu: Assorted fixes found by strict percpu address space checks

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: <2EF46123-30B0-4A7E-9414-EE25CBCF255E@gmail.com>
Date: Mon, 12 Aug 2024 22:09:01 +0300
From: Nadav Amit <nadav.amit@...il.com>
To: Uros Bizjak <ubizjak@...il.com>
Cc: "open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Dennis Zhou <dennis@...nel.org>,
 Tejun Heo <tj@...nel.org>,
 Christoph Lameter <cl@...ux.com>,
 Andy Lutomirski <luto@...nel.org>,
 Ingo Molnar <mingo@...nel.org>,
 Brian Gerst <brgerst@...il.com>,
 Denys Vlasenko <dvlasenk@...hat.com>,
 "H. Peter Anvin" <hpa@...or.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Peter Zijlstra <peterz@...radead.org>,
 Thomas Gleixner <tglx@...utronix.de>,
 Borislav Petkov <bp@...en8.de>,
 Luc Van Oostenryck <luc.vanoostenryck@...il.com>
Subject: Re: [RFC PATCH v2 2/4] percpu: Assorted fixes found by strict percpu
 address space checks

> On 12 Aug 2024, at 14:57, Uros Bizjak <ubizjak@...il.com> wrote:
> Assorted fixes to prevent defconfig build failures when
> strict percpu address space checks will be enabled.
> 
> These show effeciveness of strict percpu address space checks.

[snip]

> --- a/drivers/base/devres.c
> +++ b/drivers/base/devres.c
> @@ -1231,6 +1231,6 @@ void devm_free_percpu(struct device *dev, void __percpu *pdata)
> 	 * devm_free_pages() does.
> 	 */
> 	WARN_ON(devres_release(dev, devm_percpu_release, devm_percpu_match,
> -			       (__force void *)pdata));
> +			       (__force void *)(uintptr_t)pdata));
> 

Since this pattern of casting appears multiple times (sometimes slightly
different), I think it would be best to give a name for this operation
and put it behind a macro.

This would allow both to audit the cases developers move data between
address-spaces, and also make them think whether what they do makes
sense.