linux-kernel - Re: [PATCH V2 2/4] x86/insn: Add AVX-512 support to the instruction decoder

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: <cfc12330-adf5-4598-9467-592ee9f88f8e@intel.com>
Date: Tue, 2 Dec 2025 08:26:00 +0200
From: Adrian Hunter <adrian.hunter@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: Masami Hiramatsu <mhiramat@...nel.org>, <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>, Jiri Olsa <jolsa@...hat.com>,
	"Dan Williams" <dan.j.williams@...el.com>, Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, "Andy
 Lutomirski" <luto@...capital.net>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH V2 2/4] x86/insn: Add AVX-512 support to the instruction
 decoder

On 01/12/2025 21:01, Borislav Petkov wrote:
> On Mon, Dec 01, 2025 at 08:15:19PM +0200, Adrian Hunter wrote:
>> EXTRQ Vo,Uo (66) has a mandatory 66 prefix like vcvtps2uqq/pd2uqq Vx,Wx (66),(ev) so they end up on the same attribute table, but (ev) results in INAT_EVEXONLY which is unwanted.
>>
>> Changing that from (ev) to (evo) is probably all that is needed e.g.
>>
>> +79: VMWRITE Gy,Ey | EXTRQ Vo,Uo (66) | vcvtps2udq/pd2udq Vx,Wpd (evo) | vcvtsd2usi Gv,Wx (F2),(ev) | vcvtss2usi Gv,Wx (F3),(ev) | vcvtps2uqq/pd2uqq Vx,Wx (66),(evo)
>>
> 
> That still sounds to me like a hack: looking at the SDM, that thing:
> 
> VCVTPS2UQQ—Convert Packed Single Precision Floating-Point Values to Packed
> Unsigned Quadword Integer Values
> 
> *is* EVEX-only insn:
> 
> EVEX.128.66.0F.W0

The instruction decoder is permissive in the sense that it cannot
tell if an instruction is valid, only what its properties are assuming
it is valid.  There is no need to validate EVEX-only.

ev->evo makes sense to allow for another instruction.

> 
> the "66" meaning in this case EVEX.pp which are the VEX.pp two bits with value
> 1b meaning there's an implied 66 legacy prefix.
> 
> To make it more concrete, let's take an example from the binutils testsuite:
> 
> 62 f1 7d 4f 79 f5[    ]*vcvtps2uqq zmm6\{k7\},ymm5
> 
> and that's basically:
> 
> Extended VEctor prefiX:         0x62
>   P1: [R:1|X:1|B:1|R':1|rsv:0|mm:1] 0xf1
>   P2: [W:0|vvvv:0xf    |rsv:1|pp:1] 0x7d
>   P3: [z:0|L':1|L:0|b:0|V':1|aaa:7] 0x4f
> 
> with the opcode 0x79 and EVEX.pp=1b, as expected.
> 
> So there's no real 66 prefix there.
> 
> But our opcode map says:
> 
> "# Last Prefix Superscripts
> #  - (66): the last prefix is 0x66"
> 
> So we're using the marking (66) to mean both an explicit 66 legacy prefix and
> an implied *VEX.pp=1 66 prefix equivalence.
> 
> So now the question is, why do the *VEX opcodes need that (66) marking at all?
> For operand sizing?
> 
> Looking at our example insn VCVTPS2UQQ, I don't see any other encoding where
> 66 is not present. And there's nothing in the pseudo code either. So VEX.pp=1
> is part of the encoding of that insn.
> 
> So, that (66) there is not really the prefix ...

It puts the instruction into a different opcode/addressing-mode space
(different attribute table) so we probably need to keep using it like that.