linux-kernel - Re: [RFC] Have insn decoder functions return success/failure

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 20 Oct 2020 16:37:46 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     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 Tue, Oct 20, 2020 at 11:27:00PM +0900, Masami Hiramatsu wrote:
> So, if this return value is optional, it is OK to me. But the success
> return value does NOT mean it a correctly encoded instruction.

Ok, so what is the correct way to find out whether the decoding was
successful?

Because as it is now, it is confusing:

- Which ->got field do you check?

- Do you check all got fields like insn_complete() does?

And the return value can be made non-optional to denote that the
*function* that was called, was successful or not. The thing is, one
needs to designate one function to call and say, if this function
returns successfully, then the decode was ok.

If we want to look at only some aspects of some insn bytes, we can
definitely make the functions which do, like insn_get_length(),
insn_get_immediate() and all those return a value to denote that *they*
were successful or not.

All I'm trying to say is, *how* this insn decoder *should* be used,
is not really entirely clear, at least to me it isn't, and we need to
define that so that callers know what to expect.

Does that make more sense?

Thx.

-- 
Regards/Gruss,
    Boris.

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