Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1594751 > unrolled thread

[v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

Back to article view | Back to linux.kernel

Contents

  [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 09/21] x86/insn-eval: Add functions to get default operand and address sizes Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 03/21] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0 Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 08/21] x86/insn-eval: Add utility function to get segment descriptor base address Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 15/21] x86/mm: Relocate page fault error codes to traps.h Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
      Re: [v6 PATCH 15/21] x86/mm: Relocate page fault error codes to traps.h Andy Lutomirski <luto@amacapital.net> - 2017-03-08 17:10 +0100
    [v6 PATCH 11/21] insn/eval: Incorporate segment base in address computation Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 16/21] x86/cpufeature: Add User-Mode Instruction Prevention definitions Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 21/21] selftests/x86: Add tests for User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
      Re: [v6 PATCH 21/21] selftests/x86: Add tests for User-Mode  Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-08 17:30 +0100
        Re: [v6 PATCH 21/21] selftests/x86: Add tests for User-Mode  Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 00:40 +0100
    [v6 PATCH 01/21] x86/mpx: Use signed variables to compute effective addresses Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 20/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 13/21] x86/insn-eval: Add support to resolve 16-bit addressing encodings Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 17/21] x86: Add emulation code for UMIP instructions Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 05/21] x86/insn-eval: Add utility functions to get register offsets Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 12/21] x86/insn: Support both signed 32-bit and 64-bit effective addresses Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 07/21] x86/insn-eval: Add utility function to get segment descriptor Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 18/21] x86/umip: Force a page fault when unable to copy emulated result to user Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 14/21] x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 06/21] x86/insn-eval: Add utility functions to get segment selector Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 02:00 +0100
    [v6 PATCH 02/21] x86/mpx: Do not use SIB index if index points to R/ESP Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 02:00 +0100
    [v6 PATCH 19/21] x86/traps: Fixup general protection faults caused by UMIP Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 02:00 +0100
      Re: [v6 PATCH 19/21] x86/traps: Fixup general protection faults  caused by UMIP Andy Lutomirski <luto@amacapital.net> - 2017-03-08 17:00 +0100
    [v6 PATCH 10/21] x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 02:10 +0100
    [v6 PATCH 04/21] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 04:50 +0100
    Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-08 15:30 +0100
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-08 18:00 +0100
        Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-09 02:20 +0100
          Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-09 23:10 +0100
          Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@kernel.org> - 2017-03-10 03:50 +0100
            Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-10 22:00 +0100
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-10 22:10 +0100
                Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-10 22:40 +0100
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-08 18:20 +0100
        Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-09 02:20 +0100
          Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-09 23:20 +0100
            Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-10 03:50 +0100
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-10 12:40 +0100
                Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-10 15:20 +0100
                  Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 02:30 +0100
                Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 01:10 +0100
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 01:00 +0100
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-08 23:30 +0100
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-08 23:50 +0100
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-09 02:50 +0100
        Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-10 02:30 +0100
          Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 00:50 +0100
            Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-11 01:00 +0100
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 01:20 +0100
    Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-08 17:20 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1594772 — [v6 PATCH 06/21] x86/insn-eval: Add utility functions to get segment selector

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

For clarity, this process can be split into two steps: resolving the
relevant segment and, once known, read the applicable 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
registers. Lastly, segmentation is possible in 64-bit mode via FS and GS.
In these two cases, base addresses are obtained from the relevant 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 | 195 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 195 insertions(+)

diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index 78df1c9..8d45df8 100644
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -8,6 +8,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,
@@ -15,6 +16,200 @@ enum reg_type {
 	REG_TYPE_BASE,
 };
 
