From: Maciej Wieczor-Retman <m.wieczorretman@pm.me>
To: david.laight.linux@gmail.com, riel@surriel.com,
perry.yuan@amd.com, jgross@suse.com, ljs@kernel.org,
justinstitt@google.com, hpa@zytor.com, shuah@kernel.org,
nathan@kernel.org, sohil.mehta@intel.com,
mathieu.desnoyers@efficios.com, brauner@kernel.org,
ethantidmore06@gmail.com, dave.hansen@linux.intel.com,
maciej.wieczor-retman@intel.com, mingo@redhat.com, bp@alien8.de,
akpm@linux-foundation.org, peterz@infradead.org,
viro@zeniv.linux.org.uk, superman.xpt@gmail.com,
rdunlap@infradead.org, aliceryhl@google.com,
ilpo.jarvinen@linux.intel.com, david@kernel.org, xin@zytor.com,
seanjc@google.com, tglx@kernel.org, houwenlong.hwl@antgroup.com,
yury.norov@gmail.com, rppt@kernel.org, oleg@redhat.com,
nick.desaulniers+lkml@gmail.com, vmalik@redhat.com,
morbo@google.com, ryan.roberts@arm.com, kees@kernel.org
Cc: linux-kselftest@vger.kernel.org, linux-fsdevel@vger.kernel.org,
x86@kernel.org, llvm@lists.linux.dev,
linux-kernel@vger.kernel.org, m.wieczorretman@pm.me
Subject: [PATCH v7 0/4] x86: Simplifying LAM
Date: Wed, 29 Apr 2026 14:05:48 +0000 [thread overview]
Message-ID: <cover.1777470980.git.m.wieczorretman@pm.me> (raw)
After ChkTag [1] announcement, 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 shorten lam to
4 bits as ChkTag will likely be the main user of the interface and such
connection should simplify things in the long run.
Change in the interface tries to cover the three following aspects:
- Have the kernel use the same tag width as the underlying
hardware does. This should ensure consistent treatment of user
pointers across various user/kernel interfaces.
- Present the user with a stable tag width value not dependent
on the maximum capabilities of the hardware used. This should
prevent any backward capability issues in case there are any
hardware changes in the future.
- Export the hardware tag width through procfs for programs that
need to recreate kernel's treatment of user pointers
accurately such as gdb.
Changing the tag width at the moment has no effect on userspace
programs. Due to LAM being disabled until LASS is fully supported in the
kernel there are yet no userspace projects relying on a specific LAM tag
width. One known exception is the clang compiler and its hwasan support.
It is however not a problem since there are both no users of hwasan on
x86 yet and upon closer inspection (when working on x86 KASAN software
tag-based mode) I found it's not working correctly and needs to be
patched.
The patchset also cleans up some comments referencing LAM_U48 which was
not implemented in the kernel and the comments shouldn't imply it can be
enabled.
Patches are based on v7.1-rc1
Changelog v7:
- Redid quite a bit after Rick Edgecombe pointing out the inconsistent
treatment of user pointers internally.
- Cover letter:
- Added the third paragraph to the cover letter summarizing expected
results of the interface changes.
- 1/4:
- Redid the untag mask handling and syscall return. Updated last
paragraph of the patch message.
- 2/4:
- Added a procfs patch to help make gdb like programs work with
LAM.
- 3/4:
- No changes
- 4/4:
- Made the selftest constants analogous to the kernel ones.
Changelog v6:
- 1/3
- Change define names so they match the arch_prctl() cases for
LAM.
- Add more defines so they build into the GENMASK() more
properly.
- 2/3
- Add one reviewed-by.
- 3/3
- Update the patch subject after removing additional test cases
during v3.
- Change bit width and untag mask defines so they match the
kernel ones in name and add GENMASK() to x86 selftests so
they match the kernel in form. Update the patch description.
Changelog v5:
- Rebase onto v7.0-rc7.
Changelog v4:
- Remove the 'default' wording from the cover letter and patch messages.
- Add a paragraph to the cover letter about userspace impact.
Changelog v3:
- Remove the debugfs part and update the rest of the code and patch
messages accordingly.
Changelog v2:
- Extend a char buffer in debugfs read callback to fit the format
string.
[1] https://community.intel.com/t5/Blogs/Tech-Innovation/open-intel/ChkTag-x86-Memory-Safety/post/1721490
Maciej Wieczor-Retman (4):
x86/process: Shorten the LAM tag width
x86/process: Add a procfs file with hardware address masking
x86/mm: Cleanup comments where LAM_U48 is mentioned
selftests/lam: Update LAM tag width and cleanup names
arch/x86/Kconfig | 1 +
arch/x86/include/asm/mmu.h | 2 +-
arch/x86/include/asm/tlbflush.h | 2 +-
arch/x86/kernel/process_64.c | 30 ++++++++--
fs/proc/Kconfig | 4 ++
fs/proc/base.c | 6 ++
include/linux/uaccess.h | 5 ++
tools/testing/selftests/x86/lam.c | 94 ++++++++++++++++---------------
8 files changed, 92 insertions(+), 52 deletions(-)
--
2.53.0
next reply other threads:[~2026-04-29 14:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 14:05 Maciej Wieczor-Retman [this message]
2026-04-29 14:06 ` [PATCH v7 1/4] x86/process: Shorten the LAM tag width Maciej Wieczor-Retman
2026-04-29 14:06 ` [PATCH v7 2/4] x86/process: Add a procfs file with hardware address masking Maciej Wieczor-Retman
2026-04-29 14:06 ` [PATCH v7 3/4] x86/mm: Cleanup comments where LAM_U48 is mentioned Maciej Wieczor-Retman
2026-04-29 14:06 ` [PATCH v7 4/4] selftests/lam: Update LAM tag width and cleanup names Maciej Wieczor-Retman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1777470980.git.m.wieczorretman@pm.me \
--to=m.wieczorretman@pm.me \
--cc=akpm@linux-foundation.org \
--cc=aliceryhl@google.com \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=david.laight.linux@gmail.com \
--cc=david@kernel.org \
--cc=ethantidmore06@gmail.com \
--cc=houwenlong.hwl@antgroup.com \
--cc=hpa@zytor.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jgross@suse.com \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=llvm@lists.linux.dev \
--cc=maciej.wieczor-retman@intel.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=oleg@redhat.com \
--cc=perry.yuan@amd.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
--cc=sohil.mehta@intel.com \
--cc=superman.xpt@gmail.com \
--cc=tglx@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vmalik@redhat.com \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox