linux-kernel - Re: [PATCH 0/4] objtool,perf: Use shared x86 insn decoder

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]

Message-Id: <20190831105152.bcacc88a7cc760070fc95d98@kernel.org>
Date:   Sat, 31 Aug 2019 10:51:52 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...hat.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH 0/4] objtool,perf: Use shared x86 insn decoder

On Fri, 30 Aug 2019 16:48:45 -0300
Arnaldo Carvalho de Melo <acme@...nel.org> wrote:

> Em Fri, Aug 30, 2019 at 02:31:09PM -0500, Josh Poimboeuf escreveu:
> > On Fri, Aug 30, 2019 at 04:00:58PM -0300, Arnaldo Carvalho de Melo wrote:
> > > I.e. we need to make sure that it always gets the x86 stuff, not
> > > something that is tied to the host arch, with the patch below we get it
> > > to work, please take a look.
> > > 
> > > Probably this should go to the master copy, i.e. to the kernel sources,
> > > no?

Interesting approach. Hmm, but I would like "diff -I" trick just
for short term solution.

> > > 
> > > That or we'll have to ask the check-headers.sh and objtool sync-check
> > > (hey, this should be unified, each project could provide just the list
> > > of things it uses, but I digress) to ignore those lines...
> > > 
> > > I.e. we want to decode intel_PT traces on other arches, ditto for
> > > CoreSight (not affected here, but similar concept).
> > > 
> > > will kick the full container build process now.
> > 
> > Interesting, I didn't realize other arches would be using it.  The patch
> 
> Yeah, decoding CoreSight (aarch64) hardware traces on x86_64 should be
> as possible as decoding Intel PT hardware traces on aarch64 :-)
> 
> > looks good to me.
> > 
> > Ideally there wouldn't be any differences between the headers, but if
> > that's unavoidable then I guess we can just use the same 'diff -I' trick
> 
> I'll go with this now, but...
> 
> > we were using before in the check script(s).
> 
> Masami? What do you think of applying the patch to the main kernel
> sources so that building a decoder for x86 on any other arch becomes
> possible?

I think the build of kernel and user-space tools are different especially
for "include/asm", since user-space tools may want to use all architecture
features, but kernel needs only the architecture which it runs on.
Maybe we need a special Makefile entries for the modules which depends
on architecture dependent parts. e.g.

x86-objs = insn.o inat.o ...
arm64-objs = coresight.o ...

and they should have different -I options ('-I arch/x86/include' or 
'-I arch/arm64/include') for compiling.
I think this is better and scalable, if you use common (clone) files in
the kernel tree.

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>