Messages in this thread | | | Date | Thu, 4 May 2023 20:10:32 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [GIT PULL] x86/mm for 6.4 |
| |
On Thu, May 04, 2023 at 08:25:58AM -0700, Dave Hansen wrote: > On 5/3/23 23:28, Kirill A. Shutemov wrote: > >> Untagging a kernel address will "corrupt" it, but it will stay a > >> kernel address (well, it will stay a "high bit set" address), which is > >> all we care about anyway. > > The interesting case to consider is untagging kernel pointer when LAM_U48 > > is enabled (not part of current LAM enabling). LAM_U48 would make the > > untagging mask wider -- ~GENMASK(62, 48). With 5-level paging and LAM_SUP > > enabled (also not supported yet) untagging kernel may transform it to > > other valid kernel pointer. > > > > So we cannot rely on #GP as backstop here. The kernel has to exclude > > kernel pointer by other means. It can be fun to debug. > > Yeah, I have the feeling that we're really going to need a pair of > untagging functions once we get to doing kernel LAM for a _bunch_ of > reasons.
There's already arch_kasan_reset_tag() used on ARM64 (and two more helpers to set/get tag). Don't see a reason to add new.
> Just as a practical matter, I think we should OR bits into the mask on > the kernel side, effectively: > > unsigned long untag_kernel_addr(unsigned long addr) > { > return addr | kernel_untag_mask; > } > > and kernel_untag_mask should have bit 63 *clear*. > > That way the pointers that have gone through untagging won't look silly. > If you untag VMALLOC_END or something, it'll still look like the > addresses we have in mm.rst. > > Also, it'll be impossible to have the mask turn a userspace address into > a kernel one. > > Last, we can add some debugging in there, probably conditional on some > mm debugging options like: > > if (WARN_ON_ONCE(!valid_user_address(addr))) > return 0; > > It's kinda like "void __user *" versus "void *". The __user ones can > *absolutely* point anywhere, user or kernel. That's why we can't WARN() > in the untagged_addr() function that takes user pointers. > > But "void *" can only point to the kernel. It has totally different rules. > > We should probably also do something like the attached patch sooner > rather than later. 'untag_mask' really is a misleading name for a mask > that gets applied only to user addresses.
A bit too verbose to my liking, but okay.
Maybe _uaddr() instead of _user_addr()?
-- Kiryl Shutsemau / Kirill A. Shutemov
| |