linux-kernel - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHmME9psYjhdHDY_2e_Mqyi97J5v4GckpRGwhdspQOVw-K_Ycw@mail.gmail.com>
Date:   Wed, 22 Nov 2017 11:23:43 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Samuel Neves <sneves@....uc.pt>
Subject: Re: objtool - what if I want to clobber rbp?

Hi Josh,

On Wed, Nov 22, 2017 at 4:31 AM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> - Make your feature conflict with CONFIG_FRAME_POINTER on x86_64.  The
>   ORC unwinder is now the default anyway for 4.15, and we renamed the
>   configs, so most people will be actively switching to ORC.
> BTW, since CONFIG_FRAME_POINTER is no longer the default and is becoming
> deprecated, there has been some talk of disabling objtool with
> CONFIG_FRAME_POINTER.  That would make your life easier.  However I
> think we're not quite ready for that, so it might be a few more release
> cycles before that happens.

Fortunately my code won't be ready to be merged for a few release
cycles, so thanks for letting me know about future plans. I think my
patch set and these changes will synchronize nicely.

>
> - Add some ifdefs so your code only uses %rbp as a scratch register when
>   CONFIG_FRAME_POINTER is disabled.
> - If one of the registers is used less often than the others, you could
>   spill it to the stack.  I know you said you need all the registers,
>   but I'd be willing to review the code for ideas, if that would help.
>   Sometimes it helps to get fresh eyes on the problem.  We were able to
>   fix this problem with all the existing crypto code without affecting
>   performance measurably.  We had to get creative with a few of those.

That actually could be interesting, if you're curious about looking at it.

Jason