On 2026-04-23 at 10:09:03 +0200, Maciej Wieczor-Retman wrote:
>On 2026-04-22 at 18:07:29 +0000, Edgecombe, Rick P wrote:
>>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?
>
>Yes, the intention being that hardware might move from using the 6-bit tag
>width
>at some point in favor of the 4-bit one. So the user can safely expect the
>4-bit
>tags to work.
>
>>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.
>
>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.
One other thing I was thinking we could do already is changing the LAM version
of USER_PTR_MAX (that's for now commented out) so it also takes into account 4
bits instead of 6:
if (cpu_feature_enabled(X86_FEATURE_LAM))
USER_PTR_MAX = (-1UL >> 3) & PAGE_MASK;
I recall mmap and gup call access_ok() at some point in their operation which
uses USER_PTR_MAX. So that could take care of bits 62 and 61 if anyone tried
setting them against what the ABI specifies.
--
Kind regards
Maciej Wieczór-Retman
