linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Brian Gerst <brgerst@gmail.com>,
	Chris Metcalf <cmetcalf@mellanox.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Huang Rui <ray.huang@amd.com>, Jiri Slaby <jslaby@suse.cz>,
	Jonathan Corbet <corbet@lwn.net>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Vlastimil Babka <vbabka@suse.cz>, Chen Yucong <slaoub@gmail.com>,
	Alexandre Julliard <julliard@winehq.org>,
	Stas Sergeev <stsp@list.ru>, Fenghua Yu <fenghua.yu@intel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-msdos@vger.kernel.org, wine-devel@winehq.org,
	Adam Buchbinder <adam.buchbinder@gmail.com>,
	Colin Ian King <colin.king@canonical.com>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	Qiaowei Ren <qiaowei.ren@intel.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Garnier <thgarnie@google.com>,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH v7 10/26] x86/insn-eval: Add utility functions to get segment selector
Date: Tue, 30 May 2017 12:35:21 +0200	[thread overview]
Message-ID: <20170530103521.fb3wvp4crqapremh@pd.tnic> (raw)
In-Reply-To: <20170505181724.55000-11-ricardo.neri-calderon@linux.intel.com>

On Fri, May 05, 2017 at 11:17:08AM -0700, Ricardo Neri wrote:
> When computing a linear address and segmentation is used, we need to know
> the base address of the segment involved in the computation. In most of
> the cases, the segment base address will be zero as in USER_DS/USER32_DS.
> However, it may be possible that a user space program defines its own
> segments via a local descriptor table. In such a case, the segment base
> address may not be zero .Thus, the segment base address is needed to
> calculate correctly the linear address.
> 
> The segment selector to be used when computing a linear address is
> determined by either any of segment override prefixes in the
> instruction or inferred from the registers involved in the computation of
> the effective address; in that order. Also, there are cases when the
> overrides shall be ignored (code segments are always selected by the CS
> segment register; string instructions always use the ES segment register
> along with the EDI register).
> 
> For clarity, this process can be split into two steps: resolving the
> relevant segment register to use and, once known, read its value to
> obtain the segment selector.
> 
> The method to obtain the segment selector depends on several factors. In
> 32-bit builds, segment selectors are saved into the pt_regs structure
> when switching to kernel mode. The same is also true for virtual-8086
> mode. In 64-bit builds, segmentation is mostly ignored, except when
> running a program in 32-bit legacy mode. In this case, CS and SS can be
> obtained from pt_regs. DS, ES, FS and GS can be read directly from
> the respective segment registers.
> 
> Lastly, the only two segment registers that are not ignored in long mode
> are FS and GS. In these two cases, base addresses are obtained from the
> respective MSRs.
> 
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
> Cc: Colin Ian King <colin.king@canonical.com>
> Cc: Lorenzo Stoakes <lstoakes@gmail.com>
> Cc: Qiaowei Ren <qiaowei.ren@intel.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Thomas Garnier <thgarnie@google.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Ravi V. Shankar <ravi.v.shankar@intel.com>
> Cc: x86@kernel.org
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
>  arch/x86/lib/insn-eval.c | 256 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 256 insertions(+)
> 
> diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
> index 1634762..0a496f4 100644
> --- a/arch/x86/lib/insn-eval.c
> +++ b/arch/x86/lib/insn-eval.c
> @@ -9,6 +9,7 @@
>  #include <asm/inat.h>
>  #include <asm/insn.h>
>  #include <asm/insn-eval.h>
> +#include <asm/vm86.h>
>  
>  enum reg_type {
>  	REG_TYPE_RM = 0,
> @@ -33,6 +34,17 @@ enum string_instruction {
>  	SCASW_SCASD	= 0xaf,
>  };
>  
> +enum segment_register {
> +	SEG_REG_INVAL = -1,
> +	SEG_REG_IGNORE = 0,
> +	SEG_REG_CS = 0x23,
> +	SEG_REG_SS = 0x36,
> +	SEG_REG_DS = 0x3e,
> +	SEG_REG_ES = 0x26,
> +	SEG_REG_FS = 0x64,
> +	SEG_REG_GS = 0x65,
> +};

Yuck, didn't we talk about this already?

Those are segment override prefixes so call them as such.

#define SEG_OVR_PFX_CS	0x23
#define SEG_OVR_PFX_SS	0x36
...

and we already have those!

arch/x86/include/asm/inat.h:
...
#define INAT_PFX_CS     5       /* 0x2E */
#define INAT_PFX_DS     6       /* 0x3E */
#define INAT_PFX_ES     7       /* 0x26 */
#define INAT_PFX_FS     8       /* 0x64 */
#define INAT_PFX_GS     9       /* 0x65 */
#define INAT_PFX_SS     10      /* 0x36 */

well, kinda, they're numbers there and not the actual prefix values.

And then there's:

arch/x86/kernel/uprobes.c::is_prefix_bad() which looks at some of those.

Please add your defines to inat.h and make that function is_prefix_bad()
use them instead of naked numbers. We need to pay attention to all those
different things needing to look at insn opcodes and not let them go
unwieldy by each defining and duplicating stuff.

>  /**
>   * is_string_instruction - Determine if instruction is a string instruction
>   * @insn:	Instruction structure containing the opcode
> @@ -83,6 +95,250 @@ static bool is_string_instruction(struct insn *insn)
>  	}
>  }
>  
> +/**
> + * resolve_seg_register() - obtain segment register

That function is still returning the segment override prefix and we use
*that* to determine the segment register.

> + * @insn:	Instruction structure with segment override prefixes
> + * @regs:	Structure with register values as seen when entering kernel mode
> + * @regoff:	Operand offset, in pt_regs, used to deterimine segment register
> + *
> + * The segment register to which an effective address refers depends on
> + * a) whether segment override prefixes must be ignored: always use CS when
> + * the register is (R|E)IP; always use ES when operand register is (E)DI with
> + * string instructions as defined in the Intel documentation. b) If segment
> + * overrides prefixes are used in the instruction instruction prefixes. C) Use
> + * the default segment register associated with the operand register.
> + *
> + * The operand register, regoff, is represented as the offset from the base of
> + * pt_regs. Also, regoff can be -EDOM for cases in which registers are not
> + * used as operands (e.g., displacement-only memory addressing).
> + *
> + * This function returns the segment register as value from an enumeration
> + * as per the conditions described above. Please note that this function
> + * does not return the value in the segment register (i.e., the segment
> + * selector). The segment selector needs to be obtained using
> + * get_segment_selector() and passing the segment register resolved by
> + * this function.
> + *
> + * Return: Enumerated segment register to use, among CS, SS, DS, ES, FS, GS,
> + * ignore (in 64-bit mode as applicable), or -EINVAL in case of error.
> + */
> +static enum segment_register resolve_seg_register(struct insn *insn,
> +						  struct pt_regs *regs,
> +						  int regoff)
> +{
> +	int i;
> +	int sel_overrides = 0;
> +	int seg_register = SEG_REG_IGNORE;
> +
> +	if (!insn)
> +		return SEG_REG_INVAL;
> +
> +	/* First handle cases when segment override prefixes must be ignored */
> +	if (regoff == offsetof(struct pt_regs, ip)) {
> +		if (user_64bit_mode(regs))
> +			return SEG_REG_IGNORE;
> +		else
> +			return SEG_REG_CS;
> +		return SEG_REG_CS;

Simplify:

		if (user_64bit_mode(regs))
			return SEG_REG_IGNORE;

		return SEG_REG_CS;

> +	}
> +
> +	/*
> +	 * If the (E)DI register is used with string instructions, the ES
> +	 * segment register is always used.
> +	 */
> +	if ((regoff == offsetof(struct pt_regs, di)) &&
> +	    is_string_instruction(insn)) {
> +		if (user_64bit_mode(regs))
> +			return SEG_REG_IGNORE;
> +		else
> +			return SEG_REG_ES;
> +		return SEG_REG_CS;

What is that second return actually supposed to do?

> +	}
> +
> +	/* Then check if we have segment overrides prefixes*/

Missing space and fullstop: "... overrides prefixes. */"

> +	for (i = 0; i < insn->prefixes.nbytes; i++) {
> +		switch (insn->prefixes.bytes[i]) {
> +		case SEG_REG_CS:
> +			seg_register = SEG_REG_CS;
> +			sel_overrides++;
> +			break;
> +		case SEG_REG_SS:
> +			seg_register = SEG_REG_SS;
> +			sel_overrides++;
> +			break;
> +		case SEG_REG_DS:
> +			seg_register = SEG_REG_DS;
> +			sel_overrides++;
> +			break;
> +		case SEG_REG_ES:
> +			seg_register = SEG_REG_ES;
> +			sel_overrides++;
> +			break;
> +		case SEG_REG_FS:
> +			seg_register = SEG_REG_FS;
> +			sel_overrides++;
> +			break;
> +		case SEG_REG_GS:
> +			seg_register = SEG_REG_GS;
> +			sel_overrides++;
> +			break;
> +		default:
> +			return SEG_REG_INVAL;

So SEG_REG_NONE or so? It is not invalid if it is not a segment override
prefix.

> +	/*
> +	 * Having more than one segment override prefix leads to undefined
> +	 * behavior. If this is the case, return with error.
> +	 */
> +	if (sel_overrides > 1)
> +		return SEG_REG_INVAL;

Yuck, wrapping of -E value in a SEG_REG enum. Just return -EINVAL here
and make the function return an int, not that ugly enum.

And the return convention should be straight-forward: default segment if
no prefix or ignored, -EINVAL if error and the actual override prefix if
present.

Also, that test should be *after* the user_64bit_mode() because in long
mode, segment overrides get ignored. IOW, those three if-tests around here
should be combined into a single one, i.e., something like this:

	if (64-bit) {
		if (!FS || !GS)
			ignore
		else
			return seg_override_pfx;	<--- Yes, that variable should be called seg_override_pfx to denote what it is.
	} else if (sel_overrides > 1)
		-EINVAL
	else if (sel_overrides)
		return seg_override_pfx;

> +
> +	if (sel_overrides == 1) {
> +		/*
> +		 * If in long mode all segment registers but FS and GS are
> +		 * ignored.
> +		 */
> +		if (user_64bit_mode(regs) && !(seg_register == SEG_REG_FS ||
> +					       seg_register == SEG_REG_GS))
> +			return SEG_REG_IGNORE;
> +
> +		return seg_register;
> +	}
> +
> +	/* In long mode, all segment registers except FS and GS are ignored */
> +	if (user_64bit_mode(regs))
> +		return SEG_REG_IGNORE;
> +
> +	/*
> +	 * Lastly, if no segment overrides were found, determine the default
> +	 * segment register as described in the Intel documentation: SS for
> +	 * (E)SP or (E)BP. DS for all data references, AX, CX and DX are not
> +	 * valid register operands in 16-bit address encodings.
> +	 * -EDOM is reserved to identify for cases in which no register is used
> +	 * the default segment register (displacement-only addressing). The
> +	 * default segment register used in these cases is DS.
> +	 */
> +
> +	switch (regoff) {
> +	case offsetof(struct pt_regs, ax):
> +		/* fall through */
> +	case offsetof(struct pt_regs, cx):
> +		/* fall through */
> +	case offsetof(struct pt_regs, dx):
> +		if (insn && insn->addr_bytes == 2)
> +			return SEG_REG_INVAL;
> +	case offsetof(struct pt_regs, di):
> +		/* fall through */
> +	case -EDOM:
> +		/* fall through */
> +	case offsetof(struct pt_regs, bx):
> +		/* fall through */
> +	case offsetof(struct pt_regs, si):
> +		return SEG_REG_DS;
> +	case offsetof(struct pt_regs, bp):
> +		/* fall through */
> +	case offsetof(struct pt_regs, sp):
> +		return SEG_REG_SS;
> +	case offsetof(struct pt_regs, ip):
> +		return SEG_REG_CS;
> +	default:
> +		return SEG_REG_INVAL;
> +	}

So group all the fall through cases together so that you don't have this
dense block of code with "/* fall through */" on every other line.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

  reply	other threads:[~2017-05-30 10:35 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 18:16 [PATCH v7 00/26] x86: Enable User-Mode Instruction Prevention Ricardo Neri
2017-05-05 18:16 ` [PATCH v7 01/26] ptrace,x86: Make user_64bit_mode() available to 32-bit builds Ricardo Neri
2017-05-21 14:19   ` Borislav Petkov
2017-05-05 18:17 ` [PATCH v7 02/26] x86/mm: Relocate page fault error codes to traps.h Ricardo Neri
2017-05-21 14:23   ` Borislav Petkov
2017-05-27  3:40     ` Ricardo Neri
2017-05-27 10:13       ` Borislav Petkov
2017-06-01  3:09         ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 03/26] x86/mpx: Use signed variables to compute effective addresses Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 04/26] x86/mpx: Do not use SIB.index if its value is 100b and ModRM.mod is not 11b Ricardo Neri
2017-05-24 13:37   ` Borislav Petkov
2017-05-27  3:36     ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 05/26] x86/mpx: Do not use SIB.base if its value is 101b and ModRM.mod = 0 Ricardo Neri
2017-05-29 13:07   ` Borislav Petkov
2017-06-06  6:08     ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 06/26] x86/mpx, x86/insn: Relocate insn util functions to a new insn-eval file Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type Ricardo Neri
2017-05-29 16:37   ` Borislav Petkov
2017-06-06  6:06     ` Ricardo Neri
2017-06-06 11:58       ` Borislav Petkov
2017-06-07  0:28         ` Ricardo Neri
2017-06-07 12:21           ` Borislav Petkov
2017-05-05 18:17 ` [PATCH v7 08/26] x86/insn-eval: Add a utility function to get register offsets Ricardo Neri
2017-05-29 17:16   ` Borislav Petkov
2017-06-06  6:02     ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 09/26] x86/insn-eval: Add utility function to identify string instructions Ricardo Neri
2017-05-29 21:48   ` Borislav Petkov
2017-06-06  6:01     ` Ricardo Neri
2017-06-06 12:04       ` Borislav Petkov
2017-05-05 18:17 ` [PATCH v7 10/26] x86/insn-eval: Add utility functions to get segment selector Ricardo Neri
2017-05-30 10:35   ` Borislav Petkov [this message]
2017-06-15 18:37     ` Ricardo Neri
2017-06-15 19:04       ` Ricardo Neri
2017-06-19 15:29         ` Borislav Petkov
2017-06-19 15:37       ` Borislav Petkov
2017-05-05 18:17 ` [PATCH v7 11/26] x86/insn-eval: Add utility function to get segment descriptor Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 12/26] x86/insn-eval: Add utility functions to get segment descriptor base address and limit Ricardo Neri
2017-05-31 16:58   ` Borislav Petkov
2017-06-03 17:23     ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 13/26] x86/insn-eval: Add function to get default params of code segment Ricardo Neri
2017-06-07 12:59   ` Borislav Petkov
2017-06-15 19:24     ` Ricardo Neri
2017-06-19 17:11       ` Borislav Petkov
2017-05-05 18:17 ` [PATCH v7 14/26] x86/insn-eval: Indicate a 32-bit displacement if ModRM.mod is 0 and ModRM.rm is 5 Ricardo Neri
2017-06-07 13:15   ` Borislav Petkov
2017-06-15 19:36     ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 15/26] x86/insn-eval: Incorporate segment base and limit in linear address computation Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 16/26] x86/insn-eval: Support both signed 32-bit and 64-bit effective addresses Ricardo Neri
2017-06-07 15:48   ` Borislav Petkov
2017-07-25 23:48     ` Ricardo Neri
2017-07-27 13:26       ` Borislav Petkov
2017-07-28  2:04         ` Ricardo Neri
2017-07-28  6:50           ` Borislav Petkov
2017-06-07 15:49   ` Borislav Petkov
2017-06-15 19:58     ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 17/26] x86/insn-eval: Handle 32-bit address encodings in virtual-8086 mode Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 18/26] x86/insn-eval: Add support to resolve 16-bit addressing encodings Ricardo Neri
2017-06-07 16:28   ` Borislav Petkov
2017-06-15 21:50     ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 19/26] x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 20/26] x86/cpufeature: Add User-Mode Instruction Prevention definitions Ricardo Neri
2017-05-06  9:04   ` Paolo Bonzini
2017-05-11  3:23     ` Ricardo Neri
2017-06-07 18:24   ` Borislav Petkov
2017-05-05 18:17 ` [PATCH v7 21/26] x86: Add emulation code for UMIP instructions Ricardo Neri
2017-06-08 18:38   ` Borislav Petkov
2017-06-17  1:34     ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 22/26] x86/umip: Force a page fault when unable to copy emulated result to user Ricardo Neri
2017-06-09 11:02   ` Borislav Petkov
2017-07-25 23:50     ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 23/26] x86/traps: Fixup general protection faults caused by UMIP Ricardo Neri
2017-06-09 13:02   ` Borislav Petkov
2017-07-25 23:51     ` Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 24/26] x86: Enable User-Mode Instruction Prevention Ricardo Neri
2017-06-09 16:10   ` Borislav Petkov
2017-07-26  0:44     ` Ricardo Neri
2017-07-27 13:57       ` Borislav Petkov
2017-05-05 18:17 ` [PATCH v7 25/26] selftests/x86: Add tests for " Ricardo Neri
2017-05-05 18:17 ` [PATCH v7 26/26] selftests/x86: Add tests for instruction str and sldt Ricardo Neri
2017-05-17 18:42 ` [PATCH v7 00/26] x86: Enable User-Mode Instruction Prevention Ricardo Neri
2017-05-27  3:49   ` Neri, Ricardo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170530103521.fb3wvp4crqapremh@pd.tnic \
    --to=bp@suse.de \
    --cc=acme@redhat.com \
    --cc=adam.buchbinder@gmail.com \
    --cc=adrian.hunter@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=brgerst@gmail.com \
    --cc=cmetcalf@mellanox.com \
    --cc=colin.king@canonical.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=jslaby@suse.cz \
    --cc=julliard@winehq.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-msdos@vger.kernel.org \
    --cc=lstoakes@gmail.com \
    --cc=luto@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qiaowei.ren@intel.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=ray.huang@amd.com \
    --cc=ricardo.neri-calderon@linux.intel.com \
    --cc=shuah@kernel.org \
    --cc=slaoub@gmail.com \
    --cc=stsp@list.ru \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    --cc=vbabka@suse.cz \
    --cc=wine-devel@winehq.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).