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] [day] [month] [year] [list]

Message-ID: <20251130160528.GBaSxrSFwHscX3vnsB@fat_crate.local>
Date: Sun, 30 Nov 2025 17:05:28 +0100
From: Borislav Petkov <bp@...en8.de>
To: Adrian Hunter <adrian.hunter@...el.com>,
	Masami Hiramatsu <mhiramat@...nel.org>
Cc: 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

Resurrecting a very old thread...

On Wed, Jul 20, 2016 at 11:30:35AM +0300, Adrian Hunter wrote:
> Add support for Intel's AVX-512 instructions to the instruction decoder.
> 
> AVX-512 instructions are documented in Intel Architecture Instruction Set
> Extensions Programming Reference (February 2016).
> 
> AVX-512 instructions are identified by a EVEX prefix which, for the purpose
> of instruction decoding, can be treated as though it were a 4-byte VEX
> prefix.
> 
> Existing instructions which can now accept an EVEX prefix need not be
> further annotated in the op code map (x86-opcode-map.txt). In the case of
> new instructions, the op code map is updated accordingly.
> 
> Also add associated Mask Instructions that are used to manipulate mask
> registers used in AVX-512 instructions.
> 
> 'perf tools' instruction decoder is updated in a subsequent patch.  And a
> representative set of instructions is added to the perf tools new
> instructions test in a subsequent patch.
> 
> Signed-off-by: Adrian Hunter <adrian.hunter@...el.com>
> ---
>  arch/x86/include/asm/inat.h          |  17 ++-
>  arch/x86/include/asm/insn.h          |  12 +-
>  arch/x86/lib/insn.c                  |  18 ++-
>  arch/x86/lib/x86-opcode-map.txt      | 263 +++++++++++++++++++++++------------
>  arch/x86/tools/gen-insn-attr-x86.awk |  11 +-
>  5 files changed, 220 insertions(+), 101 deletions(-)
> 
> +78: VMREAD Ey,Gy | vcvttps2udq/pd2udq Vx,Wpd (evo) | vcvttsd2usi Gv,Wx (F2),(ev) | vcvttss2usi Gv,Wx (F3),(ev) | vcvttps2uqq/pd2uqq Vx,Wx (66),(ev)
> +79: VMWRITE Gy,Ey | vcvtps2udq/pd2udq Vx,Wpd (evo) | vcvtsd2usi Gv,Wx (F2),(ev) | vcvtss2usi Gv,Wx (F3),(ev) | vcvtps2uqq/pd2uqq Vx,Wx (66),(ev)

This is all fine and dandy but those (ev*) flags cause the escape table to
have INAT_EVEXONLY as a flag:

const insn_attr_t inat_escape_table_1_1[INAT_OPCODE_TABLE_SIZE] = {
	...

		[0x79] = INAT_MODRM | INAT_VEXOK | INAT_EVEXONLY,

};

except that that opcode is not EVEX only. Intel's VMREAD and VMWRITE are *not*
EVEX insns and AMD has there EXTRQ and INSERTQ with prefixes 66 and F2
respectively which are SSE4a and both are not EVEX.

The VMREAD and VMWRITE decoding happens to work out by pure chance because
those are without a prefix and the check for prefix id in
inat_get_escape_attribute() happens to not select that escape table.

So the first thing that comes to mind is excluding opcodes like 0x79 which can
be mixed type from that inat_must_vex() enforcement...?

Masami, any other ideas?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette