All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
To: Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>
Cc: 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>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	ricardo.neri@intel.com, Tony Luck <tony.luck@intel.com>,
	Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
	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: [PATCH v11 02/12] x86/insn-eval: Add support to resolve 32-bit address encodings
Date: Sun,  5 Nov 2017 18:27:47 -0800	[thread overview]
Message-ID: <1509935277-22138-3-git-send-email-ricardo.neri-calderon@linux.intel.com> (raw)
In-Reply-To: <1509935277-22138-1-git-send-email-ricardo.neri-calderon@linux.intel.com>

32-bit and 64-bit address encodings are identical. Thus, the same logic
could be used to resolve the effective address. However, there are two key
differences: address size and enforcement of segment limits.

If running a 32-bit process on a 64-bit kernel, it is best to perform
the address calculation using 32-bit data types. In this manner hardware
is used for the arithmetic, including handling of signs and overflows.

32-bit addresses are generally used in protected mode; segment limits are
enforced in this mode. This implementation obtains the limit of the
segment associated with the instruction operands and prefixes. If the
computed address is outside the segment limits, an error is returned. It
is also possible to use 32-bit address in long mode and virtual-8086 mode
by using an address override prefix. In such cases, segment limits are not
enforced.

Support to use 32-bit arithmetic is added to the utility functions that
compute effective addresses. However, the end result is stored in a
variable of type long (which has a width of 8 bytes in 64-bit builds).
Hence, once a 32-bit effective address is computed, the 4 most significant
bytes are masked out to avoid sign extension.

The newly added function get_addr_ref_32() is almost identical to the
existing function insn_get_addr_ref() (used for 64-bit addresses). The only
difference is that it verifies that the effective address is within the
limits of the segment.

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: Tony Luck <tony.luck@intel.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 | 112 ++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 106 insertions(+), 6 deletions(-)

diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index a4427b4..e6cb68a 100644
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -814,7 +814,11 @@ static int get_eff_addr_reg(struct insn *insn, struct pt_regs *regs,
 	if (*regoff < 0)
 		return -EINVAL;
 
-	*eff_addr = regs_get_register(regs, *regoff);
+	/* Ignore bytes that are outside the address size. */
+	if (insn->addr_bytes == 4)
+		*eff_addr = regs_get_register(regs, *regoff) & 0xffffffff;
+	else /* 64-bit address */
+		*eff_addr = regs_get_register(regs, *regoff);
 
 	return 0;
 }
