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: <20190830194845.GI28011@kernel.org>
Date:   Fri, 30 Aug 2019 16:48:45 -0300
From:   Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     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

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?
> > 
> > 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?

- Arnaldo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