linux-kernel - Re: [PATCH 2/3] x86/mm: Fix early boot use of INVPLGB

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: <3ab0fc2b-646e-4413-a485-cb9373f8b9d5@intel.com>
Date: Mon, 2 Jun 2025 10:21:53 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Rik van Riel <riel@...riel.com>, linux-kernel@...r.kernel.org
Cc: kernel-team@...a.com, dave.hansen@...ux.intel.com, luto@...nel.org,
 peterz@...radead.org, bp@...en8.de, x86@...nel.org, yu-cheng.yu@...el.com,
 stable@...nel.org
Subject: Re: [PATCH 2/3] x86/mm: Fix early boot use of INVPLGB

On 6/2/25 06:30, Rik van Riel wrote:
> Use of the INVLPGB instruction is done based off the X86_FEATURE_INVLPGB
> CPU feature, which is provided directly by the hardware.
> 
> If invlpgb_kernel_range_flush is called before the kernel has read
> the value of invlpgb_count_max from the hardware, the normally
> bounded loop can become an infinite loop if invlpgb_count_max is
> initialized to zero.
> 
> Fix that issue by initializing invlpgb_count_max to 1.
> 
> This way INVPLGB at early boot time will be a little bit slower
> than normal (with initialized invplgb_count_max), and not an
> instant hang at bootup time.

The INVLPGB instruction has limits on how many invalidations it can
perform at once. That limit is enumerated in CPUID, read by the kernel,
and stored in 'invlpgb_count_max'. Ranged invalidation (like
invlpgb_kernel_range_flush()) break up their invalidations so that they
do not exceed the limit.

However, early boot code currently attempts to do ranged invalidations
before populating 'invlpgb_count_max'. There's a for() loop which is
basically:

	for (...; addr < end; addr += invlpgb_count_max*PAGE_SIZE)

It doesn't make much progress when invlpgb_count_max==0.

... then the rest

---

BTW, how was this code even _working_ without this patch? Are the early
boot ranged invalidations infrequent or something?

Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>