linux-kernel - RE: [PATCH v5] x86: use builtins to read eflags

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: <8B69D1BF-8369-42EC-B0ED-DED038966FC9@zytor.com>
Date:   Fri, 18 Mar 2022 16:03:01 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     David Laight <David.Laight@...LAB.COM>,
        "'Linus Torvalds'" <torvalds@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>
CC:     Andrew Cooper <Andrew.Cooper3@...rix.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Bill Wendling <morbo@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Juergen Gross <jgross@...e.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "llvm@...ts.linux.dev" <llvm@...ts.linux.dev>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-toolchains <linux-toolchains@...r.kernel.org>
Subject: RE: [PATCH v5] x86: use builtins to read eflags

On March 18, 2022 3:43:13 PM PDT, David Laight <David.Laight@...LAB.COM> wrote:
>From: Linus Torvalds
>> Sent: 18 March 2022 18:19
>> 
>> On Fri, Mar 18, 2022 at 10:59 AM Andy Lutomirski <luto@...nel.org> wrote:
>> >
>> > I generally agree.  In this particular case, though, I will keep using
>> > the builtin in tools/testing/selftests/x86/helpers.h unless we actually
>> > hit breakage.  This is because this is *user* code, it is compiled with
>> > the redzone enabled, and the asm code to do the right thing when the
>> > redzone is enabled is too hairy for me to want to deal with it.
>> 
>> Yeah, redzoning is a problem for "pushf".
>> 
>> Or rather, it's not the redzoning itself, but the fact that the
>> compiler might use the word under the stack for random other things,
>> and the pushf will then corrupt some local variable storage.
>> 
>> I think it would be lovely to solve that in inline asm itself some way
>> - by marking the stack pointer clobbered or something.
>
>Something that generates:
>	mov	%rax,-8(%rsp)
>	pushf
>	xchg	%rax,0(%rsp)
>	add	%rsp,8
>should work with or without a redzone.
>Will be a bit slower :-(
>
>	David
>
>-
>Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
>Registration No: 1397386 (Wales)
>

*Much* slower (XCHG is implicitly locked, for hysterical raisins) and you are using the redzone between the mov and the push, so it seems like you just made things worse for no reason.