Re: [GIT PULL] x86/mm for 6.4

Kirill A. Shutemov
2023-04-29T00:38:31Z

On Fri, Apr 28, 2023 at 01:15:33PM -0700, Linus Torvalds wrote:
> On Fri, Apr 28, 2023 at 1:07 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So here's my suggested change on top of the current tree. Comments?
>
> Oh, and I wanted to particularly mention that
>
> We could probably just do that "check only starting address" for any
> arbitrary range size: realistically all kernel accesses to user space
> will be done starting at the low address. But let's leave that kind of
> optimization for later. As it is, this already allows us to generate
> simpler code and not worry about any tag bits in the address.
>
> part of the commit log.
>
> Right now that patch only simplifies the range check for when the
> compiler statically knows that the range is small (which does happen,
> but not very often, because 'copy_to/from_user()' isn't inlined on
> x86-64, so the compiler doesn't actually see the constant size case
> that is very common there).

BTW, I think the static check can be relaxed. Checking size against
PAGE_SIZE is rather conservative: there's 8 TB (or 4 PB for 5-level
paging) guard hole at the begging of kernel address space.

> However, that "check the end of the range" is sometimes actually
> fairly complicated code, and it would be nice to drop that entirely.
>
> See for example the fs/readdir.c case, where the length of the access
> is kind of annoying:
>
> if (!user_write_access_begin(dirent,
> (unsigned long)(dirent->d_name + namlen + 1) -
> (unsigned long)dirent))
> goto efault;
>
> and there really isn't any actual reason to check the end of the
> access on x86: if the beginning address has the low bit clear, it
> doesn't really matter what the end is, because we'll either have a
> good area, or we'll fault in the non-canonical area even if the sign
> changes.
>
> So being careful about the range is kind of annoying, when we don't
> really need it.

Hm. Is there anybody who access high to low after the check (glibc
memcpy() bug flashbacks)? Or not in any particular order?

--
Kiryl Shutsemau / Kirill A. Shutemov