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: <489c9af889954649b3453e350bab6464@AcuMS.aculab.com>
Date:   Sun, 29 Mar 2020 17:41:12 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Andy Lutomirski' <luto@...capital.net>,
        Ingo Molnar <mingo@...nel.org>
CC:     Al Viro <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>
Subject: RE: [RFC][PATCH 01/22] x86 user stack frame reads: switch to explicit
 __get_user()

From: Andy Lutomirski
> Sent: 29 March 2020 17:51
..
> My incliniation is to just get rid of the __get_user()-style APIs.
> There shouldn't be any __get_user() calls that can't be directly
> replaced by get_user(), and a single integer comparison is not that
> expensive.  On SMAP systems, the speedup of __get_user vs get_user is
> negligible.

On x86-64 (at least) __get_user() is inlined but get_user() isn't.
Since get_user() has to return two values, one will always be
a (usually) on-stack real memory location rather than a register.
For frequently use code paths this may be measurable.
I'm thinking of things like epoll_wait() writing out events.
(although that is a put_user() loop...)

It may be worth implementing get_user() as an inline
function that writes the result of access_ok() to a
'by reference' parameter and then returns the value
from an 'real' __get_user() function.
The compiler will then optimise away the memory reference.

	David

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