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: <e7845564e66f41ccabbf6c23b28966ec@AcuMS.aculab.com>
Date:   Sun, 29 Mar 2020 18:32:10 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Linus Torvalds' <torvalds@...ux-foundation.org>
CC:     Andy Lutomirski <luto@...capital.net>,
        Ingo Molnar <mingo@...nel.org>,
        "Al Viro" <viro@...iv.linux.org.uk>,
        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: Linus Torvalds
> Sent: 29 March 2020 19:16
> On Sun, Mar 29, 2020 at 11:03 AM David Laight <David.Laight@...lab.com> wrote:
> >
> > > That's how get_user() already works.
> > >
> > > It is a polymorphic function (done using macros, sizeof() and ugly
> > > compiler tricks) that generates a call, yes. But it's not a normal C
> > > call. On x86-64, it returns the error code in %rax, and the value in
> > > %rdx
> >
> > I must be mis-remembering the object code from last time
> > I looked at it.
> 
> On an object code level, the end result actually almost looks like a
> normal call, until you start looking at the exact register passing
> details.
> 
> On a source level, it's anything but.
> 
> This is "get_user()" on x86:
> 
>   #define get_user(x, ptr)                                              \
>   ({                                                                    \
>         int __ret_gu;                                                   \
>         register __inttype(*(ptr)) __val_gu asm("%"_ASM_DX);            \
>         __chk_user_ptr(ptr);                                            \
>         might_fault();                                                  \
>         asm volatile("call __get_user_%P4"                              \
>                      : "=a" (__ret_gu), "=r" (__val_gu),                \
>                         ASM_CALL_CONSTRAINT                             \
>                      : "0" (ptr), "i" (sizeof(*(ptr))));                \
>         (x) = (__force __typeof__(*(ptr))) __val_gu;                    \
>         __builtin_expect(__ret_gu, 0);                                  \
>   })

Can't you simplify that by using the =d constraint rather
than relying on a asm register variable.

	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