linux-kernel - Re: [PATCH, RFC] x86: also CFI-annotate certain inline asm()s

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: <CALCETrXjecpy4MU40o0Z84-wzGq4vn5-hA6mnZTi8TEqMVP0uQ@mail.gmail.com>
Date:	Wed, 5 Nov 2014 09:23:06 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Jan Beulich <jbeulich@...e.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, tonyj@...e.de,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH, RFC] x86: also CFI-annotate certain inline asm()s

On Wed, Nov 5, 2014 at 9:13 AM, Jan Beulich <jbeulich@...e.com> wrote:
>>>> Andy Lutomirski <luto@...capital.net> 11/04/14 8:40 PM >>>
>>On 11/04/2014 01:24 AM, Jan Beulich wrote:
>>> The main obstacle to having done this long ago was the need to
>>> determine whether annotations are needed in the first place: They need
>>> to be avoided when a frame pointer got set up. Since I can't see a way
>>> to determine this before the compilation phase, this is being achieved
>>> by inspecting the memory address generated by the compiler in an
>>> interposed assembler macro. Of course this isn't really nice code, and
>>> this the main reason I'm posting this as RFC only at this point (with
>>> the hope that maybe someone has an idea of how to achieve the same
>>> thing in a more elegant way).
>>
>>Ask binutils for help?
>
> Binutils know as little about the code the compiler generated as we do.

Could binutils add a
.cfi_adjust_cfa_offset_if_the_cfa_depends_on_sp_right_now directive?
IIUC, the issue is that, when you push, you don't want the canonical
frame address to change as a result, but you just changed the stack
pointer, so if the CFA is computed as an offset from the stack pointer
in the current context, that offset needs to change.

Alternatively, is there any sane way to get the inline asm to act as
though it creates an entirely new frame?  It would have CFA == rsp
initially (or rsp + 8 or whatever -- I can never keep track of what
the CFA is actually supposed to point to) and unwind instructions that
tell the unwinder that the caller pc is at a known address instead of
being stuck in the stack frame?

>
>>Is the issue that the CFI annotation you need is different depending on
>>whether there's a frame pointer or not?
>
> No - as said above, they need to be avoided altogether when there's a
> frame pointer.
>
>> If so, can you add some
>>comments so that mere asm mortals have some prayer of understanding how
>>your magic works and what the desired output annotations are in the
>>various cases?
>
> Honestly I have a hard time seeing where comments would help here. Plus
> the difficult part isn't how the annotations look like, but (see above) simply
> whether to emit them at all.

It could be something simple like an example of what the inputs to the
asm macros are in the two cases.  Currently even figuring out where
those inputs come from involves following a big tangle of C
preprocessor stuff, and I don't know what it's supposed to output, and
what that's supposed to do the expansions in the inline asm, and how
that ends up influencing the gas macros.

I.e. I sort of expect I'll need to want to one of these things some
day, and I'd like a couple pointers :)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/