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] [day] [month] [year] [list]
Message-ID: <20160331064939.GA13328@gmail.com>
Date:	Thu, 31 Mar 2016 08:49:40 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	linux-kernel@...r.kernel.org,
	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


* Andi Kleen <ak@...ux.intel.com> wrote:

> > 
> > Yeah, so udis86 also seems to be a pretty old, relatively stale library with no 
> > support for new instructions AFAICS.
> 
> There are lots of new instructions in pull requests on github.
> 
> But yes the author seems to be a bit slow in pulling.
> 
> > 
> > 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?
> 
> It's a major project. Who is gonna work on it? Are you volunteering?

As a maintainer I don't have much free time and me writing code for every 
technical disagreement doesn't scale in any case, but I'm responsible for creating 
the environment and incentives for people to eventually work on such enhancements.

My main tool to create such an environment is to convince people, if that tool 
doesn't work then my secondary tool is to say 'no'. If we merge udis86 support we 
remove one big incentive for people to factor out and enhance the already existing 
in-kernel disassemblers - not good.

Also, you are exaggerating the technical difficulties a lot (which is sadly a well 
known modus operandi of yours when you don't get your way in technical 
discussions, and which conflicts with the Linux project's 'can do' attitude 
frequently), I've seen in-kernel disassembler pretty-printing patches on lkml as 
well, so clearly it's possible and desirable.

Thanks,

	Ingo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