linux-kernel - Re: x86/kprobes: Use int3 instead of debug trap for single-step

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

Message-Id: <20210325075814.a66606773b47482b56e9d596@kernel.org>
Date:   Thu, 25 Mar 2021 07:58:14 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Colin Ian King <colin.king@...onical.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: x86/kprobes: Use int3 instead of debug trap for single-step

On Wed, 24 Mar 2021 15:48:34 +0000
Colin Ian King <colin.king@...onical.com> wrote:

> Hi,
> 
> Static analysis on linux-next using Coverity has detected an issue in
> the following commit:
> 
> commit 6256e668b7af9d81472e03c6a171630c08f8858a
> Author: Masami Hiramatsu <mhiramat@...nel.org>
> Date:   Wed Mar 3 00:25:46 2021 +0900
> 
>     x86/kprobes: Use int3 instead of debug trap for single-step
> 
> The analysis is as follows:
> 
> 160        switch (opcode & 0xf0) {
> 161        case 0x60:
> 162                /* can't boost "bound" */
> 163                return (opcode != 0x62);
> 164        case 0x70:
> 165                return 0; /* can't boost conditional jump */
> 166        case 0x90:
> 167                return opcode != 0x9a;  /* can't boost call far */
> 168        case 0xc0:
> 169                /* can't boost software-interruptions */
> 170                return (0xc1 < opcode && opcode < 0xcc) || opcode ==
> 0xcf;
> 171        case 0xd0:
> 172                /* can boost AA* and XLAT */
> 173                return (opcode == 0xd4 || opcode == 0xd5 || opcode ==
> 0xd7);
> 174        case 0xe0:
> 175                /* can boost in/out and absolute jmps */
> 176                return ((opcode & 0x04) || opcode == 0xea);
> 177        case 0xf0:
> 178                /* clear and set flags are boostable */
> 179                return (opcode == 0xf5 || (0xf7 < opcode && opcode <
> 0xfe));
> 
>    dead_error_condition: The switch governing value opcode & 0xf0 cannot
> be 255.
>   undefined (#1 of 1): Logically dead code (DEADCODE)
>   dead_error_begin: Execution cannot reach this statement: case 255:
> 
> 180        case 0xff:
> 181                /* indirect jmp is boostable */
> 182               return X86_MODRM_REG(insn->modrm.bytes[0]) == 4;
> 
> the case 0xff statement can never be reached because the switch
> statement is acting on opcode & 0xf0.

Good catch! It must be under the case 0xf0...

Thank you!

-- 
Masami Hiramatsu <mhiramat@...nel.org>