On 2026-04-23 at 18:07:57 +0000, Edgecombe, Rick P wrote: >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?
Yeah, I think this should be the simplest way to not cause any problems. I suppose the returned tag-mask (ARCH_GET_UNTAG_MASK) should also report [60:57] while keeping the current [62:57] in the untag_mask variable? But I'm not sure about keeping the bare numbers, maybe the expected user constants should be as is now in the patchset? LAM_TAG_BITS and LAM_UNTAG_MASK. LAM_TAG_BITS is only used for returning to userspace so no need to change or add anything, for the untag_mask we can leave it as is I think, with ~GENMASK(62, 57). And then we could match these defines in the selftest as is now (naming for easier keeping the values in sync). -- Kind regards Maciej Wieczór-Retman
