Re: [PATCH v1 00/19] x86/insn: Add an insn_decode() API

From: Tom Lendacky
Date: Sun Dec 27 2020 - 10:34:59 EST


On 12/23/20 11:42 AM, Borislav Petkov wrote:
From: Borislav Petkov <bp@xxxxxxx>

Hi,

here's v1 with the requested change to return -ENODATA on short input to
the decoder. The rest is as in the previous submission.

Only lightly tested.

Thx.

changelog:
==========

That is, provided this is how we want to control what the instruction
decoder decodes - by supplying the length of the buffer it should look
at.

We could also say that probably there should be a way to say "decode
only the first insn in the buffer and ignore the rest". That is all up
to the use cases so I'm looking for suggestions here.

That's the way it works today, right? One instruction, no matter the length of the buffer (assuming the length is long enough to include a full instruction)?

Because the callers of the decode may rely on parsing only the current instruction (like SEV-ES), it should probably default to that (although most of the call points are being updated so you could supply a boolean to indicate one vs many instructions). The caller doesn't necessarily know the length of the instruction, so it may provide a buffer of max instruction length.

Also, if you want to parse more than one instruction at a time, wouldn't you need to maintain register context within the parsing, I don't think that is done today. Or you could chain together some instruction contexts to identify each instruction that was parsed?

Thanks,
Tom