Re: [PATCH v7 09/26] x86/insn-eval: Add utility function to identify string instructions

[Borislav Petkov]

On Mon, Jun 05, 2017 at 11:01:21PM -0700, Ricardo Neri wrote:
> If I was to leave out string instructions from this function it should
> be renamed as is_string_instruction_non_lods_outs. In my opinion this
> separation makes the code more clear and I would end up having logic to
> decide which segment register to use in two places. Does it makes sense
> to you?

Ok, sure.

Thanks.

-- 
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

Re: [PATCH v7 09/26] x86/insn-eval: Add utility function to identify string instructions

[Ricardo Neri]

On Mon, 2017-05-29 at 23:48 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:07AM -0700, Ricardo Neri wrote:
> > String instructions are special because in protected mode, the linear
> > address is always obtained via the ES segment register in operands that
> > use the (E)DI register.
> 
>  ... and DS for rSI.

Right, I omitted this in the commit message.
> 
> If we're going to account for both operands of string instructions with
> two operands.
> 
> Btw, LODS and OUTS use only DS:rSI as a source operand. So we have to be
> careful with the generalization here. So if ES:rDI is the only seg. reg
> we want, then we don't need to look at those insns... (we assume DS by
> default).

My intention with this function is to write a function that does only
one thing: identify string instructions, irrespective of the operands
they use. A separate function, resolve_seg_register, will have the logic
to decide what to segment register to use based on the registers used as
operands, whether we are looking at a string instruction, whether we
have segment override prefixes and whether such overrides should be
ignored.

If I was to leave out string instructions from this function it should
be renamed as is_string_instruction_non_lods_outs. In my opinion this
separation makes the code more clear and I would end up having logic to
decide which segment register to use in two places. Does it makes sense
to you?

> 
> ...
> 
> > +/**
> > + * is_string_instruction - Determine if instruction is a string instruction
> > + * @insn:  Instruction structure containing the opcode
> > + *
> > + * Return: true if the instruction, determined by the opcode, is any of the
> > + * string instructions as defined in the Intel Software Development manual.
> > + * False otherwise.
> > + */
> > +static bool is_string_instruction(struct insn *insn)
> > +{
> > +   insn_get_opcode(insn);
> > +
> > +   /* all string instructions have a 1-byte opcode */
> > +   if (insn->opcode.nbytes != 1)
> > +   return false;
> > +
> > +   switch (insn->opcode.bytes[0]) {
> > +   case INSB:
> > +   /* fall through */
> > +   case INSW_INSD:
> > +   /* fall through */
> > +   case OUTSB:
> > +   /* fall through */
> > +   case OUTSW_OUTSD:
> > +   /* fall through */
> > +   case MOVSB:
> > +   /* fall through */
> > +   case MOVSW_MOVSD:
> > +   /* fall through */
> > +   case CMPSB:
> > +   /* fall through */
> > +   case CMPSW_CMPSD:
> > +   /* fall through */
> > +   case STOSB:
> > +   /* fall through */
> > +   case STOSW_STOSD:
> > +   /* fall through */
> > +   case LODSB:
> > +   /* fall through */
> > +   case LODSW_LODSD:
> > +   /* fall through */
> > +   case SCASB:
> > +   /* fall through */
> 
> That "fall through" for every opcode is just too much. Also, you can use
> the regularity of the x86 opcode space and do:
> 
>   case 0x6c ... 0x6f: /* INS/OUTS */
>   case 0xa4 ... 0xa7: /* MOVS/CMPS */
>   case 0xaa ... 0xaf: /* STOS/LODS/SCAS */
>   return true;
>   default:
>   return false;
> }
> 
> And voila, there's your compact is_string_insn() function! :^)

Thanks for the suggestion! It looks really nice. I will implement
accordingly.

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 09/26] x86/insn-eval: Add utility function to identify string instructions

[Borislav Petkov]

On Fri, May 05, 2017 at 11:17:07AM -0700, Ricardo Neri wrote:
> String instructions are special because in protected mode, the linear
> address is always obtained via the ES segment register in operands that
> use the (E)DI register.

 ... and DS for rSI.

If we're going to account for both operands of string instructions with
two operands.

Btw, LODS and OUTS use only DS:rSI as a source operand. So we have to be
careful with the generalization here. So if ES:rDI is the only seg. reg
we want, then we don't need to look at those insns... (we assume DS by
default).

