From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
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 <maciej.wieczor-retman@intel.com>
---
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 *image, unsigned long addr)
#ifdef CONFIG_ADDRESS_MASKING
-#define LAM_U57_BITS 6
+#define LAM_DEFAULT_BITS 4
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 = X86_CR3_LAM_U57;
- mm->context.untag_mask = ~GENMASK(62, 57);
+ mm->context.untag_mask = ~GENMASK(57 + LAM_DEFAULT_BITS - 1, 57);
/*
* Even though the process must still be single-threaded at this
@@ -850,7 +850,7 @@ static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits)
return -EBUSY;
}
- 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 option, 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:
--
2.53.0
On 2.03.26 г. 17:34 ч., Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>
> 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 <maciej.wieczor-retman@intel.com>
> ---
> 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 *image, unsigned long addr)
>
> #ifdef CONFIG_ADDRESS_MASKING
>
> -#define LAM_U57_BITS 6
> +#define LAM_DEFAULT_BITS 4
If this is getting standartized across architectures shouldn't there be
some shared header file which contains arch-agnostic definitions, which
could then be used by the arch-specific code?
>
> 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 = X86_CR3_LAM_U57;
> - mm->context.untag_mask = ~GENMASK(62, 57);
> + mm->context.untag_mask = ~GENMASK(57 + LAM_DEFAULT_BITS - 1, 57);
>
> /*
> * Even though the process must still be single-threaded at this
> @@ -850,7 +850,7 @@ static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits)
> return -EBUSY;
> }
>
> - 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 option, 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:
On 2026-03-06 at 18:58:31 +0200, Nikolay Borisov wrote: > > >On 2.03.26 г. 17:34 ч., Maciej Wieczor-Retman wrote: >> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com> >> >> 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 <maciej.wieczor-retman@intel.com> >> --- >> 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 *image, unsigned long addr) >> >> #ifdef CONFIG_ADDRESS_MASKING >> >> -#define LAM_U57_BITS 6 >> +#define LAM_DEFAULT_BITS 4 > >If this is getting standartized across architectures shouldn't there be >some shared header file which contains arch-agnostic definitions, which >could then be used by the arch-specific code? I think this patchset should mostly just clarify the intentions, make specifically x86's LAM 4-bit so any users that might appear in the near future are used to this width and not the bigger one. On across arch level I'd say right now it's about x86 preparing ground to have some common features of address masking with other architectures that seem to follow the 4-bit width notion. For now I recall only MTE using 4-bit tags in cooperation with TBI but I'm not yet sure if it has any value to take the tag width out of arch code for these two use cases. I'm working on a KASAN series for x86 in parallel for some time and maybe if/once that's merged it would make sense to generalize some constants/functions. -- Kind regards Maciej Wieczór-Retman
On 3/2/26 07:34, Maciej Wieczor-Retman wrote: > 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. The "default" naming in here doesn't make a whole lot of sense now that it's static. The changelog also needs a few things: first, it needs to talk about what this does to existing userspace. Second, it needs an imperative: Shrink the maximum acceptable tag width from 6 to 4. But otherwise, this looks fine to me.
On 2026-03-04 at 12:08:14 -0800, Dave Hansen wrote: >On 3/2/26 07:34, Maciej Wieczor-Retman wrote: >> 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. > >The "default" naming in here doesn't make a whole lot of sense now that >it's static. > >The changelog also needs a few things: first, it needs to talk about >what this does to existing userspace. Second, it needs an imperative: > > Shrink the maximum acceptable tag width from 6 to 4. > >But otherwise, this looks fine to me. Thanks, I'll apply these things to the patchset. -- Kind regards Maciej Wieczór-Retman
© 2016 - 2026 Red Hat, Inc.