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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 17 Feb 2017 15:18:04 -0600 From: Josh Poimboeuf <jpoimboe@...hat.com> To: Jiri Slaby <jslaby@...e.cz> 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 Fri, Feb 17, 2017 at 03:26:36PM +0100, Jiri Slaby wrote: > 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) Have you seen any real inline asm issues? I had been thinking they weren't a problem, because CFI instructions are only emitted for the function prologue and epilogue. Running objtool with CFI analysis seemed to confirm that -- I don't remember seeing any inline asm issues with CFI like we did with frame pointers. So my thinking for objtool CFI was: .c files: read-only .S files: write-only > > 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. Nice! Does it work? > 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. Yes, that would make sense if we have to do read-write for .c files. -- Josh
Powered by blists - more mailing lists