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: <20251202104746.GAaS7D0jXL4qN8XPXi@fat_crate.local>
Date: Tue, 2 Dec 2025 11:47:46 +0100
From: Borislav Petkov <bp@...en8.de>
To: Adrian Hunter <adrian.hunter@...el.com>
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 Tue, Dec 02, 2025 at 08:26:00AM +0200, Adrian Hunter wrote:
> 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.

I have no clue what you mean here.

> #  (ev): this opcode requires EVEX prefix.
> #  (evo): this opcode is changed by EVEX prefix (EVEX opcode)

I can certainly see the "evo" part. This opcode - 0f 79 - means different
things with different prefixes. So "ev" is wrong here because this opcode does
*not* require EVEX - it can exist without EVEX.

So the "ev" -> "evo" change is probably the right thing to do ATM.

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

Probably?

This scheme of putting an insn in a different attribute table because of
randomly selected insn properties looks silly and error prone to me. If you
want to mark it as part of the whole AVX512* set, then use the fact that it
has an EVEX prefix. That's all.

And if you want to differentiate on VEX.pp, then invent a new "superscript" or
whatever this thing is called which is called VEX_pp or whatever. But do not
call it 66 to mean the legacy prefix because that is wrong and it conflates
two incompatible things as it can be seen here, and causes trouble.

I mean, there should be a direct 1:1 match between insn encoding and flags we
need and that'll give us the different attribute tables as this thing is
designed and all is fine and dandy.

I'd say.

-- 
Regards/Gruss,
    Boris.

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