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]

Message-ID: <20201024082445.GB11562@zn.tnic>
Date:   Sat, 24 Oct 2020 10:24:45 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Andy Lutomirski <luto@...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 Sat, Oct 24, 2020 at 04:13:15PM +0900, Masami Hiramatsu wrote:
> Thanks, so will you split this into several patches, since I saw some
> cleanups in this patch?

Oh, most definitely. This was just a preview of where this is going...

> Yeah, that's good to me because in the most cases, user needs prefix,
> length or total decoded info.
> 
> BTW, it seems you returns 1 for errors, I rather like -EINVAL or -EILSEQ
> for errors so that user can also write
> 
>  if (insn_decode() < 0)
>    ...
> 
> I think "positive" and "zero" pair can easily mislead user to "true" and
> "false" trap.

Ok, sure, makes sense.

> Yeah, for the kprobes, if you see the insn_init() and insn_get_length()
> those can be replaced with one insn_decode().

Ok.

> Except for the return value, it looks good to me.

Thanks!

-- 
Regards/Gruss,
    Boris.

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