linux-kernel - RE: [PATCH v2 13/18] uaccess: generalize access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <93a1ee797e9d4f789dff85a3c0f0c232@AcuMS.aculab.com>
Date:   Fri, 18 Feb 2022 09:30:32 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Andy Lutomirski' <luto@...capital.net>,
        Arnd Bergmann <arnd@...nel.org>
CC:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Christoph Hellwig <hch@....de>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "will@...nel.org" <will@...nel.org>,
        "guoren@...nel.org" <guoren@...nel.org>,
        "bcain@...eaurora.org" <bcain@...eaurora.org>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "monstr@...str.eu" <monstr@...str.eu>,
        "tsbogend@...ha.franken.de" <tsbogend@...ha.franken.de>,
        "nickhu@...estech.com" <nickhu@...estech.com>,
        "green.hu@...il.com" <green.hu@...il.com>,
        "dinguyen@...nel.org" <dinguyen@...nel.org>,
        "shorne@...il.com" <shorne@...il.com>,
        "deller@....de" <deller@....de>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
        "dalias@...c.org" <dalias@...c.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "richard@....at" <richard@....at>,
        "x86@...nel.org" <x86@...nel.org>,
        "jcmvbkbc@...il.com" <jcmvbkbc@...il.com>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "ardb@...nel.org" <ardb@...nel.org>,
        "linux-alpha@...r.kernel.org" <linux-alpha@...r.kernel.org>,
        "linux-snps-arc@...ts.infradead.org" 
        <linux-snps-arc@...ts.infradead.org>,
        "linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
        "linux-hexagon@...r.kernel.org" <linux-hexagon@...r.kernel.org>,
        "linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
        "linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "openrisc@...ts.librecores.org" <openrisc@...ts.librecores.org>,
        "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
        "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
        "linux-um@...ts.infradead.org" <linux-um@...ts.infradead.org>,
        "linux-xtensa@...ux-xtensa.org" <linux-xtensa@...ux-xtensa.org>
Subject: RE: [PATCH v2 13/18] uaccess: generalize access_ok()

From: Andy Lutomirski
> Sent: 17 February 2022 19:15
...
> This isn't actually optimal.  On x86, TASK_SIZE_MAX is a bizarre
> constant that has a very specific value to work around a bug^Wdesign
> error^Wfeature of Intel CPUs.  TASK_SIZE_MAX is the maximum address at
> which userspace is permitted to allocate memory, but there is a huge
> gap between user and kernel addresses, and any value in the gap would
> be adequate for the comparison.  If we wanted to optimize this, simply
> checking the high bit (which x86 can do without any immediate
> constants at all) would be sufficient and, for an access known to fit
> in 32 bits, one could get even fancier and completely ignore the size
> of the access.  (For accesses not known to fit in 32 bits, I suspect
> some creativity could still come up with a construction that's
> substantially faster than the one in your patch.)
> 
> So there's plenty of room for optimization here.
> 
> (This is not in any respect a NAK -- it's just an observation that
> this could be even better.)

For 64bit arch that use the top bit to separate user/kernel
you can test '(addr | size) >> 62)'.
The compiler optimises out constant sizes.

This has all been mentioned a lot of times.
You do get different fault types.

OTOH an explicit check for constant size (less than something big)
can use the cheaper test of the sign bit.
Big constant sizes could be compile time errors.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)