...

> +/**
> + * is_string_instruction - Determine if instruction is a string instruction
> + * @insn:Instruction structure containing the opcode
> + *
> + * Return: true if the instruction, determined by the opcode, is any of the
> + * string instructions as defined in the Intel Software Development manual.
> + * False otherwise.
> + */
> +static bool is_string_instruction(struct insn *insn)
> +{
> + insn_get_opcode(insn);
> +
> + /* all string instructions have a 1-byte opcode */
> + if (insn->opcode.nbytes != 1)
> + return false;
> +
> + switch (insn->opcode.bytes[0]) {
> + case INSB:
> + /* fall through */
> + case INSW_INSD:
> + /* fall through */
> + case OUTSB:
> + /* fall through */
> + case OUTSW_OUTSD:
> + /* fall through */
> + case MOVSB:
> + /* fall through */
> + case MOVSW_MOVSD:
> + /* fall through */
> + case CMPSB:
> + /* fall through */
> + case CMPSW_CMPSD:
> + /* fall through */
> + case STOSB:
> + /* fall through */
> + case STOSW_STOSD:
> + /* fall through */
> + case LODSB:
> + /* fall through */
> + case LODSW_LODSD:
> + /* fall through */
> + case SCASB:
> + /* fall through */

That "fall through" for every opcode is just too much. Also, you can use
the regularity of the x86 opcode space and do:

case 0x6c ... 0x6f: /* INS/OUTS */
case 0xa4 ... 0xa7: /* MOVS/CMPS */
case 0xaa ... 0xaf: /* STOS/LODS/SCAS */
return true;
default:
return false;
}

And voila, there's your compact is_string_insn() function! :^)

(Modulo the exact list, as I mentioned above).

Thanks.

-- 
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 09/26] x86/insn-eval: Add utility function to identify string instructions

[Ricardo Neri]

String instructions are special because in protected mode, the linear
address is always obtained via the ES segment register in operands that
use the (E)DI register. Segment override prefixes are ignored. non-
string instructions use DS as the default segment register and it can
be overridden with a segment override prefix.

This function will be used in a subsequent commmit that introduces a
function to determine the segment register to use given the instruction,
operands and segment override prefixes.

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 | 67 
 1 file changed, 67 insertions(+)

diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index 8b16761..1634762 100644
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -16,6 +16,73 @@ enum reg_type {
REG_TYPE_BASE,
 };
 
+enum string_instruction {
+   INSB= 0x6c,
+   INSW_INSD   = 0x6d,
+   OUTSB   = 0x6e,
+   OUTSW_OUTSD = 0x6f,
+   MOVSB   = 0xa4,
+   MOVSW_MOVSD = 0xa5,
+   CMPSB   = 0xa6,
+   CMPSW_CMPSD = 0xa7,
+   STOSB   = 0xaa,
+   STOSW_STOSD = 0xab,
+   LODSB   = 0xac,
+   LODSW_LODSD = 0xad,
+   SCASB   = 0xae,
+   SCASW_SCASD = 0xaf,
+};
+
+/**
+ * is_string_instruction - Determine if instruction is a string instruction
+ * @insn:  Instruction structure containing the opcode
+ *
+ * Return: true if the instruction, determined by the opcode, is any of the
+ * string instructions as defined in the Intel Software Development manual.
+ * False otherwise.
+ */
+static bool is_string_instruction(struct insn *insn)
+{
+   insn_get_opcode(insn);
+
+   /* all string instructions have a 1-byte opcode */
+   if (insn->opcode.nbytes != 1)
+   return false;
+
+   switch (insn->opcode.bytes[0]) {
+   case INSB:
+   /* fall through */
+   case INSW_INSD:
+   /* fall through */
+   case OUTSB:
+   /* fall through */
+   case OUTSW_OUTSD:
+   /* fall through */
+   case MOVSB:
+   /* fall through */
+   case MOVSW_MOVSD:
+   /* fall through */
+   case CMPSB:
+   /* fall through */
+   case CMPSW_CMPSD:
+   /* fall through */
+   case STOSB:
+   /* fall through */
+   case STOSW_STOSD:
+   /* fall through */
+   case LODSB:
+   /* fall through */
+   case LODSW_LODSD:
+   /* fall through */
+   case SCASB:
+   /* fall through */
+   case SCASW_SCASD:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
  enum reg_type type)
 {
-- 
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