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.
>What is the chktag behavior for bits 61 and 62? Are they ignored or trigger a
>#GP?
In ChkTag? I don't think the full specification is out yet so I'm not sure. In
current LAM they are ignored.
>> /*
>> * 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);
>
--
Kind regards
Maciej Wieczór-Retman
