Re: [PATCH v6 1/3] x86/process: Shorten the LAM tag width

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Thu, 2026-04-23 at 10:09 +0200, Maciej Wieczor-Retman wrote:
> 
> > If so, then there will be a difference between userspace accesses to a
> > pointer and the kernel's handling of a user pointer (mmap(), gup, etc). I
> > don't know that it is unsafe, but have you thought through the implications?
> > Besides that though it's a weird ABI.
> 

For LAM (forgetting about chktag for a second), I see three things that are
linked today:
1. What gets communicated to userspace about which bits will actually be ignored
2. What bits the HW actually will ignore.
3. Which bits that the kernel will strip in all of the places where it processes
   userspace addresses.

Yea, I guess I think they should stay linked.

If 1 doesn't match 2, userspace will have trouble understanding what is going
on. GDB, etc will not be able to make sense of things.

If 2 doesn't match 3, that is what I was calling the weird ABI. I don't know
about security issues, but it seems confusing to keep track of at least too, for
the purpose of making sure the wrong memory doesn't get accesses.

> Do you think leaving the untag_mask as it was (bits 62:57) while advertising
> that 4 bits are available would be better? The untag_mask would be more inline
> with what the hardware is doing currently while ABI would promise to long term
> only stick by the 4-bit tags.

Some properly coded thing that does this?

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 08e72f4298701..a01f935872348 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -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(4, (unsigned long __user *)arg2);
 #endif
        case ARCH_SHSTK_ENABLE:
        case ARCH_SHSTK_DISABLE:

I think it meets my (suggested) goals above. It is weird to hear that the max is
4, and then ask for 4 and get 6. But I guess it's not going to break anything?