+enum segment {
+	SEG_CS = 0x23,
+	SEG_SS = 0x36,
+	SEG_DS = 0x3e,
+	SEG_ES = 0x26,
+	SEG_FS = 0x64,
+	SEG_GS = 0x65
+};
+
+/**
+ * resolve_seg_selector() - obtain segment selector
+ * @regs:	Set of registers containing the segment selector
+ * @insn:	Instruction structure with selector override prefixes
+ * @regoff:	Operand offset, in pt_regs, of which the selector is needed
+ * @default:	Resolve default segment selector (i.e., ignore overrides)
+ *
+ * The segment selector to which an effective address refers depends on
+ * a) segment selector overrides instruction prefixes or b) the operand
+ * register indicated in the ModRM or SiB byte.
+ *
+ * For case a), the function inspects any prefixes in the insn instruction;
+ * insn can be null to indicate that selector override prefixes shall be
+ * ignored. This is useful when the use of prefixes is forbidden (e.g.,
+ * obtaining the code selector). For case b), the operand register shall be
+ * represented as the offset from the base address of pt_regs. Also, regoff
+ * can be -EINVAL for cases in which registers are not used as operands (e.g.,
+ * when the mod and r/m parts of the ModRM byte are 0 and 5, respectively).
+ *
+ * This function returns the segment selector to utilize as per the conditions
+ * described above. Please note that this functin does not return the value
+ * of the segment selector. The value of the segment selector needs to be
+ * obtained using get_segment_selector and passing the segment selector type
+ * resolved by this function.
+ *
+ * Return: Segment selector to use, among CS, SS, DS, ES, FS or GS.
+ */
+static int resolve_seg_selector(struct insn *insn, int regoff, bool get_default)
+{
+	int i;
+
+	if (!insn)
+		return -EINVAL;
+
+	if (get_default)
+		goto default_seg;
+	/*
+	 * Check first if we have selector overrides. Having more than
+	 * one selector override leads to undefined behavior. We
+	 * only use the first one and return
+	 */
+	for (i = 0; i < insn->prefixes.nbytes; i++) {
+		switch (insn->prefixes.bytes[i]) {
+		case SEG_CS:
+			return SEG_CS;
+		case SEG_SS:
+			return SEG_SS;
+		case SEG_DS:
+			return SEG_DS;
+		case SEG_ES:
+			return SEG_ES;
+		case SEG_FS:
+			return SEG_FS;
+		case SEG_GS:
+			return SEG_GS;
+		default:
+			return -EINVAL;
+		}
+	}
+
+default_seg:
+	/*
+	 * If no overrides, use default selectors as described in the
+	 * Intel documentation: SS for ESP or EBP. DS for all data references,
+	 * except when relative to stack or string destination.
+	 * Also, AX, CX and DX are not valid register operands in 16-bit
+	 * address encodings.
+	 * Callers must interpret the result correctly according to the type
+	 * of instructions (e.g., use ES for string instructions).
+	 * Also, some values of modrm and sib might seem to indicate the use
+	 * of EBP and ESP (e.g., modrm_mod = 0, modrm_rm = 5) but actually
+	 * they refer to cases in which only a displacement used. These cases
+	 * should be indentified by the caller and not with this function.
+	 */
+	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 -EINVAL;
+	case -EDOM: /* no register involved in address computation */
+	case offsetof(struct pt_regs, bx):
+		/* fall through */
+	case offsetof(struct pt_regs, di):
+		/* fall through */
+	case offsetof(struct pt_regs, si):
+		return SEG_DS;
+	case offsetof(struct pt_regs, bp):
+		/* fall through */
+	case offsetof(struct pt_regs, sp):
+		return SEG_SS;
+	case offsetof(struct pt_regs, ip):
+		return SEG_CS;
+	default:
+		return -EINVAL;
+	}
+}
+
+/**
+ * get_segment_selector() - obtain segment selector
+ * @regs:	Set of registers containing the segment selector
+ * @seg_type:	Type of segment selector to obtain
+ * @regoff:	Operand offset, in pt_regs, of which the selector is needed
+ *
+ * Obtain the segment selector for any of CS, SS, DS, ES, FS, GS. In
+ * CONFIG_X86_32, the segment is obtained from either pt_regs or
+ * kernel_vm86_regs as applicable. In CONFIG_X86_64, CS and SS are obtained
+ * from pt_regs. DS, ES, FS and GS are obtained by reading the ds and es, fs
+ * and gs, respectively.
+ *
+ * Return: Value of the segment selector
+ */
+static unsigned short get_segment_selector(struct pt_regs *regs,
+					   enum segment seg_type)
+{
+#ifdef CONFIG_X86_64
+	unsigned short seg_sel;
+
+	switch (seg_type) {
+	case SEG_CS:
+		return (unsigned short)(regs->cs & 0xffff);
+	case SEG_SS:
+		return (unsigned short)(regs->ss & 0xffff);
+	case SEG_DS:
+		savesegment(ds, seg_sel);
+		return seg_sel;
+	case SEG_ES:
+		savesegment(es, seg_sel);
+		return seg_sel;
+	case SEG_FS:
+		savesegment(fs, seg_sel);
+		return seg_sel;
+	case SEG_GS:
+		savesegment(gs, seg_sel);
+		return seg_sel;
+	default:
+		return -1;
+	}
+#else /* CONFIG_X86_32 */
+	struct kernel_vm86_regs *vm86regs = (struct kernel_vm86_regs *)regs;
+
+	if (v8086_mode(regs)) {
+		switch (seg_type) {
+		case SEG_CS:
+			return (unsigned short)(regs->cs & 0xffff);
+		case SEG_SS:
+			return (unsigned short)(regs->ss & 0xffff);
+		case SEG_DS:
+			return vm86regs->ds;
+		case SEG_ES:
+			return vm86regs->es;
+		case SEG_FS:
+			return vm86regs->fs;
+		case SEG_GS:
+			return vm86regs->gs;
+		default:
+			return -1;
+		}
+	}
+
+	switch (seg_type) {
+	case SEG_CS:
+		return (unsigned short)(regs->cs & 0xffff);
+	case SEG_SS:
+		return (unsigned short)(regs->ss & 0xffff);
+	case SEG_DS:
+		return (unsigned short)(regs->ds & 0xffff);
+	case SEG_ES:
+		return (unsigned short)(regs->es & 0xffff);
+	case SEG_FS:
+		return (unsigned short)(regs->fs & 0xffff);
+	case SEG_GS:
+		/*
+		 * GS may or may not be in regs as per CONFIG_X86_32_LAZY_GS.
+		 * The macro below takes care of both cases.
+		 */
+		return get_user_gs(regs);
+	default:
+		return -1;
+	}
+#endif /* CONFIG_X86_64 */
+}
+
 static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
 			  enum reg_type type)
 {
-- 
2.9.3

[toc] | [prev] | [next] | [standalone]

#1594773 — [v6 PATCH 02/21] x86/mpx: Do not use SIB index if index points to R/ESP

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when memory addressing is used
(i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of
the SIB byte points to the R/ESP (i.e., index = 4), the index should not be
used in the computation of the memory address.

In these cases the address is simply the value present in the register
pointed by the base part of the SIB byte plus the displacement byte.

An example of such instruction could be

    insn -0x80(%rsp)

This is represented as:

     [opcode] 4c 23 80

      ModR/M=0x4c: mod: 0x1, reg: 0x1: r/m: 0x4(R/ESP)
      SIB=0x23: sc: 0, index: 0x100(R/ESP), base: 0x11(R/EBX):
      Displacement -0x80

The correct address is (base) + displacement; no index is used.

We can achieve the desired effect of not using the index by making
get_reg_offset return -EDOM in this particular case. This value indicates
callers that they should not use the index to calculate the address.
EINVAL continues to indicate that an error when decoding the SIB byte.

Care is taken to allow R12 to be used as index, which is a valid scenario.

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: Peter Zijlstra <peterz@infradead.org>
Cc: Nathan Howard <liverlint@gmail.com>
Cc: Adan Hawthorn <adanhawthorn@gmail.com>
Cc: Joe Perches <joe@perches.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/mm/mpx.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index ff112e3..d9e92d6 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -110,6 +110,13 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
 		regno = X86_SIB_INDEX(insn->sib.value);
 		if (X86_REX_X(insn->rex_prefix.value))
 			regno += 8;
+		/*
+		 * If mod !=3, register R/ESP (regno=4) is not used as index in
+		 * the address computation. Check is done after looking at REX.X
+		 * This is because R12 (regno=12) can be used as an index.
+		 */
+		if (regno == 4 && X86_MODRM_MOD(insn->modrm.value) != 3)
+			return -EDOM;
 		break;
 
 	case REG_TYPE_BASE:
@@ -159,11 +166,19 @@ static void __user *mpx_get_addr_ref(struct insn *insn, struct pt_regs *regs)
 				goto out_err;
 
 			indx_offset = get_reg_offset(insn, regs, REG_TYPE_INDEX);
-			if (indx_offset < 0)
+			/*
+			 * A negative offset generally means a error, except
+			 * -EDOM, which means that the contents of the register
+			 * should not be used as index.
+			 */
+			if (unlikely(indx_offset == -EDOM))
+				indx = 0;
+			else if (unlikely(indx_offset < 0))
 				goto out_err;
+			else
+				indx = regs_get_register(regs, indx_offset);
 
 			base = regs_get_register(regs, base_offset);
-			indx = regs_get_register(regs, indx_offset);
 			eff_addr = base + indx * (1 << X86_SIB_SCALE(sib));
 		} else {
 			addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
-- 
2.9.3

[toc] | [prev] | [next] | [standalone]

#1594779 — [v6 PATCH 19/21] x86/traps: Fixup general protection faults caused by UMIP

If the User-Mode Instruction Prevention CPU feature is available and
enabled, a general protection fault will be issued if the instructions
sgdt, sldt, sidt, str or smsw are executed from user-mode context
(CPL > 0). If the fault was caused by any of the instructions protected
by UMIP, fixup_umip_exception will emulate dummy results for these
instructions. If emulation is successful, the result is passed to the
user space program and no SIGSEGV signal is emitted.

Please note that fixup_umip_exception also caters for the case when
the fault originated while running in virtual-8086 mode.

Cc: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Chen Yucong <slaoub@gmail.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi V. Shankar <ravi.v.shankar@intel.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Liang Z. Li <liang.z.li@intel.com>
Cc: Alexandre Julliard <julliard@winehq.org>
Cc: Stas Sergeev <stsp@list.ru>
Cc: x86@kernel.org
Cc: linux-msdos@vger.kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
 arch/x86/kernel/traps.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 948443e..86efbcb 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -65,6 +65,7 @@
 #include <asm/trace/mpx.h>
 #include <asm/mpx.h>
 #include <asm/vm86.h>
+#include <asm/umip.h>
 
 #ifdef CONFIG_X86_64
 #include <asm/x86_init.h>
@@ -492,6 +493,9 @@ do_general_protection(struct pt_regs *regs, long error_code)
 	RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
 	cond_local_irq_enable(regs);
 
+	if (user_mode(regs) && fixup_umip_exception(regs))
+		return;
+
 	if (v8086_mode(regs)) {
 		local_irq_enable();
 		handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code);
-- 
2.9.3

[toc] | [prev] | [next] | [standalone]

#1595313 — Re: [v6 PATCH 19/21] x86/traps: Fixup general protection faults caused by UMIP

On Tue, Mar 7, 2017 at 4:32 PM, Ricardo Neri
<ricardo.neri-calderon@linux.intel.com> wrote:
> If the User-Mode Instruction Prevention CPU feature is available and
> enabled, a general protection fault will be issued if the instructions
> sgdt, sldt, sidt, str or smsw are executed from user-mode context
> (CPL > 0). If the fault was caused by any of the instructions protected
> by UMIP, fixup_umip_exception will emulate dummy results for these
> instructions. If emulation is successful, the result is passed to the
> user space program and no SIGSEGV signal is emitted.
>
> Please note that fixup_umip_exception also caters for the case when
> the fault originated while running in virtual-8086 mode.

Reviewed-by: Andy Lutomirski <luto@kernel.org>

[toc] | [prev] | [next] | [standalone]

#1594782 — [v6 PATCH 10/21] x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero

Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when the mod part of the ModRM
byte is zero and R/EBP is specified in the R/M part of such bit, the value
of the aforementioned register should not be used in the address
computation. Instead, a 32-bit displacement is expected. The instruction
decoder takes care of setting the displacement to the expected value.
Returning -EDOM signals callers that they should ignore the value of such
register when computing the address encoded in the instruction operands.

Also, callers should exercise care to correctly interpret this particular
case. In IA-32e 64-bit mode, the address is given by the displacement plus
the value of the RIP. In IA-32e compatibility mode, the value of EIP is
ignored. This correction is done for our insn_get_addr_ref.

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 | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index cda6c71..ea10b03 100644
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -250,6 +250,14 @@ 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);
+		/* if mod=0, register R/EBP is not used in the address
+		 * computation. Instead, a 32-bit displacement is expected;
+		 * the instruction decoder takes care of reading such
+		 * displacement. This is true for both R/EBP and R13, as the
+		 * REX.B bit is not decoded.
+		 */
+		if (regno == 5 && X86_MODRM_MOD(insn->modrm.value) == 0)
+			return -EDOM;
 		if (X86_REX_B(insn->rex_prefix.value))
 			regno += 8;
 		break;
@@ -599,9 +607,22 @@ 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.
+			 * The only case in which we see this value is when
+			 * R/M points to R/EBP. In such a case, in 64-bit mode
+			 * the effective address is relative to tho RIP.
+			 */
+			if (addr_offset == -EDOM) {
+				eff_addr = 0;
+#ifdef CONFIG_X86_64
+				if (user_64bit_mode(regs))
+					eff_addr = (long)regs->ip;
+#endif
+			} 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

[toc] | [prev] | [next] | [standalone]

#1594830 — [v6 PATCH 04/21] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel

Other kernel submodules can benefit from using the utility functions
defined in mpx.c to obtain the addresses and values of operands contained
in the general purpose registers. An instance of this is the emulation code
used for instructions protected by the Intel User-Mode Instruction
Prevention feature.

Thus, these functions are relocated to a new insn-eval.c file. The reason
to not relocate these utilities into insn.c is that the latter solely
analyses instructions given by a struct insn without any knowledge of the
meaning of the values of instruction operands. This new utility insn-
eval.c aims to be used to resolve effective and userspace linear addresses
based on the contents of the instruction operands as well as the contents
of pt_regs structure.

These utilities come with a separate header. This is to avoid taking insn.c
out of sync from the instructions decoders under tools/obj and tools/perf.
This also avoids adding cumbersome #ifdef's for the #include'd files
required to decode instructions in a kernel context.

Functions are simply relocated. There are not functional or indentation
changes.

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/include/asm/insn-eval.h |  16 ++++
 arch/x86/lib/Makefile            |   2 +-
 arch/x86/lib/insn-eval.c         | 160 +++++++++++++++++++++++++++++++++++++++
 arch/x86/mm/mpx.c                | 153 +------------------------------------
 4 files changed, 179 insertions(+), 152 deletions(-)
 create mode 100644 arch/x86/include/asm/insn-eval.h
 create mode 100644 arch/x86/lib/insn-eval.c

diff --git a/arch/x86/include/asm/insn-eval.h b/arch/x86/include/asm/insn-eval.h
new file mode 100644
index 0000000..5cab1b1
--- /dev/null
+++ b/arch/x86/include/asm/insn-eval.h
@@ -0,0 +1,16 @@
+#ifndef _ASM_X86_INSN_EVAL_H
+#define _ASM_X86_INSN_EVAL_H
+/*
+ * A collection of utility functions for x86 instruction analysis to be
+ * used in a kernel context. Useful when, for instance, making sense
+ * of the registers indicated by operands.
+ */
+
+#include <linux/compiler.h>
+#include <linux/bug.h>
+#include <linux/err.h>
+#include <asm/ptrace.h>
+
+void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs);
+
+#endif /* _ASM_X86_INSN_EVAL_H */
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 34a7413..675d7b0 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -23,7 +23,7 @@ lib-y := delay.o misc.o cmdline.o cpu.o
 lib-y += usercopy_$(BITS).o usercopy.o getuser.o putuser.o
 lib-y += memcpy_$(BITS).o
 lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
-lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o
+lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o insn-eval.o
 lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
 
 obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
new file mode 100644
index 0000000..23cf010
--- /dev/null
+++ b/arch/x86/lib/insn-eval.c
@@ -0,0 +1,160 @@
+/*
+ * Utility functions for x86 operand and address decoding
+ *
+ * Copyright (C) Intel Corporation 2017
+ */
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <asm/inat.h>
+#include <asm/insn.h>
+#include <asm/insn-eval.h>
+
+enum reg_type {
+	REG_TYPE_RM = 0,
+	REG_TYPE_INDEX,
+	REG_TYPE_BASE,
+};
+
+static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
+			  enum reg_type type)
+{
+	int regno = 0;
+
+	static const int regoff[] = {
+		offsetof(struct pt_regs, ax),
+		offsetof(struct pt_regs, cx),
+		offsetof(struct pt_regs, dx),
+		offsetof(struct pt_regs, bx),
+		offsetof(struct pt_regs, sp),
+		offsetof(struct pt_regs, bp),
+		offsetof(struct pt_regs, si),
+		offsetof(struct pt_regs, di),
+#ifdef CONFIG_X86_64
+		offsetof(struct pt_regs, r8),
+		offsetof(struct pt_regs, r9),
+		offsetof(struct pt_regs, r10),
+		offsetof(struct pt_regs, r11),
+		offsetof(struct pt_regs, r12),
+		offsetof(struct pt_regs, r13),
+		offsetof(struct pt_regs, r14),
+		offsetof(struct pt_regs, r15),
+#endif
+	};
+	int nr_registers = ARRAY_SIZE(regoff);
+	/*
+	 * Don't possibly decode a 32-bit instructions as
+	 * reading a 64-bit-only register.
+	 */
+	if (IS_ENABLED(CONFIG_X86_64) && !insn->x86_64)
+		nr_registers -= 8;
+
+	switch (type) {
+	case REG_TYPE_RM:
+		regno = X86_MODRM_RM(insn->modrm.value);
+		if (X86_REX_B(insn->rex_prefix.value))
+			regno += 8;
+		break;
+
+	case REG_TYPE_INDEX:
+		regno = X86_SIB_INDEX(insn->sib.value);
+		if (X86_REX_X(insn->rex_prefix.value))
+			regno += 8;
+		/*
+		 * If mod !=3, register R/ESP (regno=4) is not used as index in
+		 * the address computation. Check is done after looking at REX.X
+		 * This is because R12 (regno=12) can be used as an index.
+		 */
+		if (regno == 4 && X86_MODRM_MOD(insn->modrm.value) != 3)
+			return -EDOM;
+		break;
+
+	case REG_TYPE_BASE:
+		regno = X86_SIB_BASE(insn->sib.value);
+		/*
+		 * If mod is 0 and register R/EBP (regno=5) is indicated in the
+		 * base part of the SIB byte, the value of such register should
+		 * not be used in the address computation. Also, a 32-bit
+		 * displacement is expected in this case; the instruction
+		 * decoder takes care of it. This is true for both R13 and
+		 * R/EBP as REX.B will not be decoded.
+		 */
+		if (regno == 5 && X86_MODRM_MOD(insn->modrm.value) == 0)
+			return -EDOM;
+
+		if (X86_REX_B(insn->rex_prefix.value))
+			regno += 8;
+		break;
+
+	default:
+		pr_err("invalid register type");
+		BUG();
+		break;
+	}
+
+	if (regno >= nr_registers) {
+		WARN_ONCE(1, "decoded an instruction with an invalid register");
+		return -EINVAL;
+	}
+	return regoff[regno];
+}
+
+/*
+ * return the address being referenced be instruction
+ * for rm=3 returning the content of the rm reg
+ * for rm!=3 calculates the address using SIB and Disp
+ */
+void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs)
+{
+	unsigned long linear_addr;
+	long eff_addr, base, indx;
+	int addr_offset, base_offset, indx_offset;
+	insn_byte_t sib;
+
+	insn_get_modrm(insn);
+	insn_get_sib(insn);
+	sib = insn->sib.value;
+
+	if (X86_MODRM_MOD(insn->modrm.value) == 3) {
+		addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
+		if (addr_offset < 0)
+			goto out_err;
+		eff_addr = regs_get_register(regs, addr_offset);
+	} else {
+		if (insn->sib.nbytes) {
+			/*
+			 * Negative values in the base and index offset means
+			 * an error when decoding the SIB byte. Except -EDOM,
+			 * which means that the registers should not be used
+			 * in the address computation.
+			 */
+			base_offset = get_reg_offset(insn, regs, REG_TYPE_BASE);
+			if (unlikely(base_offset == -EDOM))
+				base = 0;
+			else if (unlikely(base_offset < 0))
+				goto out_err;
+			else
+				base = regs_get_register(regs, base_offset);
+
+			indx_offset = get_reg_offset(insn, regs, REG_TYPE_INDEX);
+			if (unlikely(indx_offset == -EDOM))
+				indx = 0;
+			else if (unlikely(indx_offset < 0))
+				goto out_err;
+			else
+				indx = regs_get_register(regs, indx_offset);
+
+			eff_addr = base + indx * (1 << X86_SIB_SCALE(sib));
+		} else {
+			addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
+			if (addr_offset < 0)
+				goto out_err;
+			eff_addr = regs_get_register(regs, addr_offset);
+		}
+		eff_addr += insn->displacement.value;
+	}
+	linear_addr = (unsigned long)eff_addr;
+
+	return (void __user *)linear_addr;
+out_err:
+	return (void __user *)-1;
+}
diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index ef7eb67..4c3efd6 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -12,6 +12,7 @@
 #include <linux/sched/sysctl.h>
 
 #include <asm/insn.h>
