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>,
Liang Z Li <liang.z.li@intel.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.kern
Subject: [v5 10/20] x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero
Date: Fri, 3 Mar 2017 13:41:22 -0800 [thread overview]
Message-ID: <20170303214132.77244-11-ricardo.neri-calderon@linux.intel.com> (raw)
In-Reply-To: <20170303214132.77244-1-ricardo.neri-calderon@linux.intel.com>
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
next prev parent reply other threads:[~2017-03-03 21:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-03 21:41 [v5 00/20] x86: Enable User-Mode Instruction Prevention Ricardo Neri
2017-03-03 21:41 ` [v5 01/20] x86/mpx: Use signed variables to compute effective addresses Ricardo Neri
2017-03-03 21:41 ` [v5 02/20] x86/mpx: Do not use SIB index if index points to R/ESP Ricardo Neri
2017-03-03 21:41 ` [v5 03/20] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0 Ricardo Neri
2017-03-03 21:41 ` [v5 04/20] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel Ricardo Neri
2017-03-03 21:41 ` [v5 05/20] x86/insn-eval: Add utility functions to get register offsets Ricardo Neri
2017-03-03 21:41 ` [v5 06/20] x86/insn-eval: Add utility functions to get segment selector Ricardo Neri
2017-03-03 21:41 ` [v5 07/20] x86/insn-eval: Add utility function to get segment descriptor Ricardo Neri
2017-03-03 21:41 ` [v5 08/20] x86/insn-eval: Add utility function to get segment descriptor base address Ricardo Neri
2017-03-03 21:41 ` [v5 09/20] x86/insn-eval: Add functions to get default operand and address sizes Ricardo Neri
2017-03-03 21:41 ` Ricardo Neri [this message]
2017-03-03 21:41 ` [v5 11/20] insn/eval: Incorporate segment base in address computation Ricardo Neri
2017-03-03 21:41 ` [v5 12/20] x86/insn: Support both signed 32-bit and 64-bit effective addresses Ricardo Neri
2017-03-03 21:41 ` [v5 13/20] x86/insn-eval: Add support to resolve 16-bit addressing encodings Ricardo Neri
2017-03-03 21:41 ` [v5 14/20] x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings Ricardo Neri
2017-03-03 21:41 ` [v5 15/20] x86/cpufeature: Add User-Mode Instruction Prevention definitions Ricardo Neri
2017-03-03 21:41 ` [v5 16/20] x86: Add emulation code for UMIP instructions Ricardo Neri
2017-03-03 21:41 ` [v5 17/20] x86/umip: Force a page fault when unable to copy emulated result to user Ricardo Neri
2017-03-05 16:18 ` Andy Lutomirski
2017-03-07 0:26 ` Ricardo Neri
2017-03-03 21:41 ` [v5 18/20] x86/traps: Fixup general protection faults caused by UMIP Ricardo Neri
2017-03-03 21:41 ` [v5 19/20] x86: Enable User-Mode Instruction Prevention Ricardo Neri
2017-03-03 21:41 ` [v5 20/20] selftests/x86: Add tests for " 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=20170303214132.77244-11-ricardo.neri-calderon@linux.intel.com \
--to=ricardo.neri-calderon@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=bp@suse.de \
--cc=brgerst@gmail.com \
--cc=cmetcalf@mellanox.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=jslaby@suse.cz \
--cc=julliard@winehq.org \
--cc=liang.z.li@intel.com \
--cc=linux-kernel@vger.kern \
--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=ravi.v.shankar@intel.com \
--cc=ray.huang@amd.com \
--cc=shuah@kernel.org \
--cc=slaoub@gmail.com \
--cc=stsp@list.ru \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
/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