@@ -846,7 +850,7 @@ static int get_eff_addr_modrm(struct insn *insn, struct pt_regs *regs,
 {
 	long tmp;
 
-	if (insn->addr_bytes != 8)
+	if (insn->addr_bytes != 8 && insn->addr_bytes != 4)
 		return -EINVAL;
 
 	insn_get_modrm(insn);
@@ -875,7 +879,13 @@ static int get_eff_addr_modrm(struct insn *insn, struct pt_regs *regs,
 		tmp = regs_get_register(regs, *regoff);
 	}
 
-	*eff_addr = tmp + insn->displacement.value;
+	if (insn->addr_bytes == 4) {
+		int addr32 = (int)(tmp & 0xffffffff) + insn->displacement.value;
+
+		*eff_addr = addr32 & 0xffffffff;
+	} else {
+		*eff_addr = tmp + insn->displacement.value;
+	}
 
 	return 0;
 }
@@ -908,7 +918,7 @@ static int get_eff_addr_sib(struct insn *insn, struct pt_regs *regs,
 	long base, indx;
 	int indx_offset;
 
-	if (insn->addr_bytes != 8)
+	if (insn->addr_bytes != 8 && insn->addr_bytes != 4)
 		return -EINVAL;
 
 	insn_get_modrm(insn);
@@ -946,12 +956,102 @@ static int get_eff_addr_sib(struct insn *insn, struct pt_regs *regs,
 	else
 		indx = regs_get_register(regs, indx_offset);
 
-	*eff_addr = base + indx * (1 << X86_SIB_SCALE(insn->sib.value));
+	if (insn->addr_bytes == 4) {
+		int addr32, base32, idx32;
+
+		base32 = base & 0xffffffff;
+		idx32 = indx & 0xffffffff;
 
-	*eff_addr += insn->displacement.value;
+		addr32 = base32 + idx32 * (1 << X86_SIB_SCALE(insn->sib.value));
+		addr32 += insn->displacement.value;
+
+		*eff_addr = addr32 & 0xffffffff;
+	} else {
+		*eff_addr = base + indx * (1 << X86_SIB_SCALE(insn->sib.value));
+		*eff_addr += insn->displacement.value;
+	}
 
 	return 0;
 }
+
+/**
+ * get_addr_ref_32() - Obtain a 32-bit linear address
+ * @insn:	Instruction with ModRM, SIB bytes and displacement
+ * @regs:	Register values as seen when entering kernel mode
+ *
+ * This function is to be used with 32-bit address encodings to obtain the
+ * linear memory address referred by the instruction's ModRM, SIB,
+ * displacement bytes and segment base address, as applicable. If in protected
+ * mode, segment limits are enforced.
+ *
+ * Returns:
+ *
+ * Linear address referenced by instruction and registers on success.
+ *
+ * -1L on error.
+ */
+static void __user *get_addr_ref_32(struct insn *insn, struct pt_regs *regs)
+{
+	unsigned long linear_addr = -1L, seg_base, seg_limit;
+	int eff_addr, regoff;
+	long tmp;
+	int ret;
+
+	if (insn->addr_bytes != 4)
+		goto out;
+
+	if (X86_MODRM_MOD(insn->modrm.value) == 3) {
+		ret = get_eff_addr_reg(insn, regs, &regoff, &tmp);
+		if (ret)
+			goto out;
+
+		eff_addr = tmp;
+
+	} else {
+		if (insn->sib.nbytes) {
+			ret = get_eff_addr_sib(insn, regs, &regoff, &tmp);
+			if (ret)
+				goto out;
+
+			eff_addr = tmp;
+		} else {
+			ret = get_eff_addr_modrm(insn, regs, &regoff, &tmp);
+			if (ret)
+				goto out;
+
+			eff_addr = tmp;
+		}
+	}
+
+	ret = get_seg_base_limit(insn, regs, regoff, &seg_base, &seg_limit);
+	if (ret)
+		goto out;
+
+	/*
+	 * In protected mode, before computing the linear address, make sure
+	 * the effective address is within the limits of the segment.
+	 * 32-bit addresses can be used in long and virtual-8086 modes if an
+	 * address override prefix is used. In such cases, segment limits are
+	 * not enforced. When in virtual-8086 mode, the segment limit is -1L
+	 * to reflect this situation.
+	 *
+	 * After computed, the effective address is treated as an unsigned
+	 * quantity.
+	 */
+	if (!user_64bit_mode(regs) && ((unsigned int)eff_addr > seg_limit))
+		goto out;
+
+	/*
+	 * Data type long could be 64 bits in size. Ensure that our 32-bit
+	 * effective address is not sign-extended when computing the linear
+	 * address.
+	 */
+	linear_addr = (unsigned long)(eff_addr & 0xffffffff) + seg_base;
+
+out:
+	return (void __user *)linear_addr;
+}
+
 /*
  * return the address being referenced be instruction
  * for rm=3 returning the content of the rm reg
-- 
2.7.4

  parent reply	other threads:[~2017-11-06  2:30 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-06  2:27 [PATCH v11 00/12] x86: Enable User-Mode Instruction Prevention Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 01/12] x86/insn-eval: Compute linear address in several utility functions Ricardo Neri
2017-11-08 10:57   ` [tip:x86/asm] " tip-bot for Ricardo Neri
2017-11-06  2:27 ` Ricardo Neri [this message]
2017-11-08 10:58   ` [tip:x86/asm] x86/insn-eval: Add support to resolve 32-bit address encodings tip-bot for Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 03/12] x86/insn-eval: Add wrapper function for 32 and 64-bit addresses Ricardo Neri
2017-11-08 10:58   ` [tip:x86/asm] " tip-bot for Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 04/12] x86/insn-eval: Handle 32-bit address encodings in virtual-8086 mode Ricardo Neri
2017-11-08 10:59   ` [tip:x86/asm] " tip-bot for Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 05/12] x86/insn-eval: Add support to resolve 16-bit address encodings Ricardo Neri
2017-11-08 10:59   ` [tip:x86/asm] " tip-bot for Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 06/12] x86/cpufeature: Add User-Mode Instruction Prevention definitions Ricardo Neri
2017-11-08 10:59   ` [tip:x86/asm] " tip-bot for Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 07/12] x86: Add emulation code for UMIP instructions Ricardo Neri
2017-11-08 11:00   ` [tip:x86/asm] x86/umip: " tip-bot for Ricardo Neri
2017-11-08 16:14     ` Denys Vlasenko
2017-11-08 16:34       ` Linus Torvalds
2017-11-08 16:38         ` H. Peter Anvin
2017-11-08 16:53         ` Denys Vlasenko
2017-11-08 16:57           ` Linus Torvalds
2017-11-08 17:09             ` Denys Vlasenko
2017-11-08 17:14               ` Paolo Bonzini
2017-11-08 17:24                 ` Denys Vlasenko
2017-11-09  6:17                 ` Ricardo Neri
2017-11-08 17:24           ` Alan Cox
2017-11-09  6:13         ` Ricardo Neri
2017-11-09  6:11       ` Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 08/12] x86/umip: Force a page fault when unable to copy emulated result to user Ricardo Neri
2017-11-08 11:00   ` [tip:x86/asm] " tip-bot for Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 09/12] x86: Enable User-Mode Instruction Prevention at runtime Ricardo Neri
2017-11-08  9:52   ` Ingo Molnar
2017-11-09  5:51     ` Ricardo Neri
2017-11-08 11:01   ` [tip:x86/asm] x86/umip: " tip-bot for Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 10/12] x86/traps: Fixup general protection faults caused by UMIP Ricardo Neri
2017-11-08 11:01   ` [tip:x86/asm] x86/traps: Fix up " tip-bot for Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 11/12] selftests/x86: Add tests for User-Mode Instruction Prevention Ricardo Neri
2017-11-08 11:02   ` [tip:x86/asm] " tip-bot for Ricardo Neri
2017-11-06  2:27 ` [PATCH v11 12/12] selftests/x86: Add tests for instruction str and sldt Ricardo Neri
2017-11-08 11:02   ` [tip:x86/asm] selftests/x86: Add tests for the STR and SLDT instructions tip-bot for Ricardo Neri
2017-11-08 10:00 ` [PATCH v11 00/12] x86: Enable User-Mode Instruction Prevention Thomas Gleixner
2017-11-09  5:46   ` Ricardo Neri

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=1509935277-22138-3-git-send-email-ricardo.neri-calderon@linux.intel.com \
    --to=ricardo.neri-calderon@linux.intel.com \
    --cc=acme@redhat.com \
    --cc=adam.buchbinder@gmail.com \
    --cc=adrian.hunter@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@suse.de \
    --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=hpa@zytor.com \
    --cc=jslaby@suse.cz \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@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@intel.com \
    --cc=shuah@kernel.org \
    --cc=slaoub@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    --cc=tony.luck@intel.com \
    --cc=vbabka@suse.cz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.