[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201023092010.GB23324@zn.tnic>
Date: Fri, 23 Oct 2020 11:20:10 +0200
From: Borislav Petkov <bp@...en8.de>
To: Andy Lutomirski <luto@...nel.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, x86-ml <x86@...nel.org>,
Joerg Roedel <jroedel@...e.de>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Have insn decoder functions return success/failure
On Thu, Oct 22, 2020 at 10:58:32AM -0700, Andy Lutomirski wrote:
> I'm guessing that the confusion here is that the kernel instruction
> decoder was originally designed to be used to decode kernel
> instructions, which are generally trusted to be valid, but that it's
> starting to be used to decode user code and such as well.
>
> Masami, could we perhaps have an extra API like:
>
> extern int insn_decode_fully(struct insn *insn);
insn_decode(). Simple. :)
> that decodes the *entire* instruction, returns success if the decoder
> thinks the instruction is valid, and returns an error if the decoder
> thinks it's invalid?
Yap, exactly.
> We would use this when decoding arbitrary bytes
> when we're not really sure that there's a valid instruction there.
> For user code emulation, we don't really care much about performance
> -- the overhead of getting #GP in the first place is much, much higher
> than the overhead of decoding more of the instruction than needed.
Ack.
> Ideally we would solve another little problem at the same time. Right
> now, we are quite sloppy about how we fetch the instruction bytes, and
> it might be nice to fix this. It would be nice if we could have a
> special error code saying "more bytes are needed". So
> insn_decode_fully() would return 0 (or the length) on a successful
> decode, -EINVAL if the bytes are not a valid instruction, and -EAGAIN
> (or something more appropriate) if the bytes are a valid *prefix* of
> an instruction but more bytes are needed. Then the caller would do:
Yah, lemme see if that can be done easily.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists