linux-kernel - Re: [RFC][PATCH 00/13] Cleanup recordmcount and begin objtool conversion

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 May 2019 16:52:19 -0700
From:   Matt Helsley <mhelsley@...are.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
CC:     Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [RFC][PATCH 00/13] Cleanup recordmcount and begin objtool
 conversion

On Wed, May 29, 2019 at 09:11:45AM -0500, Josh Poimboeuf wrote:
> On Wed, May 29, 2019 at 03:41:52PM +0200, Peter Zijlstra wrote:
> > On Tue, May 28, 2019 at 09:43:28AM -0500, Josh Poimboeuf wrote:
> > > Would it be feasible to eventually combine subcommands so that objtool
> > > could do both ORC and mcount generation in a single invocation?  I
> > > wonder what what the interface would look like.

I think it'll be feasible. I've done a bit of investigation but don't
have patches for it yet.

> > 
> > objtool orc+mcount ?
> > 
> > That is, have '+' be a separator for cmd thingies. That would of course
> > require all other arguments to be shared between all commands, which is
> > currently already so, but I've not checked the mcount patches.
> 
> The problem is that you have to combine "orc generate" with "mcount
> record".  Because even the subcommands have subcommands ;-)
> 
> And also sharing arguments between all subcommands isn't ideal.
> 
> Maybe could do:
> 
>   objtool orc generate [orc options] + mcount record [mcount options]

I think that makes more sense; it'll be easier to construct
Make recipes this way. I was thinking '+' would be something like the
getopt handling of the '--' argument where it stops argument parsing so
someting else can consume the remainder.

The really interesting part is deciding which file to operate on is
specified by the arguments to the first subcommand and subsequent subcmds
would then operate on the same object file. For example:

objtool orc generate [orc opts] foo.o + mcount record [mcount opts]

Would it be clearer what's going on if the object file(s) were specified
first and then the passes to run and their arguments came afterwards?
I'm thinking it'd go somewhat like this:

objtool foo.o [bar.o] -- check [check opts] + \
			 orc generate [orc opts] + \
			 mcount record [mcount opts]

Then objtool would iterate over the object file(s) to open,
hand off the ELF data structures into each successive pass, and
finally write any accumulated changes back.

Cheers,
    -Matt