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  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:   Thu, 26 Nov 2020 18:50:11 +0100
From:   Borislav Petkov <>
To:     Masami Hiramatsu <>
Cc:     Andy Lutomirski <>, X86 ML <>,
        LKML <>
Subject: Re: [RFC PATCH v0 03/19] x86/insn: Add an insn_decode() API

On Thu, Nov 26, 2020 at 10:37:09AM +0900, Masami Hiramatsu wrote:
> BTW, the instruction validation depends on who needs it, because to
> check the all invalid ops, we need more information in the x86-opcode-map.txt
> and it will bloat up the table size and consumes more time to analysis.

Yes, the decoder is supposed to serve the kernel's needs, not be a
general purpose one.

> (Moreover, it depends on the processor generation -- older processor will
> not support VEX prefix, those are invalid)

Why does the processor VEX support matter? Isn't the decoder supposed to
decode any instruction it knows about, regardless of the CPU it runs on?

> OK, then could you use -1 instead of 1? It may allow us to expand it
> to return error code in the future.

Ok, sure.

> I think insn_get_prefixes() can be used independently, because x86
> perfix bytes is very complex.

Yah, it all depends on what API interfaces we want to give to users and
make those other helpers internal. Time and usecases will tell.



Powered by blists - more mailing lists