linux-kernel - Re: [PATCH 3/4] x86/insn: Extract more information about instructions

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: <53509FD9.2020803@zytor.com>
Date:	Thu, 17 Apr 2014 20:45:29 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Sasha Levin <sasha.levin@...cle.com>
CC:	vegard.nossum@...cle.com, penberg@...nel.org,
	jamie.iles@...cle.com, mingo@...hat.com, tglx@...utronix.de,
	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] x86/insn: Extract more information about instructions

On 04/17/2014 08:40 PM, Masami Hiramatsu wrote:
> (2014/04/18 2:31), Sasha Levin wrote:
>>> I also have seen several attempts at using the generic instruction
>>> decoder which has resulted in more complexity, not less, because of
>>> excess generality, so it is not an obvious thing.
>>
>> Let's split this patchset into two:
>>
>> We have one part which moves kmemcheck to the generic instruction decoder
>> and adds memory access size to the instruction decoder. There seems to be
>> no objection to that part beyond technical issues regarding how we store
>> the new size value.
> 
> This looks OK to me.
> 
>> The other part is adding mnemonics to the instruction decoder. If my
>> explanation above makes sense, and kmemcheck does need to know about AND,
>> OR, XOR, MOVS and CMPS then let me know how to proceed about changing
>> the instruction decoder to add that functionality.
> 
> I don't think we need to add such things to instruction decoder.
> You'd better start from clarifying the bit pattern of those instructions
> and making macros or inlines which evaluate insn->opcode.value.
> 
> Using automatic generated macros for immediate in the source code always
> leads misunderstanding and abuse, and is hard to fix if a bug is there.
> I strongly recommend you to define instruction classification macros
> for their use by hand. That's easy to review too.
> Actually x86 has a long history and its mnemonics are not so simple...
> 

What it sounds like it really wants is a "bitwise" flag on the instruction.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/