+#include <asm/insn-eval.h>
 #include <asm/mman.h>
 #include <asm/mmu_context.h>
 #include <asm/mpx.h>
@@ -60,156 +61,6 @@ static unsigned long mpx_mmap(unsigned long len)
 	return addr;
 }
 
-enum reg_type {
-	REG_TYPE_RM = 0,
-	REG_TYPE_INDEX,
-	REG_TYPE_BASE,
-};
-
-static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
-			  enum reg_type type)
-{
-	int regno = 0;
-
-	static const int regoff[] = {
-		offsetof(struct pt_regs, ax),
-		offsetof(struct pt_regs, cx),
-		offsetof(struct pt_regs, dx),
-		offsetof(struct pt_regs, bx),
-		offsetof(struct pt_regs, sp),
-		offsetof(struct pt_regs, bp),
-		offsetof(struct pt_regs, si),
-		offsetof(struct pt_regs, di),
-#ifdef CONFIG_X86_64
-		offsetof(struct pt_regs, r8),
-		offsetof(struct pt_regs, r9),
-		offsetof(struct pt_regs, r10),
-		offsetof(struct pt_regs, r11),
-		offsetof(struct pt_regs, r12),
-		offsetof(struct pt_regs, r13),
-		offsetof(struct pt_regs, r14),
-		offsetof(struct pt_regs, r15),
-#endif
-	};
-	int nr_registers = ARRAY_SIZE(regoff);
-	/*
-	 * Don't possibly decode a 32-bit instructions as
-	 * reading a 64-bit-only register.
-	 */
-	if (IS_ENABLED(CONFIG_X86_64) && !insn->x86_64)
-		nr_registers -= 8;
-
-	switch (type) {
-	case REG_TYPE_RM:
-		regno = X86_MODRM_RM(insn->modrm.value);
-		if (X86_REX_B(insn->rex_prefix.value))
-			regno += 8;
-		break;
-
-	case REG_TYPE_INDEX:
-		regno = X86_SIB_INDEX(insn->sib.value);
-		if (X86_REX_X(insn->rex_prefix.value))
-			regno += 8;
-		/*
-		 * If mod !=3, register R/ESP (regno=4) is not used as index in
-		 * the address computation. Check is done after looking at REX.X
-		 * This is because R12 (regno=12) can be used as an index.
-		 */
-		if (regno == 4 && X86_MODRM_MOD(insn->modrm.value) != 3)
-			return -EDOM;
-		break;
-
-	case REG_TYPE_BASE:
-		regno = X86_SIB_BASE(insn->sib.value);
-		/*
-		 * If mod is 0 and register R/EBP (regno=5) is indicated in the
-		 * base part of the SIB byte, the value of such register should
-		 * not be used in the address computation. Also, a 32-bit
-		 * displacement is expected in this case; the instruction
-		 * decoder takes care of it. This is true for both R13 and
-		 * R/EBP as REX.B will not be decoded.
-		 */
-		if (regno == 5 && X86_MODRM_MOD(insn->modrm.value) == 0)
-			return -EDOM;
-
-		if (X86_REX_B(insn->rex_prefix.value))
-			regno += 8;
-		break;
-
-	default:
-		pr_err("invalid register type");
-		BUG();
-		break;
-	}
-
-	if (regno >= nr_registers) {
-		WARN_ONCE(1, "decoded an instruction with an invalid register");
-		return -EINVAL;
-	}
-	return regoff[regno];
-}
-
-/*
- * return the address being referenced be instruction
- * for rm=3 returning the content of the rm reg
- * for rm!=3 calculates the address using SIB and Disp
- */
-static void __user *mpx_get_addr_ref(struct insn *insn, struct pt_regs *regs)
-{
-	unsigned long linear_addr;
-	long eff_addr, base, indx;
-	int addr_offset, base_offset, indx_offset;
-	insn_byte_t sib;
-
-	insn_get_modrm(insn);
-	insn_get_sib(insn);
-	sib = insn->sib.value;
-
-	if (X86_MODRM_MOD(insn->modrm.value) == 3) {
-		addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
-		if (addr_offset < 0)
-			goto out_err;
-		eff_addr = regs_get_register(regs, addr_offset);
-	} else {
-		if (insn->sib.nbytes) {
-			/*
-			 * Negative values in the base and index offset means
-			 * an error when decoding the SIB byte. Except -EDOM,
-			 * which means that the registers should not be used
-			 * in the address computation.
-			 */
-			base_offset = get_reg_offset(insn, regs, REG_TYPE_BASE);
-			if (unlikely(base_offset == -EDOM))
-				base = 0;
-			else if (unlikely(base_offset < 0))
-				goto out_err;
-			else
-				base = regs_get_register(regs, base_offset);
-
-			indx_offset = get_reg_offset(insn, regs, REG_TYPE_INDEX);
-			if (unlikely(indx_offset == -EDOM))
-				indx = 0;
-			else if (unlikely(indx_offset < 0))
-				goto out_err;
-			else
-				indx = regs_get_register(regs, indx_offset);
-
-			eff_addr = base + indx * (1 << X86_SIB_SCALE(sib));
-		} else {
-			addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
-			if (addr_offset < 0)
-				goto out_err;
-			eff_addr = regs_get_register(regs, addr_offset);
-		}
-		eff_addr += insn->displacement.value;
-	}
-	linear_addr = (unsigned long)eff_addr;
-
-	return (void __user *)linear_addr;
-out_err:
-	return (void __user *)-1;
-}
-
 static int mpx_insn_decode(struct insn *insn,
 			   struct pt_regs *regs)
 {
@@ -322,7 +173,7 @@ siginfo_t *mpx_generate_siginfo(struct pt_regs *regs)
 	info->si_signo = SIGSEGV;
 	info->si_errno = 0;
 	info->si_code = SEGV_BNDERR;
-	info->si_addr = mpx_get_addr_ref(&insn, regs);
+	info->si_addr = insn_get_addr_ref(&insn, regs);
 	/*
 	 * We were not able to extract an address from the instruction,
 	 * probably because there was something invalid in it.
-- 
2.9.3

[toc] | [prev] | [next] | [standalone]

#1595219

08.03.2017 03:32, Ricardo Neri пишет:
> These are the instructions covered by UMIP:
> * SGDT - Store Global Descriptor Table
> * SIDT - Store Interrupt Descriptor Table
> * SLDT - Store Local Descriptor Table
> * SMSW - Store Machine Status Word
> * STR - Store Task Register
>
> This patchset initially treated tasks running in virtual-8086 mode as a
> special case. However, I received clarification that DOSEMU[8] does not
> support applications that use these instructions.
Yes, this is the case.
But at least in the past there was an attempt to
support SLDT as it is used by an ancient pharlap
DOS extender (currently unsupported by dosemu1/2).
So how difficult would it be to add an optional
possibility of delivering such SIGSEGV to userspace
so that the kernel's dummy emulation can be overridden?
It doesn't need to be a matter of this particular
patch set, i.e. this proposal should not trigger a
v7 resend of all 21 patches. :) But it would be useful
for the future development of dosemu2.

[toc] | [prev] | [next] | [standalone]

#1595381

08.03.2017 19:46, Andy Lutomirski пишет:
>> No no, since I meant prot mode, this is not what I need.
>> I would never need to disable UMIP as to allow the
>> prot mode apps to do SLDT. Instead it would be good
>> to have an ability to provide a replacement for the dummy
>> emulation that is currently being proposed for kernel.
>> All is needed for this, is just to deliver a SIGSEGV.
> That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
> turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
> GP exit).
But then I am confused with the word "compat" in
your "COMPAT_MASK0_X86_UMIP_FIXUP" and
"sys_adjust_compat_mask(int op, int word, u32 mask);"

Leaving UMIP on and only disabling a fixup doesn't
sound like a compat option to me. I would expect
compat to disable it completely.

[toc] | [prev] | [next] | [standalone]

#1595620

On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
> 08.03.2017 19:46, Andy Lutomirski пишет:
> >> No no, since I meant prot mode, this is not what I need.
> >> I would never need to disable UMIP as to allow the
> >> prot mode apps to do SLDT. Instead it would be good
> >> to have an ability to provide a replacement for the dummy
> >> emulation that is currently being proposed for kernel.
> >> All is needed for this, is just to deliver a SIGSEGV.
> > That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
> > turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
> > GP exit).
> But then I am confused with the word "compat" in
> your "COMPAT_MASK0_X86_UMIP_FIXUP" and
> "sys_adjust_compat_mask(int op, int word, u32 mask);"
> 
> Leaving UMIP on and only disabling a fixup doesn't
> sound like a compat option to me. I would expect
> compat to disable it completely.

I guess that the _UMIP_FIXUP part makes it clear that emulation, not
UMIP is disabled, allowing the SIGSEGV be delivered to the user space
program.

Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
COMPAT_MASK0_X86_UMIP to disable UMIP make sense?

Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
purpose? Applications could simply use this compat mask to bypass UMIP
and gain access to the instructions it protects.

Thanks and BR,
Ricardo

[toc] | [prev] | [next] | [standalone]

#1596408

09.03.2017 04:11, Ricardo Neri пишет:
> On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
>> 08.03.2017 19:46, Andy Lutomirski пишет:
>>>> No no, since I meant prot mode, this is not what I need.
>>>> I would never need to disable UMIP as to allow the
>>>> prot mode apps to do SLDT. Instead it would be good
>>>> to have an ability to provide a replacement for the dummy
>>>> emulation that is currently being proposed for kernel.
>>>> All is needed for this, is just to deliver a SIGSEGV.
>>> That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
>>> turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
>>> GP exit).
>> But then I am confused with the word "compat" in
>> your "COMPAT_MASK0_X86_UMIP_FIXUP" and
>> "sys_adjust_compat_mask(int op, int word, u32 mask);"
>>
>> Leaving UMIP on and only disabling a fixup doesn't
>> sound like a compat option to me. I would expect
>> compat to disable it completely.
> I guess that the _UMIP_FIXUP part makes it clear that emulation, not
> UMIP is disabled, allowing the SIGSEGV be delivered to the user space
> program.
>
> Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
> COMPAT_MASK0_X86_UMIP to disable UMIP make sense?
>
> Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
> purpose? Applications could simply use this compat mask to bypass UMIP
> and gain access to the instructions it protects.
I don't think someone will want to completely disable
UMIP, so why do you need such functionality?
My question was only what does "compat" mean
in "COMPAT_MASK0_X86_UMIP_FIXUP", compat with what.

[toc] | [prev] | [next] | [standalone]

#1596583

On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
<ricardo.neri-calderon@linux.intel.com> wrote:
> On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
>> 08.03.2017 19:46, Andy Lutomirski пишет:
>> >> No no, since I meant prot mode, this is not what I need.
>> >> I would never need to disable UMIP as to allow the
>> >> prot mode apps to do SLDT. Instead it would be good
>> >> to have an ability to provide a replacement for the dummy
>> >> emulation that is currently being proposed for kernel.
>> >> All is needed for this, is just to deliver a SIGSEGV.
>> > That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
>> > turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
>> > GP exit).
>> But then I am confused with the word "compat" in
>> your "COMPAT_MASK0_X86_UMIP_FIXUP" and
>> "sys_adjust_compat_mask(int op, int word, u32 mask);"
>>
>> Leaving UMIP on and only disabling a fixup doesn't
>> sound like a compat option to me. I would expect
>> compat to disable it completely.
>
> I guess that the _UMIP_FIXUP part makes it clear that emulation, not
> UMIP is disabled, allowing the SIGSEGV be delivered to the user space
> program.
>
> Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
> COMPAT_MASK0_X86_UMIP to disable UMIP make sense?
>
> Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
> purpose? Applications could simply use this compat mask to bypass UMIP
> and gain access to the instructions it protects.
>

I was obviously extremely unclear.  The point of the proposed syscall
is to let programs opt out of legacy features.  So there would be a
bit to disable emulation of UMIP-blocked instructions (this giving the
unadulterated #GP).  There would not be a bit to disable UMIP itself.

There's also a flaw in my proposal.  Disable-vsyscall would be per-mm
and disable-umip-emulation would be per-task, so they'd need to be in
separate words to make any sense.  I'll ponder this a bit more.

[toc] | [prev] | [next] | [standalone]

#1598087

10.03.2017 05:41, Andy Lutomirski пишет:
> On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
> <ricardo.neri-calderon@linux.intel.com> wrote:
>> On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
>>> 08.03.2017 19:46, Andy Lutomirski пишет:
>>>>> No no, since I meant prot mode, this is not what I need.
>>>>> I would never need to disable UMIP as to allow the
>>>>> prot mode apps to do SLDT. Instead it would be good
>>>>> to have an ability to provide a replacement for the dummy
>>>>> emulation that is currently being proposed for kernel.
>>>>> All is needed for this, is just to deliver a SIGSEGV.
>>>> That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
>>>> turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
>>>> GP exit).
>>> But then I am confused with the word "compat" in
>>> your "COMPAT_MASK0_X86_UMIP_FIXUP" and
>>> "sys_adjust_compat_mask(int op, int word, u32 mask);"
>>>
>>> Leaving UMIP on and only disabling a fixup doesn't
>>> sound like a compat option to me. I would expect
>>> compat to disable it completely.
>> I guess that the _UMIP_FIXUP part makes it clear that emulation, not
>> UMIP is disabled, allowing the SIGSEGV be delivered to the user space
>> program.
>>
>> Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
>> COMPAT_MASK0_X86_UMIP to disable UMIP make sense?
>>
>> Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
>> purpose? Applications could simply use this compat mask to bypass UMIP
>> and gain access to the instructions it protects.
>>
> I was obviously extremely unclear.  The point of the proposed syscall
> is to let programs opt out of legacy features.
I guess both "compat" and "legacy" are misleading
here. Maybe these are "x86-specific" or "hypervisor-specific",
but a mere enabling of UMIP doesn't immediately make
the use of SLDT instruction a legacy IMHO.

>   I'll ponder this a bit more.
So if we are to invent something new, it would be nice to
also think up a clear terminology for it. Maybe something
like "X86_FEATURE_xxx_MASK" or alike.

[toc] | [prev] | [next] | [standalone]

#1598088

On Fri, Mar 10, 2017 at 2:30 AM, Stas Sergeev <stsp@list.ru> wrote:
> 10.03.2017 05:41, Andy Lutomirski пишет:
>
>> On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
>> <ricardo.neri-calderon@linux.intel.com> wrote:
>>>
>>> On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
>>>>
>>>> 08.03.2017 19:46, Andy Lutomirski пишет:
>>>>>>
>>>>>> No no, since I meant prot mode, this is not what I need.
>>>>>> I would never need to disable UMIP as to allow the
>>>>>> prot mode apps to do SLDT. Instead it would be good
>>>>>> to have an ability to provide a replacement for the dummy
>>>>>> emulation that is currently being proposed for kernel.
>>>>>> All is needed for this, is just to deliver a SIGSEGV.
>>>>>
>>>>> That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
>>>>> turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
>>>>> GP exit).
>>>>
>>>> But then I am confused with the word "compat" in
>>>> your "COMPAT_MASK0_X86_UMIP_FIXUP" and
>>>> "sys_adjust_compat_mask(int op, int word, u32 mask);"
>>>>
>>>> Leaving UMIP on and only disabling a fixup doesn't
>>>> sound like a compat option to me. I would expect
>>>> compat to disable it completely.
>>>
>>> I guess that the _UMIP_FIXUP part makes it clear that emulation, not
>>> UMIP is disabled, allowing the SIGSEGV be delivered to the user space
>>> program.
>>>
>>> Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
>>> COMPAT_MASK0_X86_UMIP to disable UMIP make sense?
>>>
>>> Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
>>> purpose? Applications could simply use this compat mask to bypass UMIP
>>> and gain access to the instructions it protects.
>>>
>> I was obviously extremely unclear.  The point of the proposed syscall
>> is to let programs opt out of legacy features.
>
> I guess both "compat" and "legacy" are misleading
> here. Maybe these are "x86-specific" or "hypervisor-specific",
> but a mere enabling of UMIP doesn't immediately make
> the use of SLDT instruction a legacy IMHO.

Sure it is. :)  Using SLDT from user mode is a legacy ability that
just happens to still work on existing CPUs and kernels.  Once UMIP
goes in, it will officially be obsolete -- it will just be supported
for backwards compatibility.  New code should opt out and emulate in
usermode if needed.  (And the vast, vast majority of Linux programs
don't use these instructions in the first place.)

Similarly, vsyscalls were obsolete the as soon as better alternatives
were fully supported and the kernel started making them slow, and the
fact that new static glibc programs still used them for a little while
didn't make them any less obsolete.

>
>>   I'll ponder this a bit more.
>
> So if we are to invent something new, it would be nice to
> also think up a clear terminology for it. Maybe something
> like "X86_FEATURE_xxx_MASK" or alike.

But they're misfeatures, not features.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

[toc] | [prev] | [next] | [standalone]

#1598120

11.03.2017 00:04, Andy Lutomirski пишет:
> On Fri, Mar 10, 2017 at 2:30 AM, Stas Sergeev <stsp@list.ru> wrote:
>> 10.03.2017 05:41, Andy Lutomirski пишет:
>>
>>> On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
>>> <ricardo.neri-calderon@linux.intel.com> wrote:
>>>> On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
>>>>> 08.03.2017 19:46, Andy Lutomirski пишет:
>>>>>>> No no, since I meant prot mode, this is not what I need.
>>>>>>> I would never need to disable UMIP as to allow the
>>>>>>> prot mode apps to do SLDT. Instead it would be good
>>>>>>> to have an ability to provide a replacement for the dummy
>>>>>>> emulation that is currently being proposed for kernel.
>>>>>>> All is needed for this, is just to deliver a SIGSEGV.
>>>>>> That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
>>>>>> turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
>>>>>> GP exit).
>>>>> But then I am confused with the word "compat" in
>>>>> your "COMPAT_MASK0_X86_UMIP_FIXUP" and
>>>>> "sys_adjust_compat_mask(int op, int word, u32 mask);"
>>>>>
>>>>> Leaving UMIP on and only disabling a fixup doesn't
>>>>> sound like a compat option to me. I would expect
>>>>> compat to disable it completely.
>>>> I guess that the _UMIP_FIXUP part makes it clear that emulation, not
>>>> UMIP is disabled, allowing the SIGSEGV be delivered to the user space
>>>> program.
>>>>
>>>> Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
>>>> COMPAT_MASK0_X86_UMIP to disable UMIP make sense?
>>>>
>>>> Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
>>>> purpose? Applications could simply use this compat mask to bypass UMIP
>>>> and gain access to the instructions it protects.
>>>>
>>> I was obviously extremely unclear.  The point of the proposed syscall
>>> is to let programs opt out of legacy features.
>> I guess both "compat" and "legacy" are misleading
>> here. Maybe these are "x86-specific" or "hypervisor-specific",
>> but a mere enabling of UMIP doesn't immediately make
>> the use of SLDT instruction a legacy IMHO.
> Sure it is. :)  Using SLDT from user mode is a legacy ability that
> just happens to still work on existing CPUs and kernels.  Once UMIP
> goes in, it will officially be obsolete
Yes, but the names you suggest, imply that "UMIP_FIXUP"
is legacy or compat, which I find misleading because it have
just appeared. Maybe something like "COMPAT_X86_UMIP_INSNS_EMU"?

[toc] | [prev] | [next] | [standalone]

#1595399

On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev <stsp@list.ru> wrote:
> 08.03.2017 19:06, Andy Lutomirski пишет:
>>
>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>
>>> 08.03.2017 03:32, Ricardo Neri пишет:
>>>>
>>>> These are the instructions covered by UMIP:
>>>> * SGDT - Store Global Descriptor Table
>>>> * SIDT - Store Interrupt Descriptor Table
>>>> * SLDT - Store Local Descriptor Table
>>>> * SMSW - Store Machine Status Word
>>>> * STR - Store Task Register
>>>>
>>>> This patchset initially treated tasks running in virtual-8086 mode as a
>>>> special case. However, I received clarification that DOSEMU[8] does not
>>>> support applications that use these instructions.
>>
>> Can you remind me what was special about it?  It looks like you still
>> emulate them in v8086 mode.
>
> Indeed, sorry, I meant prot mode here. :)
> So I wonder what was cited to be special about v86.

Not sure.  Ricardo?

>
>>> Yes, this is the case.
>>> But at least in the past there was an attempt to
>>> support SLDT as it is used by an ancient pharlap
>>> DOS extender (currently unsupported by dosemu1/2).
>>> So how difficult would it be to add an optional
>>> possibility of delivering such SIGSEGV to userspace
>>> so that the kernel's dummy emulation can be overridden?
>>> It doesn't need to be a matter of this particular
>>> patch set, i.e. this proposal should not trigger a
>>> v7 resend of all 21 patches. :) But it would be useful
>>> for the future development of dosemu2.
>>
>> What I'd actually like to see is a totally separate patchset that adds
>> an inheritable (but reset on exec) per-task mask of legacy
>> compatibility features to disable.  Maybe:
>>
>> sys_adjust_compat_mask(int op, int word, u32 mask);
>
> No no, since I meant prot mode, this is not what I need.
> I would never need to disable UMIP as to allow the
> prot mode apps to do SLDT. Instead it would be good
> to have an ability to provide a replacement for the dummy
> emulation that is currently being proposed for kernel.
> All is needed for this, is just to deliver a SIGSEGV.

That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
GP exit).

--Andy

[toc] | [prev] | [next] | [standalone]

#1595617

On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev <stsp@list.ru> wrote:
> > 08.03.2017 19:06, Andy Lutomirski пишет:
> >>
> >> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> wrote:
> >>>
> >>> 08.03.2017 03:32, Ricardo Neri пишет:
> >>>>
> >>>> These are the instructions covered by UMIP:
> >>>> * SGDT - Store Global Descriptor Table
> >>>> * SIDT - Store Interrupt Descriptor Table
> >>>> * SLDT - Store Local Descriptor Table
> >>>> * SMSW - Store Machine Status Word
> >>>> * STR - Store Task Register
> >>>>
> >>>> This patchset initially treated tasks running in virtual-8086
> mode as a
> >>>> special case. However, I received clarification that DOSEMU[8]
> does not
> >>>> support applications that use these instructions.
> >>
> >> Can you remind me what was special about it?  It looks like you
> still
> >> emulate them in v8086 mode.
> >
> > Indeed, sorry, I meant prot mode here. :)
> > So I wonder what was cited to be special about v86.

Initially my patches disabled UMIP on virtual-8086 instructions, without
regards of protected mode (i.e., UMIP was always enabled). I didn't have
emulation at the time. Then, I added emulation code that now covers
protected and virtual-8086 modes. I guess it is not special anymore.

Thanks and BR,
Ricardo

[toc] | [prev] | [next] | [standalone]

#1596422

09.03.2017 04:15, Ricardo Neri пишет:
> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
>> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev <stsp@list.ru> wrote:
>>> 08.03.2017 19:06, Andy Lutomirski пишет:
>>>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>>> 08.03.2017 03:32, Ricardo Neri пишет:
>>>>>> These are the instructions covered by UMIP:
>>>>>> * SGDT - Store Global Descriptor Table
>>>>>> * SIDT - Store Interrupt Descriptor Table
>>>>>> * SLDT - Store Local Descriptor Table
>>>>>> * SMSW - Store Machine Status Word
>>>>>> * STR - Store Task Register
>>>>>>
>>>>>> This patchset initially treated tasks running in virtual-8086
>> mode as a
>>>>>> special case. However, I received clarification that DOSEMU[8]
>> does not
>>>>>> support applications that use these instructions.
>>>> Can you remind me what was special about it?  It looks like you
>> still
>>>> emulate them in v8086 mode.
>>> Indeed, sorry, I meant prot mode here. :)
>>> So I wonder what was cited to be special about v86.
> Initially my patches disabled UMIP on virtual-8086 instructions, without
> regards of protected mode (i.e., UMIP was always enabled). I didn't have
> emulation at the time. Then, I added emulation code that now covers
> protected and virtual-8086 modes. I guess it is not special anymore.
But isn't SLDT&friends just throw UD in v86?
How does UMIP affect this? How does your patch affect
this?

[toc] | [prev] | [next] | [standalone]

#1596581

On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev <stsp@list.ru> wrote:
> 09.03.2017 04:15, Ricardo Neri пишет:
>
>> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
>>>
>>> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>>
>>>> 08.03.2017 19:06, Andy Lutomirski пишет:
>>>>>
>>>>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>
>>>>>> 08.03.2017 03:32, Ricardo Neri пишет:
>>>>>>>
>>>>>>> These are the instructions covered by UMIP:
>>>>>>> * SGDT - Store Global Descriptor Table
>>>>>>> * SIDT - Store Interrupt Descriptor Table
>>>>>>> * SLDT - Store Local Descriptor Table
>>>>>>> * SMSW - Store Machine Status Word
>>>>>>> * STR - Store Task Register
>>>>>>>
>>>>>>> This patchset initially treated tasks running in virtual-8086
>>>
>>> mode as a
>>>>>>>
>>>>>>> special case. However, I received clarification that DOSEMU[8]
>>>
>>> does not
>>>>>>>
>>>>>>> support applications that use these instructions.
>>>>>
>>>>> Can you remind me what was special about it?  It looks like you
>>>
>>> still
>>>>>
>>>>> emulate them in v8086 mode.
>>>>
>>>> Indeed, sorry, I meant prot mode here. :)
>>>> So I wonder what was cited to be special about v86.
>>
>> Initially my patches disabled UMIP on virtual-8086 instructions, without
>> regards of protected mode (i.e., UMIP was always enabled). I didn't have
>> emulation at the time. Then, I added emulation code that now covers
>> protected and virtual-8086 modes. I guess it is not special anymore.
>
> But isn't SLDT&friends just throw UD in v86?
> How does UMIP affect this? How does your patch affect
> this?

Er, right.  Ricardo, your code may need fixing.  But don't you have a
test case for this?  The behavior should be the same with and without
your patches applied.  The exception is #UD, not #GP, so maybe your
code just never executes in the vm86 case.

--Andy

[toc] | [prev] | [next] | [standalone]

#1597165

10.03.2017 05:39, Andy Lutomirski пишет:
> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 09.03.2017 04:15, Ricardo Neri пишет:
>>
>>> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
>>>> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>>> 08.03.2017 19:06, Andy Lutomirski пишет:
>>>>>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>> 08.03.2017 03:32, Ricardo Neri пишет:
>>>>>>>> These are the instructions covered by UMIP:
>>>>>>>> * SGDT - Store Global Descriptor Table
>>>>>>>> * SIDT - Store Interrupt Descriptor Table
>>>>>>>> * SLDT - Store Local Descriptor Table
>>>>>>>> * SMSW - Store Machine Status Word
>>>>>>>> * STR - Store Task Register
>>>>>>>>
>>>>>>>> This patchset initially treated tasks running in virtual-8086
>>>> mode as a
>>>>>>>> special case. However, I received clarification that DOSEMU[8]
>>>> does not
>>>>>>>> support applications that use these instructions.
>>>>>> Can you remind me what was special about it?  It looks like you
>>>> still
>>>>>> emulate them in v8086 mode.
>>>>> Indeed, sorry, I meant prot mode here. :)
>>>>> So I wonder what was cited to be special about v86.
>>> Initially my patches disabled UMIP on virtual-8086 instructions, without
>>> regards of protected mode (i.e., UMIP was always enabled). I didn't have
>>> emulation at the time. Then, I added emulation code that now covers
>>> protected and virtual-8086 modes. I guess it is not special anymore.
>> But isn't SLDT&friends just throw UD in v86?
>> How does UMIP affect this? How does your patch affect
>> this?
> Er, right.  Ricardo, your code may need fixing.  But don't you have a
> test case for this?
Why would you need one?
Or do you really want to allow these instructions
in v86 by the means of emulation? If so - this wasn't
clearly stated in the patch description, neither it was
properly discussed, it seems.

[toc] | [prev] | [next] | [standalone]

#1597785

On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeev <stsp@list.ru> wrote:
> 10.03.2017 05:39, Andy Lutomirski пишет:
>
>> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>
>>> 09.03.2017 04:15, Ricardo Neri пишет:
>>>
>>>> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
>>>>>
>>>>> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>
>>>>>> 08.03.2017 19:06, Andy Lutomirski пишет:
>>>>>>>
>>>>>>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>>
>>>>>>>> 08.03.2017 03:32, Ricardo Neri пишет:
>>>>>>>>>
>>>>>>>>> These are the instructions covered by UMIP:
>>>>>>>>> * SGDT - Store Global Descriptor Table
>>>>>>>>> * SIDT - Store Interrupt Descriptor Table
>>>>>>>>> * SLDT - Store Local Descriptor Table
>>>>>>>>> * SMSW - Store Machine Status Word
>>>>>>>>> * STR - Store Task Register
>>>>>>>>>
>>>>>>>>> This patchset initially treated tasks running in virtual-8086
>>>>>
>>>>> mode as a
>>>>>>>>>
>>>>>>>>> special case. However, I received clarification that DOSEMU[8]
>>>>>
>>>>> does not
>>>>>>>>>
>>>>>>>>> support applications that use these instructions.
>>>>>>>
>>>>>>> Can you remind me what was special about it?  It looks like you
>>>>>
>>>>> still
>>>>>>>
>>>>>>> emulate them in v8086 mode.
>>>>>>
>>>>>> Indeed, sorry, I meant prot mode here. :)
>>>>>> So I wonder what was cited to be special about v86.
>>>>
>>>> Initially my patches disabled UMIP on virtual-8086 instructions, without
>>>> regards of protected mode (i.e., UMIP was always enabled). I didn't have
>>>> emulation at the time. Then, I added emulation code that now covers
>>>> protected and virtual-8086 modes. I guess it is not special anymore.
>>>
>>> But isn't SLDT&friends just throw UD in v86?
>>> How does UMIP affect this? How does your patch affect
>>> this?
>>
>> Er, right.  Ricardo, your code may need fixing.  But don't you have a
>> test case for this?
>
> Why would you need one?
> Or do you really want to allow these instructions
> in v86 by the means of emulation? If so - this wasn't
> clearly stated in the patch description, neither it was
> properly discussed, it seems.

What I meant was: if the patches incorrectly started making these
instructions work in vm86 mode where they used to cause a vm86 exit,
then that's a bug that the selftest should have caught.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web