On 3/13/22 22:00, Bharata B Rao wrote: > On 3/10/2022 8:46 PM, Dave Hansen wrote:> 1. While Intel LAM provides two LAM widths (15 and 6 bits wide), AMD UAI > has a fixed tag width of 7 bits. This results in following differences > in the implementation: > - Two threadinfo flags (TIF_LAM_57 and TIF_LAM_48) in Intel LAM vs > single flag TIF_TAGGED_ADDR(like in ARM64) in AMD UAI. > - Untagging needs to be aware of 2 widths in Intel LAM as against > a single width in AMD UAI. I'd be perfectly happy with an initial version of this stuff that only comprehends UAI and LAM_57. As long as the ABI can be used for all three cases, adding the two most similar ones initially would make a lot of sense. > - Requirement of making LAM_U48 and mappings above 47bits mutually > exclusive is required for Intel LAM only. > > 2. The enablement bit is part of CR3 in Intel LAM which brings in > additional complexity of updating the CR3 with right LAM mode on every > MM switch and associated tlbstate changes. In AMD UAI, enablement bit > is part of EFER MSR and it is a single time enablement with no MM switch > time changes. Hold on a sec. The context-switching is a *policy*. A _kernel_ policy. If we wanted the LAM settings to be static and system wide, we'd just have a single: if (cpu_feature_enabled(LAM)) cr3 |= LAM_MASK; in build_cr3(). That's not exactly complicated. You know what's a heck of a lot more complicated than that? Adding context-switching for EFER. I can't imagine a world where we want this tagging to be system-wide. There *ARE* going to be apps that break with this pointer tagging stuff. Normal, user apps. Apps in containers. With a system-wide setting, they have zero recourse when things break. All a user can do is reboot the kernel. As-is, it seems like it would be awful to even develop apps that use tagging. You always want to test them with tagging on and off. With this, you need to reboot to test either way. Also, the prctl() in Kirill's version actually enables and disables the hardware feature in addition to the in-kernel tag/untag operations. This series takes the same ABI and doesn't change the hardware feature state. That will need to be rectified at some point. Speaking of which, it's also really worrying that kernel behavior is affected by _EFER_UAI. When tagging is "disabled" in the prctl(), _EFER_UAI is still set. The kernel can go merrily dereferencing both kernel and userspace pointers with no canonical checks. That seems scary. LAM's supervisor separation makes things a lot less scary.
