linux-kernel - Re: [PATCH 10/11] perf tools: Add probing for udev86 library

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:	Wed, 30 Mar 2016 15:52:46 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Arnaldo Carvalho de Melo <acme@...hat.com>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
	Stephane Eranian <eranian@...gle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andy Lutomirski <luto@...nel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Zi Shen Lim <zlim.lnx@...il.com>
Subject: Re: [PATCH 10/11] perf tools: Add probing for udev86 library


* Arnaldo Carvalho de Melo <acme@...hat.com> wrote:

> Em Wed, Mar 30, 2016 at 12:43:27PM +0200, Ingo Molnar escreveu:
> > > From: Andi Kleen <ak@...ux.intel.com>
> 
> > > Add autoprobing for the udev86 disassembler library.
>  
> > So the typo in the title is confusing, what is 'udev86'?
>  
> > Also, this library does not seem to be available on stock Ubuntu. We should not be 
> > adding library dependencies that cannot be resolved on major distros:
> 
> Ok, I'll remove, I thought it would be ok because I fired up:
> 
>   # dnf install udis86-devel
> 
> On fedora and it installed straight away, but after I started trying to
> update my docker images I couldn't find it on debian
> experimental/unstable:

> Nor even in OpenSuSE:

> Or even Mageia:

Yeah, so udis86 also seems to be a pretty old, relatively stale library with no 
support for new instructions AFAICS.

So I'd rather encourage librarizing one of the x86 instruction decoders in 
arch/x86/, and adding pretty-printing functionality to it. The code can already 
see instruction boundaries, which is the hardest part.

That would also be better supported on non-x86 architectures in the long run:

 triton:~/tip> find arch/ -name insn.c | xargs ls -l
 -rw-rw-r-- 1 mingo mingo 30244 Mar 29 11:24 arch/arm64/kernel/insn.c
 -rw-rw-r-- 1 mingo mingo  1347 Dec  8 06:27 arch/arm/kernel/insn.c
 -rw-rw-r-- 1 mingo mingo 15123 Mar 30 12:31 arch/x86/lib/insn.c

Such an in-kernel-repo library could also be used by live kernel debuggers such as 
kgdb/kdb, oops/crash-time disassembly printout, etc.

... so how about that direction instead?

Thank,

	Ingo