linux-kernel - Re: [PREVIEW 10/10] linkage: add .cfi

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: <7f613a09-39f8-5477-ed5e-17024baf5876@suse.cz>
Date:   Fri, 17 Feb 2017 15:26:36 +0100
From:   Jiri Slaby <jslaby@...e.cz>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     mingo@...hat.com, tglx@...utronix.de, hpa@...or.com,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PREVIEW 10/10] linkage: add .cfi_{start/end}proc to
 ENTRY/ENDPROC

On 02/17/2017, 03:07 PM, Josh Poimboeuf wrote:
> On Fri, Feb 17, 2017 at 02:36:15PM +0100, Jiri Slaby wrote:
>> On 02/17/2017, 02:16 PM, Josh Poimboeuf wrote:
>>> On Fri, Feb 17, 2017 at 11:47:57AM +0100, Jiri Slaby wrote:
>>>> This is just a preview, not to merged now, only later with DWARF
>>>> unwinder series. This is what the series will serve for (aside from
>>>> cleanup and unification).
>>>>
>>>> I am aware of CFI_STARTPROC and CFI_ENDPROC left defined in other archs
>>>> in spite of cfi annotations removal ages ago. For simplicity. I am using
>>>> DW_ prefix here.
>>>
>>> If objtool is going to be generating CFI instructions, why not have it
>>> generate .cfi_startproc and .cfi_endproc too?
>>
>> I tried that, but in many places it is very hard to recognize start
>> and/or end of a function.
> 
> How so?  objtool already knows where the start and end of every function
> is due to ENDPROC's use of the .type and .size macros.

Right, I did not realized that we are writing about different things. So
yes, when the series is applied, we have ENTRY, ENDPROC et al. at all
appropriate places. We can indeed use that info.

>> Having .cfi_startproc and .cfi_endproc in place makes it rather easy,
>> actually reduced to "emit dwarf instructions for this code between
>> here and there". Plus pre-prepared .eh_frame only to be extended.
>> (.eh_frame_hdr has to be rehashed of course.)
> 
> Hm, but now objtool has to read *and* write CFI instead of just writing.

That is needed due to inline assembly anyway :/. So the way I wanted to
go was: here you have code with possibly incomplete (but at least some)
CFIs, fix the broken ones. Otherwise we would have to differentiate 2
kind of files:
* .c files with inline assembly (read-write = update CFIs)
* .S files with "native" assembly (write eh_frame header and also CFIs)

> It would help to see the generation code.  Have you written it?

I started writing it and it is complete crap so far :P. Please see
"objtool: generate dwarf for asm" at:
https://git.kernel.org/cgit/linux/kernel/git/jirislaby/linux.git/log/?h=devel

And yes, the current code is for .S files without any .eh_frame. Then I
decided to clean up ENTRY/ENDPROC etc. first. It's up to discussion what
route we want to go, but I would prefer the "read-write" since we have
to implement it anyway.

thanks,
-- 
js
suse labs