On Fri, 2026-04-10 at 09:55 +0000, Maciej Wieczor-Retman wrote:
>
> #ifdef CONFIG_ADDRESS_MASKING
>
> -#define LAM_U57_BITS 6
> +#define LAM_TAG_BITS 4
> +#define LAM_LS_BIT 57
> +#define LAM_MS_BIT (LAM_LS_BIT + LAM_TAG_BITS - 1) /* 60 */
> +#define LAM_UNTAG_MASK ~GENMASK(LAM_MS_BIT, LAM_LS_BIT)
>
> static void enable_lam_func(void *__mm)
> {
> @@ -814,7 +817,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 = LAM_UNTAG_MASK;
>
It's been a bit since I looked at LAM. The untag_mask is used to strip the
addresses passed by userspace, right? So this lies to userspace about the
tagging behavior of the CPU? Userspace still gets the LAM_U57 behavior, but is
told the untag mask is the 4 chcktag bits?
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.
What is the chktag behavior for bits 61 and 62? Are they ignored or trigger a
#GP?
> /*
> * Even though the process must still be single-threaded at this
> @@ -850,7 +853,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_TAG_BITS) {
> mmap_write_unlock(mm);
