Re: [PATCH v7 14/26] x86/insn-eval: Indicate a 32-bit displacement if ModRM.mod is 0 and ModRM.rm is 5

[Ricardo Neri]

On Wed, 2017-06-07 at 15:15 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:12AM -0700, Ricardo Neri wrote:
> > Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software
> > Developer's Manual volume 2A states that when ModRM.mod is zero and
> > ModRM.rm is 101b, a 32-bit displacement follows the ModRM byte. This means
> > that none of the registers are used in the computation of the effective
> > address. A return value of -EDOM signals callers that they should not use
> > the value of registers when computing the effective address for the
> > instruction.
> > 
> > In IA-32e 64-bit mode (long mode), the effective address is given by the
> > 32-bit displacement plus the value of RIP of the next instruction.
> > In IA-32e compatibility mode (protected mode), only the displacement is
> > used.
> > 
> > The instruction decoder takes care of obtaining the displacement.
> 
> ...
> 
> > diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
> > index 693e5a8..4f600de 100644
> > --- a/arch/x86/lib/insn-eval.c
> > +++ b/arch/x86/lib/insn-eval.c
> > @@ -379,6 +379,12 @@ static int get_reg_offset(struct insn *insn, struct 
> > pt_regs *regs,
> > switch (type) {
> > case REG_TYPE_RM:
> > regno = X86_MODRM_RM(insn->modrm.value);
> 
> 
> < newline here.

Will add the new line.
> 
> > +   /*
> > +* ModRM.mod == 0 and ModRM.rm == 5 means a 32-bit displacement
> > +* follows the ModRM byte.
> > +*/
> > +   if (!X86_MODRM_MOD(insn->modrm.value) && regno == 5)
> > +   return -EDOM;
> > if (X86_REX_B(insn->rex_prefix.value))
> > regno += 8;
> > break;
> > @@ -730,9 +736,21 @@ void __user *insn_get_addr_ref(struct insn *insn, 
> > struct pt_regs *regs)
> > eff_addr = base + indx * (1 << X86_SIB_SCALE(sib));
> > } else {
> > addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
> > -   if (addr_offset < 0)
> 
> ditto.

Will add the new line.
> 
> > +   /*
> > +* -EDOM means that we must ignore the address_offset.
> > +* In such a case, in 64-bit mode the effective address
> > +* relative to the RIP of the following instruction.
> > +*/
> > +   if (addr_offset == -EDOM) {
> > +   eff_addr = 0;
> > +   if (user_64bit_mode(regs))
> > +   eff_addr = (long)regs->ip +
> > +  insn->length;
> 
> Let that line stick out and write it balanced:
> 
> if (addr_offset == -EDOM) {
> if (user_64bit_mode(regs))
> eff_addr = (long)regs->ip + 
> insn->length;
> else
> eff_addr = 0;
> 
> should be easier parseable this way.

Will rewrite as you suggest.

Thanks and BR,
Ricardo

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 14/26] x86/insn-eval: Indicate a 32-bit displacement if ModRM.mod is 0 and ModRM.rm is 5

[Borislav Petkov]

On Fri, May 05, 2017 at 11:17:12AM -0700, Ricardo Neri wrote:
> Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software
> Developer's Manual volume 2A states that when ModRM.mod is zero and
> ModRM.rm is 101b, a 32-bit displacement follows the ModRM byte. This means
> that none of the registers are used in the computation of the effective
> address. A return value of -EDOM signals callers that they should not use
> the value of registers when computing the effective address for the
> instruction.
> 
> In IA-32e 64-bit mode (long mode), the effective address is given by the
> 32-bit displacement plus the value of RIP of the next instruction.
> In IA-32e compatibility mode (protected mode), only the displacement is
> used.
> 
> The instruction decoder takes care of obtaining the displacement.

...

> diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
> index 693e5a8..4f600de 100644
> --- a/arch/x86/lib/insn-eval.c
> +++ b/arch/x86/lib/insn-eval.c
> @@ -379,6 +379,12 @@ static int get_reg_offset(struct insn *insn, struct 
> pt_regs *regs,
>   switch (type) {
>   case REG_TYPE_RM:
>   regno = X86_MODRM_RM(insn->modrm.value);


< newline here.

> + /*
> +  * ModRM.mod == 0 and ModRM.rm == 5 means a 32-bit displacement
> +  * follows the ModRM byte.
> +  */
> + if (!X86_MODRM_MOD(insn->modrm.value) && regno == 5)
> + return -EDOM;
>   if (X86_REX_B(insn->rex_prefix.value))
>   regno += 8;
>   break;
> @@ -730,9 +736,21 @@ void __user *insn_get_addr_ref(struct insn *insn, struct 
> pt_regs *regs)
>   eff_addr = base + indx * (1 << X86_SIB_SCALE(sib));
>   } else {
>   addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
> - if (addr_offset < 0)

ditto.

> + /*
> +  * -EDOM means that we must ignore the address_offset.
> +  * In such a case, in 64-bit mode the effective address
> +  * relative to the RIP of the following instruction.
> +  */
> + if (addr_offset == -EDOM) {
> + eff_addr = 0;
> + if (user_64bit_mode(regs))
> + eff_addr = (long)regs->ip +
> +insn->length;

Let that line stick out and write it balanced:

if (addr_offset == -EDOM) {
if (user_64bit_mode(regs))
eff_addr = (long)regs->ip + 
insn->length;
else
eff_addr = 0;

should be easier parseable this way.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 14/26] x86/insn-eval: Indicate a 32-bit displacement if ModRM.mod is 0 and ModRM.rm is 5

[Ricardo Neri]

Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when ModRM.mod is zero and
ModRM.rm is 101b, a 32-bit displacement follows the ModRM byte. This means
that none of the registers are used in the computation of the effective
address. A return value of -EDOM signals callers that they should not use
the value of registers when computing the effective address for the
instruction.

In IA-32e 64-bit mode (long mode), the effective address is given by the
32-bit displacement plus the value of RIP of the next instruction.
In IA-32e compatibility mode (protected mode), only the displacement is
used.

The instruction decoder takes care of obtaining the displacement.

Cc: Dave Hansen 
Cc: Adam Buchbinder 
Cc: Colin Ian King 
Cc: Lorenzo Stoakes 
Cc: Qiaowei Ren 
Cc: Arnaldo Carvalho de Melo 
Cc: Masami Hiramatsu 
Cc: Adrian Hunter 
Cc: Kees Cook 
Cc: Thomas Garnier 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: Dmitry Vyukov 
Cc: Ravi V. Shankar 
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri 
---
 arch/x86/lib/insn-eval.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index 693e5a8..4f600de 100644
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -379,6 +379,12 @@ static int get_reg_offset(struct insn *insn, struct 
pt_regs *regs,
switch (type) {
case REG_TYPE_RM:
regno = X86_MODRM_RM(insn->modrm.value);
+   /*
+* ModRM.mod == 0 and ModRM.rm == 5 means a 32-bit displacement
+* follows the ModRM byte.
+*/
+   if (!X86_MODRM_MOD(insn->modrm.value) && regno == 5)
+   return -EDOM;
if (X86_REX_B(insn->rex_prefix.value))
regno += 8;
break;
@@ -730,9 +736,21 @@ void __user *insn_get_addr_ref(struct insn *insn, struct 
pt_regs *regs)
eff_addr = base + indx * (1 << X86_SIB_SCALE(sib));
} else {
addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
-   if (addr_offset < 0)
+   /*
+* -EDOM means that we must ignore the address_offset.
+* In such a case, in 64-bit mode the effective address
+* relative to the RIP of the following instruction.
+*/
+   if (addr_offset == -EDOM) {
+   eff_addr = 0;
+   if (user_64bit_mode(regs))
+   eff_addr = (long)regs->ip +
+  insn->length;
+   } else if (addr_offset < 0) {
goto out_err;
-   eff_addr = regs_get_register(regs, addr_offset);
+   } else {
+   eff_addr = regs_get_register(regs, addr_offset);
+   }
}
eff_addr += insn->displacement.value;
}
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html