Messages in this thread | | | Date | Sat, 29 Apr 2023 03:38:22 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [GIT PULL] x86/mm for 6.4 |
| |
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
| |