[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1ea18c96-162f-a606-f37b-aaa1bfb2443c@intel.com>
Date: Thu, 4 May 2023 08:25:58 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>,
Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, kirill.shutemov@...ux.intel.com,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [GIT PULL] x86/mm for 6.4
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.
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.
View attachment "lam.patch" of type "text/x-patch" (6944 bytes)
Powered by blists - more mailing lists