linux-kernel - Re: [PATCH -tip 1/2] x86/hweight: Fix false output register dependency of POPCNT insn

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: <Z-MlMardXbnknUzS@gmail.com>
Date: Tue, 25 Mar 2025 22:50:41 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Uros Bizjak <ubizjak@...il.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH -tip 1/2] x86/hweight: Fix false output register
 dependency of POPCNT insn

* Uros Bizjak <ubizjak@...il.com> wrote:

> On Sandy/Ivy Bridge and later Intel processors, the POPCNT instruction
> appears to have a false dependency on the destination register. Even
> though the instruction only writes to it, the instruction will wait
> until destination is ready before executing. This false dependency
> was fixed for Cannon Lake (and later) processors.
> 
> Fix false dependency by clearing the destination register first.
> 
> The x86_64 defconfig object size increases by 779 bytes:
> 
> 	    text           data     bss      dec            hex filename
> 	27341418        4643015  814852 32799285        1f47a35 vmlinux-old.o
> 	27342197        4643015  814852 32800064        1f47d40 vmlinux-new.o

I don't think adding an instruction for an old-microarchitecture 
weakness that has been fixed in new hardware already is worth bloating 
the kernel.

Cannon Lake was released in 2018, 7 years ago.

It will be 1-2 years until such a change percolates to Linux users, and 
by that time the microarchitecture with the fix (Cannon Lake) will be a 
decade old, and a majority of Intel CPU users will be using it.

So I don't think this particular change is worth it, unless the false 
dependency can be quantified to have a huge impact on pre-Cannon-Lake 
CPUs - which I don't think it is.

Thanks,

	Ingo