linux-kernel - Re: [PATCH 1/2] x86: insn decoder: create artificial 3rd byte for 2-byte VEX

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]

Date:	Mon, 19 May 2014 16:58:55 +0200
From:	Denys Vlasenko <dvlasenk@...hat.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
CC:	linux-kernel@...r.kernel.org, "Frank Ch. Eigler" <fche@...hat.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Andi Kleen <andi@...stfloor.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 1/2] x86: insn decoder: create artificial 3rd byte for
 2-byte VEX

On 05/17/2014 05:59 PM, Masami Hiramatsu wrote:
> (2014/05/17 3:34), Denys Vlasenko wrote:
>> Before this patch, users need to do this to fetch vex.vvvv:
>>
>>         if (insn->vex_prefix.nbytes == 2) {
>>                 vex_vvvv = ((insn->vex_prefix.bytes[1] >> 3) & 0xf) ^ 0xf;
>>         }
>>         if (insn->vex_prefix.nbytes == 3) {
>>                 vex_vvvv = ((insn->vex_prefix.bytes[2] >> 3) & 0xf) ^ 0xf;
>>         }
>>
>> Make it so that insn->vex_prefix.bytes[2] always contains vex.wvvvvLpp bits.
> 
> I like this hack :)
> If you don't mind, please add inline functions to get such vex bits from
> struct insn too?

I prefer to add such functionality when the first user surfaces:
the needs of the user often dictate more suitable API.

In this case (VEX insns), the API isn't that straightforward.
For example, uprobe code narrowly escaped the need to detect maskmovq__
(0f f7) and maskmovdqu (66 0f f7 or equivalent VEX) instructions.

Let's assume we do need to detect them.
Merely fetching and looking at vex.mmmmm, vex.pp and opcode doesn't
really help that much in detecting these instructions:
with such simplistic help, user needs to check both VEX and legacy forms.

Perhaps a better API would be to form a word-sized "expanded opcode"
for vector and VEX insns. Something along the lines of:

[x.mmmmm.pp.opcode__]

where x bit indicates XOP insn (as opposed to VEX), pp indicate
none/66/F2/F3 prefixes, opcode__ is 8-bit opcode.
then checking for maskmovFOO insns would be easier.
--
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/