linux-kernel - Re: [PATCH v2 2/3] objtool,x86: Additionally decode: mov %rsp, (%reg)

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: <YCK7ZYt92ZFeD5IE@hirez.programming.kicks-ass.net>
Date:   Tue, 9 Feb 2021 17:42:13 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Miroslav Benes <mbenes@...e.cz>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Julien Thierry <jthierry@...hat.com>,
        Kees Cook <keescook@...omium.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] objtool,x86: Additionally decode: mov %rsp, (%reg)

On Tue, Feb 09, 2021 at 10:32:55AM -0600, Josh Poimboeuf wrote:
> On Tue, Feb 09, 2021 at 10:16:02AM +0100, Peter Zijlstra wrote:
> > Where we already decode: mov %rsp, %reg, also decode mov %rsp, (%reg).
> > 
> > Nothing should match for this new stack-op.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> > ---
> >  tools/objtool/arch/x86/decode.c |   23 ++++++++++++++++++-----
> >  1 file changed, 18 insertions(+), 5 deletions(-)
> > 
> > --- a/tools/objtool/arch/x86/decode.c
> > +++ b/tools/objtool/arch/x86/decode.c
> > @@ -222,14 +222,24 @@ int arch_decode_instruction(const struct
> >  		break;
> >  
> >  	case 0x89:
> > -		if (rex_w && !rex_r && modrm_mod == 3 && modrm_reg == 4) {
> > +		if (rex_w && !rex_r && modrm_reg == 4) {
> >  
> > -			/* mov %rsp, reg */
> > +			/* mov %rsp, */
> >  			ADD_OP(op) {
> >  				op->src.type = OP_SRC_REG;
> >  				op->src.reg = CFI_SP;
> > -				op->dest.type = OP_DEST_REG;
> > -				op->dest.reg = op_to_cfi_reg[modrm_rm][rex_b];
> > +				if (modrm_mod == 3) {
> > +
> > +					/* mov %rsp, reg */
> > +					op->dest.type = OP_DEST_REG;
> > +					op->dest.reg = op_to_cfi_reg[modrm_rm][rex_b];
> > +
> > +				} else if (modrm_mod == 0) {
> > +
> > +					/* mov %rsp, (%reg) */
> > +					op->dest.type = OP_DEST_REG_INDIRECT;
> > +					op->dest.reg = op_to_cfi_reg[modrm_rm][rex_b];
> > +				}
> 
> What if modrm_mod is 1 or 2?   Should 'if' below the 'case' make sure
> it's 0 or 3?

For 1,2 we need to look at the SIB byte or something. IIRC you get that
encoding for stuff like: mov %rsp, off(%reg).

Didn't want to dive too deep into the instruction encoding thing again,
this is all we need.

> >  			}
> >  			break;
> >  		}
> > @@ -259,8 +269,10 @@ int arch_decode_instruction(const struct
> >  				op->dest.reg = CFI_BP;
> >  				op->dest.offset = insn.displacement.value;
> >  			}
> > +			break;
> > +		}
> >  
> > -		} else if (rex_w && !rex_b && modrm_rm == 4 && sib == 0x24) {
> > +		if (rex_w && !rex_b && modrm_rm == 4 && sib == 0x24) {
> >  
> >  			/* mov reg, disp(%rsp) */
> >  			ADD_OP(op) {
> > @@ -270,6 +282,7 @@ int arch_decode_instruction(const struct
> >  				op->dest.reg = CFI_SP;
> >  				op->dest.offset = insn.displacement.value;
> >  			}
> > +			break;
> >  		}
> >  
> >  		break;
> > 
> 
> Did this change have a point?

Consistency, but yeah, I see what you mean.