linux-kernel - objtool - what if I want to clobber rbp?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAHmME9rrA=eYtc-npJCqdhnEnVOT78DR2eZLQTw6yKEYM8=kYw@mail.gmail.com>
Date:   Tue, 21 Nov 2017 22:55:23 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     Samuel Neves <sneves@....uc.pt>
Subject: objtool - what if I want to clobber rbp?

Hi Josh,

We're working on some highly optimized assembly crypto primitive
implementations for WireGuard. The last 24 hours have been spent
trying to make objtool happy with a variety of tricks, some more
unfortunate than others. There's still one issue remaining, however,
and I just can't figure out how to make it go away:

poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx uses BP as a
scratch register
poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx2 uses BP as a
scratch register
poly1305-x86_64.o: warning: objtool: poly1305_blocks_avx512 uses BP as
a scratch register

The messages are right. We're using %rbp as a general purpose
register, writing into it all sorts of crypto gibberish certainly not
suitable for walking stack frames. It's hard to find a way of not
using it, without incurring a speed penalty. We really do just need
all the registers.

Of course the "problem" goes away with the new slick ORC unwinding,
which is great. But for frame pointer unwinding, this problem remains.

I'm wondering if you can think of any clever way of marking a function
or the like that will make this issue go away, somehow. Is there any
path forward without sacrificing %rbp and hence performance to a
useless frame pointer?

Thanks,
Jason