linux-kernel - Re: [RFC][PATCH 00/36] objtool: Make recordmcount a subcommand

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: <20200414200910.GB118458@rlwimi.vmware.com>
Date:   Tue, 14 Apr 2020 13:09:10 -0700
From:   Matt Helsley <mhelsley@...are.com>
To:     Steven Rostedt <rostedt@...dmis.org>
CC:     Julien Thierry <jthierry@...hat.com>,
        <linux-kernel@...r.kernel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, Miroslav Benes <mbenes@...e.cz>
Subject: Re: [RFC][PATCH 00/36] objtool: Make recordmcount a subcommand

On Tue, Apr 14, 2020 at 11:54:58AM -0400, Steven Rostedt wrote:
> On Tue, 14 Apr 2020 15:17:39 +0100
> Julien Thierry <jthierry@...hat.com> wrote:
> 
> > > I was hoping to have objtool handle all the operations needed that required
> > > reading elf headers.
> > >   
> > 
> > That makes sense, however, having each operation as an objtool 
> > subcommand doesn't solve that issue, right? Each invocation of objtool 
> > will re-read the elf object.
> > 
> > I guess having all the relevant code in objtool as subcommand would be a 
> > first step towards that goal.
> 
> Exactly. I believe the goal (it's been a while since we discussed this),
> was that we could "batch" the sub commands into a single command. That way,
> the executable will be executed once per object file, load all the elf
> headers, than iterate over all the sub commands that we set on the command
> line.

Yup. The idea is it's somewhat like a pipe but instead of reloading the file
and re-creating the linked data structures each time, each sub command would
simply hand off the ELF section/symbol/relocation structures to the next tool.

If we look in scripts/Makefile.build for example we can see the rule_cc_o_c
definition, after producing the initial .o with the compiler, does:

	$(call cmd,gen_ksymdeps)
        $(call cmd,checkdoc)
        $(call cmd,objtool)
        $(call cmd,modversions_c)
        $(call cmd,record_mcount)

The latter 3 all deal with loading and walking the ELF file output
from the previous step. If we could merge that into a single "call" to
objtool then we can avoid the extra write-close-open-read cycles. I also
wonder if we could move "checkdoc" because then 4 tools in a row could
be relevant to convert (genksyms makes simple use of nm).

I also noticed that, for example, sorttable uses the same ELF code /
patterns as recordmcount -- like the double-include trick. Of course
it operates on a larger scale than per-object-file and so there might
only be code maintenance savings there...

Also, the follow-on is definitely more speculative -- these patches show
that things like recordmcount can be converted to share the same ELF code
as objtool. The benefits of chaining commands together, how easy/hard
that would be, etc. haven't been fully fleshed out. For instance, I was
only looking at "check" and "mcount" chained together.

But even aside from those changes, having all of the tools use the same
ELF code and keeping that ELF code in one place rather than copy-paste
it seems like it would be useful for maintenance.

Cheers,
    -Matt