linux-kernel - Re: [RFC][PATCH 03/36] objtool: Enable compilation of objtool for all architectures

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]

Date:   Tue, 14 Apr 2020 15:01:18 +0100
From:   Julien Thierry <jthierry@...hat.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Matt Helsley <mhelsley@...are.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 03/36] objtool: Enable compilation of objtool for all
 architectures

On 4/14/20 2:41 PM, Steven Rostedt wrote:
> On Tue, 14 Apr 2020 08:39:23 +0100
> Julien Thierry <jthierry@...hat.com> wrote:
> 
>> My concern with this it that most of the structures and code in arch.h
>> and check.c can/should be reused across architectures. So, when
>> providing support for a new architecutre, the first thing that will be
>> needed is to move those back under tools/objtool whithout disturbing the
>> arches that don't yet provide support for "check" subcommand.
> 
> Are all the enums and structs in arch.h non-arch specific?

While some definitions are very x86 specific (in particular PUSH/POP 
related definition), most other other things have similar concept in 
other architectures.

And the "non-generic" definition here do not necessarily interfere with 
other architectures. E.g. if the instruction decoder never produces 
INSN_PUSH or INSN_POP, the corresponding branches in the validation code 
will simply not be taken.

> 
> Or would they need to be split?
> 

So far, for the arm64 work, I've left all those definitions where they 
are. In the future, some cleanup could encourage to split for some "arch 
specific" and "non-arch specific" instruction/stack-ops types, but this 
is not a hard requirement for introducing new architechtures. And I'd 
rather encourage to have complex arch specific instructions be divided 
into several simpler instructions (e.g. PUSH is just sub stack pointer + 
memory access) that could be reused for other architectures, as long as 
that is possible of course.

>>
>> So, if it is decided that recordmcount should be an objtool subcommand,
>> the code itself should probably stay under tools/objtool and then have
>> different compilation configurations for objtool depending on the
>> architecture (e.g. HAVE_OBJTOOL_CHECK, HAVE_OBJTOOL_ORC) or something of
>> the sort.
> 
> That could work.
> 
> -- Steve
> 

-- 
Julien Thierry