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  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]
Date:   Fri, 15 Sep 2017 19:53:46 +0300
From:   Andrey Ryabinin <>
To:     Josh Poimboeuf <>,
        Linus Torvalds <>
Cc:     the arch/x86 maintainers <>,
        Linux Kernel Mailing List <>,
        Ingo Molnar <>,
        Thomas Gleixner <>,
        "H. Peter Anvin" <>,
        Andy Lutomirski <>,
        Alexander Potapenko <>,
        Dmitriy Vyukov <>,
        Matthias Kaehlcke <>,
        Arnd Bergmann <>,
        Peter Zijlstra <>
Subject: Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more
 clear and consistent

On 08/31/2017 08:25 PM, Josh Poimboeuf wrote:
> There have been a few other ideas which have *almost* worked:
> 1) Make the 'register void *__sp asm(_ASM_SP)' a global variable instead
>    of a local one.  This works for GCC and doesn't break clang.  However
>    it resulted in a lot of changed code on the GCC side.  It looked like
>    some optimizations had been disabled, even in functions which
>    shouldn't have been affected.

(For those who wasn't following previous discussion there is the patch -<>
But, Josh discovered that the patch causes regression in .text size with gcc > 7.x<20170721132452.ihpws67e3e7ym3al@...ble> )

I'm not so sure that this is disabled optimization. I assume that global rsp makes
changes something in gcc's register allocation logic, or something like that leading
to subtle changes in generated code.

But what I recently find out, is that this "regression" sometimes is actually improvement in .text size.
It all depends on .config, e.g:

               text    data     bss     dec     hex filename
patched	       938094  207700 1215752 2361546  2408ca allnoconfig_p/vmlinux
unpatched      938768  211796 1215752 2366316  241b6c allnoconfig/vmlinux                                                                                                                                                         

               text    data     bss     dec     hex filename
patched	       10691469        4882856  876544 16450869         fb0535 defconfig_p/vmlinux
unpatched      10691035        4882856  876544 16450435         fb0383 defconfig/vmlinux

               text    data     bss     dec     hex filename
patched	       159216239       153294411       49692672        362203322       1596c8ba        allyesconfig_p/vmlinux
unpatched      159224951       153294387       49692672        362212010       1596eaaa        allyesconfig/vmlinux

So there is regression with Josh's config and defconfig, but allnoconfig and allyesconfig shows improvement.
Note that sometimes there is the difference in .data size too, don't ask me why.

Given that, perhaps the best thing to do here would be asking gcc devs why is generated code changed.
And if such changes are harmless (as I suspect) we can just fix the problem with this simple patch<> ?
Despite the increased .text on some configs.

Powered by blists - more mailing lists