From nobody Thu Apr 9 15:03:55 2026 Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch [79.135.106.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C5083FFABF for ; Mon, 2 Mar 2026 15:34:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.29 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772465698; cv=none; b=NsSJD7G5hYx+aQBjQ+QhRHmzAStTTAWftVfz0HBgVGdwO4qGb1Ssv2qDZDV13k8jDU3aqCJGgXV1gJVSEczUj9YbrxXUXxiai6GVZ77oUFVu6oMUffeLOo0suFO/XkPAwzie/iSoWXRGdnpf2Cm46LUZJz7C1ocg7ki3jGxZx1M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772465698; c=relaxed/simple; bh=/P7eSs/YI9GuU2GxaO6McGC5VGXAwnW6Pa3DHc+GVjM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ef5DZjk+V0QrZfT6ml6vq7zoDPhaG3Cw5q68eX8rDn/C39OD2HhefTrQo1ZPjm76FyCokU1giZpjD3pHUZNaLRURoMEvFtV5sZEwxlOXcZdq91Yn8akUQdVEpcl9UcMcYwjOiEIjCCOxk2FdM0QDVNShjB1AF4k+bbpQEAN3Zbk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=HWlDTa1F; arc=none smtp.client-ip=79.135.106.29 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="HWlDTa1F" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1772465695; x=1772724895; bh=ZlcZz7fdQsm7Q8War/X6oCltG7oGV69i06GCdcnX4cQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=HWlDTa1F9pscxhPPkV58if4oWOzs5celCny+Xd3YOiuEAY9W6iX5rDie24SWTJ5Wt RGuyArvZsk6aqLH7N3dl138HcPxqtc/OcKJIWXeJS00QQnJE0U8T6QLeU0AwygGxIP wRwd7ye/NGO/qJ9a05vxR+fjIFc+v9sl7KN2P616F6bB6oErHUfhm4he/IMo8JFDrR Oc1iyam/HMTn/Ob2EGwszFAePaR1I1VHhsgtiez31V+cgUsLEWuui6VDYVViJq6g0Z jUlM/Y+bSSbeWgNRhMT+qOqVSHMJFu9a5dgVkHmkSy9+5C+ehK4WeR8/kCFW8z0KRb UPNJv6/bHr/KA== Date: Mon, 02 Mar 2026 15:34:51 +0000 To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" From: Maciej Wieczor-Retman Cc: m.wieczorretman@pm.me, Maciej Wieczor-Retman , linux-kernel@vger.kernel.org Subject: [PATCH v3 1/3] x86/process: Shorten the default LAM tag width Message-ID: <324da30e8b32576b9a05b3969f6d6a49a4153ba2.1772465456.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: c438c750f29ca643cdf7b63b7362a62d44628d28 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman With the announcement of ChkTag, it's worth preparing a stable x86 linear address masking (lam) user interface. One important aspect of lam is the tag width, and aligning it with other industry solutions can provide a more popular, generalized interface that other technologies could utilize. ChkTag will use 4-bit tags and since that's the direction other memory tagging implementations seem to be taking too (for example Arm's MTE) it's reasonable to converge lam in linux to the same specification. Even though x86's LAM supports 6-bit tags it is beneficial to default lam to 4 bits as ChkTag will likely be the main user of the interface and such connection should simplify things in the future. Signed-off-by: Maciej Wieczor-Retman --- Changelog v3: - Remove the variability of the lam width after the debugfs part was removed from the patchset. arch/x86/kernel/process_64.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 08e72f429870..1a0e96835bbc 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -797,7 +797,7 @@ static long prctl_map_vdso(const struct vdso_image *ima= ge, unsigned long addr) =20 #ifdef CONFIG_ADDRESS_MASKING =20 -#define LAM_U57_BITS 6 +#define LAM_DEFAULT_BITS 4 =20 static void enable_lam_func(void *__mm) { @@ -814,7 +814,7 @@ static void enable_lam_func(void *__mm) static void mm_enable_lam(struct mm_struct *mm) { mm->context.lam_cr3_mask =3D X86_CR3_LAM_U57; - mm->context.untag_mask =3D ~GENMASK(62, 57); + mm->context.untag_mask =3D ~GENMASK(57 + LAM_DEFAULT_BITS - 1, 57); =20 /* * Even though the process must still be single-threaded at this @@ -850,7 +850,7 @@ static int prctl_enable_tagged_addr(struct mm_struct *m= m, unsigned long nr_bits) return -EBUSY; } =20 - if (!nr_bits || nr_bits > LAM_U57_BITS) { + if (!nr_bits || nr_bits > LAM_DEFAULT_BITS) { mmap_write_unlock(mm); return -EINVAL; } @@ -965,7 +965,7 @@ long do_arch_prctl_64(struct task_struct *task, int opt= ion, unsigned long arg2) if (!cpu_feature_enabled(X86_FEATURE_LAM)) return put_user(0, (unsigned long __user *)arg2); else - return put_user(LAM_U57_BITS, (unsigned long __user *)arg2); + return put_user(LAM_DEFAULT_BITS, (unsigned long __user *)arg2); #endif case ARCH_SHSTK_ENABLE: case ARCH_SHSTK_DISABLE: --=20 2.53.0