linux-kernel - [PATCH v2 0/4] x86/mm: Some fixes about global ASID allocation

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

Message-Id: <cover.1768900340.git.houwenlong.hwl@antgroup.com>
Date: Tue, 20 Jan 2026 21:44:26 +0800
From: Hou Wenlong <houwenlong.hwl@...group.com>
To: linux-kernel@...r.kernel.org
Cc: Hou Wenlong <houwenlong.hwl@...group.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Andy Lutomirski <luto@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Rik van Riel <riel@...riel.com>
Subject: [PATCH v2 0/4] x86/mm: Some fixes about global ASID allocation

During the backporting of the global ASID allocation, I found some
issues with the ASID range size calculations, and I'm not sure if I
misread them.

Firstly, it's just a mathematical calculation. When we describe a range
[a,b] as a closed interval, the size of the range should be 'b - a + 1'.
As noted in the comment, the range for global ASIDs is [TLB_NR_DYN_SIZE,
MAX_ASID_AVAILABLE-1], and the size of the bitmap is also defined as
'MAX_ASID_AVAILABL', Therefore, the size of the range should be
'MAX_ASID_AVAILABLE - TLB_NR_DYN_SIZE'. However, 'global_asid_available'
is assigned the value of 'MAX_ASID_AVAILABLE - TLB_NR_DYN_SIZE - 1',
which means one ASID will never be allocated.

The macro 'MAX_ASID_AVAILABLE', as I understand it, is used to represent
the maximum valid ASID. Thus the available ASID range described in the
comments is [0,MAX_ASID_AVAILABLE], which is a close interval too. So
the acutal size of the range is 'MAX_ASID_AVAILABLE + 1'. But it is
incorrectly used as the size of the bitmap in global ASID allocation,
leading to the maximum ASID being excluded from global ASID allocation.

As referenced in [1], there is an issue: when a smaller ASID is freed
and last_global_asid is not equal to 'MAX_ASID_AVAILABLE-1', the
allocation will fail because the ASID space cannot be reset. This can be
fixed by resetting the ASID space when an ASID rollover occurs,
regardless of the value of 'last_global_asid'.

Additionally, I found that when PTI is off but
'CONFIG_MITIGATION_PAGE_TABLE_ISOLATION' is enabled (which should be
true for broadcast TLB-capable hardware), only half of the ASID space is
available because 'MAX_ASID_AVAILABLE' is defined as 2046. I have made
some changes to expand the entire ASID space for global ASID allocation
when PTI is off, but I haven't covered this in this patchset. I am
considering whether we can align ASID and PCID to make the code clearer
as Rik said in [0].

Note, I have only conducted some basic tests (running the 4096
tlb_flush2_threads tests to trigger ASID rollover) on the AMD platform.

v1: https://lore.kernel.org/lkml/cover.1743250122.git.houwenlong.hwl@antgroup.com

[0]: https://lore.kernel.org/lkml/df4f0ce855b7acd6fc9777457b89359e075a5cbb.camel@surriel.com

v1 -> v2:
  - Add a new patch to fix the allocation failure.
  - Rewrite the commit message and add Reviwed-by tag.

Hou Wenlong (4):
  x86/mm: Correct the actual size of available global ASID range
  x86/mm: Fix wrong judgement in allocate_global_asid()
  x86/mm: Correct the actual size of ASID range
  x86/mm: Reset global ASID space when ASID rollover

 arch/x86/mm/tlb.c | 25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)

base-commit: d613f96096e48b3646217f006bcccc6ff973c428
--
2.31.1