lkml.org 
[lkml]   [2020]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Have insn decoder functions return success/failure
    On Wed, Oct 21, 2020 at 06:45:58PM +0200, Borislav Petkov wrote:
    > On Wed, Oct 21, 2020 at 11:26:13PM +0900, Masami Hiramatsu wrote:
    > > Hmm, I meant someone might think it can be used for filtering the
    > > instruction something like,
    > >
    > > insn_init(insn, buf, buflen, 1);
    > > ret = insn_get_length(insn);
    > > if (!ret) {
    > > /* OK, this is safe */
    > > patch_text(buf, trampoline);
    > > }
    > >
    > > No, we need another validator for such usage.
    >
    > Well, I think calling insn_get_length() should give you only the
    > *length* of the insn and nothing else - I mean that is what the function
    > is called. And I believe current use is wrong.
    >
    > Examples:
    >
    > arch/x86/kernel/kprobes/core.c:
    > insn_get_length(&insn);
    >
    > /*
    > * Another debugging subsystem might insert this breakpoint.
    > * In that case, we can't recover it.
    > */
    > if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
    >
    > So this has called get_length but it is far from clear that after that
    > call, the opcode bytes in insn.opcode.bytes are there.

    Given the trainwreck called x86-instruction-encoding, it's impossible to
    not have decoded the opcode and still know the length. Therefore, if you
    know the length, you also have the opcode. Hm?

    \
     
     \ /
      Last update: 2020-10-22 10:04    [W:3.379 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site