>
Cc: Vlastimil Babka <vba...@suse.cz>
Cc: Tony Luck <tony.l...@intel.com>
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Liang Z. Li <liang.z...@intel.com>
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch/x86/kernel/umip.
t;liverl...@gmail.com>
Cc: Adan Hawthorn <adanhawth...@gmail.com>
Cc: Joe Perches <j...@perches.com>
Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch/x86/mm/mpx.c | 20 ++
: Huang Rui
Cc: Jiri Slaby
Cc: Jonathan Corbet
Cc: Michael S. Tsirkin
Cc: Paul Gortmaker
Cc: Peter Zijlstra
Cc: Ravi V. Shankar
Cc: Shuah Khan
Cc: Vlastimil Babka
Cc: Tony Luck
Cc: Paolo Bonzini
Cc: Liang Z. Li
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/kernel/umip.c
Stoakes
Cc: Qiaowei Ren
Cc: Peter Zijlstra
Cc: Nathan Howard
Cc: Adan Hawthorn
Cc: Joe Perches
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/mm/mpx.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/x86/mm/mpx.c
l.com>
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Liang Z. Li <liang.z...@intel.com>
Cc: x...@kernel.org
Reviewed-by: Borislav Petkov <b...@suse.de>
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/
aul Gortmaker
Cc: Peter Zijlstra
Cc: Ravi V. Shankar
Cc: Shuah Khan
Cc: Vlastimil Babka
Cc: Tony Luck
Cc: Paolo Bonzini
Cc: Liang Z. Li
Cc: x...@kernel.org
Reviewed-by: Borislav Petkov
Signed-off-by: Ricardo Neri
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/disab
@intel.com>
Cc: Shuah Khan <sh...@kernel.org>
Cc: Vlastimil Babka <vba...@suse.cz>
Cc: Tony Luck <tony.l...@intel.com>
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Liang Z. Li <liang.z...@intel.com>
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde..
off-by: Ricardo Neri
---
arch/x86/include/asm/umip.h | 12 ++
arch/x86/kernel/Makefile| 1 +
arch/x86/kernel/umip.c | 303
3 files changed, 316 insertions(+)
create mode 100644 arch/x86/include/asm/umip.h
create mode 100644 arch/x86/ker
<pet...@infradead.org>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch/x86/lib/insn-eval.c | 6 +++---
1 file changed, 3 insertions(+), 3 d
. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/lib/insn-eval.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index 2bb8303ba92f..3919458fecbf 100644
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib
pet...@infradead.org>
Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
Cc: Shuah Khan <sh...@kernel.org>
Cc: Vlastimil Babka <vba...@suse.cz>
Cc: Tony Luck <tony.l...@intel.com>
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Liang Z. Li <liang.z...@intel.com>
Cc: x...@kernel.o
Bonzini
Cc: Liang Z. Li
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/Kconfig | 10 ++
arch/x86/kernel/cpu/common.c | 25 -
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index
Khan <sh...@kernel.org>
Cc: Vlastimil Babka <vba...@suse.cz>
Cc: Tony Luck <tony.l...@intel.com>
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Liang Z. Li <liang.z...@intel.com>
Cc: x...@kernel.org
Reviewed-by: Andy Lutomirski <l...@kernel.org>
Signed-off-by: Ricardo Neri
ned-off-by: Ricardo Neri
---
arch/x86/kernel/traps.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index bf54309b85da..1c1bb7992f70 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -65,6 +65,7 @@
#include
#incl
: Jiri Slaby <jsl...@suse.cz>
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Michael S. Tsirkin <m...@redhat.com>
Cc: Paul Gortmaker <paul.gortma...@windriver.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
Cc: Shuah Khan <sh.
lt;m...@redhat.com>
Cc: Paul Gortmaker <paul.gortma...@windriver.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
Cc: Shuah Khan <sh...@kernel.org>
Cc: Vlastimil Babka <vba...@suse.cz>
Signed-off-by: Ricardo Neri <ricardo.
Cc: Dave Hansen
Cc: Fenghua Yu
Cc: Huang Rui
Cc: Jiri Slaby
Cc: Jonathan Corbet
Cc: Michael S. Tsirkin
Cc: Paul Gortmaker
Cc: Peter Zijlstra
Cc: Ravi V. Shankar
Cc: Shuah Khan
Cc: Vlastimil Babka
Signed-off-by: Ricardo Neri
---
tools/testing/selftests/x86/entry_from_vm86.c | 73
l S. Tsirkin
Cc: Paul Gortmaker
Cc: Peter Zijlstra
Cc: Ravi V. Shankar
Cc: Shuah Khan
Cc: Vlastimil Babka
Signed-off-by: Ricardo Neri
---
tools/testing/selftests/x86/entry_from_vm86.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/
<pet...@infradead.org>
Cc: Borislav Petkov <b...@suse.de>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch/x86/lib/insn-eval.c | 26 ++
Zijlstra
Cc: Borislav Petkov
Cc: Dmitry Vyukov
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/lib/insn-eval.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index c6120e9298f5
g>
Cc: Adrian Hunter <adrian.hun...@intel.com>
Cc: Kees Cook <keesc...@chromium.org>
Cc: Thomas Garnier <thgar...@google.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
Cc: x..
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Adrian Hunter
Cc: Kees Cook
Cc: Thomas Garnier
Cc: Peter Zijlstra
Cc: Dmitry Vyukov
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/include/asm/insn-eval.h | 16
arch/x86/lib/Make
Hunter <adrian.hun...@intel.com>
Cc: Kees Cook <keesc...@chromium.org>
Cc: Thomas Garnier <thgar...@google.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Borislav Petkov <b...@suse.de>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Ravi V. Shankar <ravi.v.shan.
: Lorenzo Stoakes
Cc: Qiaowei Ren
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Adrian Hunter
Cc: Kees Cook
Cc: Thomas Garnier
Cc: Peter Zijlstra
Cc: Borislav Petkov
Cc: Dmitry Vyukov
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/lib/insn-eval.c | 147
rnel.org>
Cc: Adrian Hunter <adrian.hun...@intel.com>
Cc: Kees Cook <keesc...@chromium.org>
Cc: Thomas Garnier <thgar...@google.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Borislav Petkov <b...@suse.de>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Ravi V. Shan
King
Cc: Lorenzo Stoakes
Cc: Qiaowei Ren
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Adrian Hunter
Cc: Kees Cook
Cc: Thomas Garnier
Cc: Peter Zijlstra
Cc: Borislav Petkov
Cc: Dmitry Vyukov
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/lib
adrian.hun...@intel.com>
Cc: Kees Cook <keesc...@chromium.org>
Cc: Thomas Garnier <thgar...@google.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Borislav Petkov <b...@suse.de>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Ravi V. Shankar <ravi.v.shan.
Cc: Qiaowei Ren
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Adrian Hunter
Cc: Kees Cook
Cc: Thomas Garnier
Cc: Peter Zijlstra
Cc: Borislav Petkov
Cc: Dmitry Vyukov
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/include/asm/insn-eval.h | 1
On Thu, 2017-07-27 at 15:26 +0200, Borislav Petkov wrote:
> On Tue, Jul 25, 2017 at 04:48:13PM -0700, Ricardo Neri wrote:
> > I meant to say the 4 most significant bytes. In this case, the
> > 64-address 0x1234 would lie in the kernel memory while
> > 0xfff
On Thu, 2017-07-27 at 15:26 +0200, Borislav Petkov wrote:
> On Tue, Jul 25, 2017 at 04:48:13PM -0700, Ricardo Neri wrote:
> > I meant to say the 4 most significant bytes. In this case, the
> > 64-address 0x1234 would lie in the kernel memory while
> > 0xfff
On Fri, 2017-06-09 at 18:10 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:22AM -0700, Ricardo Neri wrote:
> > User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a
> > bit in %cr4.
> >
> > It makes sense to enable UMIP at some point
On Fri, 2017-06-09 at 18:10 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:22AM -0700, Ricardo Neri wrote:
> > User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a
> > bit in %cr4.
> >
> > It makes sense to enable UMIP at some point
I am sorry Boris, I also missed this feedback.
On Fri, 2017-06-09 at 15:02 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:21AM -0700, Ricardo Neri wrote:
> > If the User-Mode Instruction Prevention CPU feature is available and
> > enabled, a general protection fault
I am sorry Boris, I also missed this feedback.
On Fri, 2017-06-09 at 15:02 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:21AM -0700, Ricardo Neri wrote:
> > If the User-Mode Instruction Prevention CPU feature is available and
> > enabled, a general protection fault
On Fri, 2017-06-09 at 13:02 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:20AM -0700, Ricardo Neri wrote:
> > fixup_umip_exception() will be called from do_general_p
On Fri, 2017-06-09 at 13:02 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:20AM -0700, Ricardo Neri wrote:
> > fixup_umip_exception() will be called from do_general_p
I am sorry Boris, while working on this series I missed a few of your
feedback comments.
On Wed, 2017-06-07 at 17:48 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:14AM -0700, Ricardo Neri wrote:
> > The 32-bit and 64-bit address encodings are identical. This means that w
I am sorry Boris, while working on this series I missed a few of your
feedback comments.
On Wed, 2017-06-07 at 17:48 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:14AM -0700, Ricardo Neri wrote:
> > The 32-bit and 64-bit address encodings are identical. This means that w
On Thu, 2017-06-08 at 20:38 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:19AM -0700, Ricardo Neri wrote:
> > The feature User-Mode Instruction Prevention present in recent Intel
> > processor prevents a group of instructions from being executed with
> &g
On Thu, 2017-06-08 at 20:38 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:19AM -0700, Ricardo Neri wrote:
> > The feature User-Mode Instruction Prevention present in recent Intel
> > processor prevents a group of instructions from being executed with
> &g
On Wed, 2017-06-07 at 18:28 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:16AM -0700, Ricardo Neri wrote:
> > Tasks running in virtual-8086 mode or in protected mode with code
> > segment descriptors that specify 16-bit default address sizes via the
> >
On Wed, 2017-06-07 at 18:28 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:16AM -0700, Ricardo Neri wrote:
> > Tasks running in virtual-8086 mode or in protected mode with code
> > segment descriptors that specify 16-bit default address sizes via the
> >
On Wed, 2017-06-07 at 17:49 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:14AM -0700, Ricardo Neri wrote:
> > @@ -697,18 +753,21 @@ void __user *insn_get_addr_ref(struct insn *insn,
> > struct pt_regs *regs)
> > {
> > unsigned long linear_add
On Wed, 2017-06-07 at 17:49 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:14AM -0700, Ricardo Neri wrote:
> > @@ -697,18 +753,21 @@ void __user *insn_get_addr_ref(struct insn *insn,
> > struct pt_regs *regs)
> > {
> > unsigned long linear_add
On Wed, 2017-06-07 at 15:15 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:12AM -0700, Ricardo Neri wrote:
> > Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software
> > Developer's Manual volume 2A states that when ModRM.mod is zero and
> > ModRM
On Wed, 2017-06-07 at 15:15 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:12AM -0700, Ricardo Neri wrote:
> > Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software
> > Developer's Manual volume 2A states that when ModRM.mod is zero and
> > ModRM
On Wed, 2017-06-07 at 14:59 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:11AM -0700, Ricardo Neri wrote:
> > This function returns the default values of the address and operand sizes
> > as specified in the segment descriptor. This information is determined
>
On Wed, 2017-06-07 at 14:59 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:11AM -0700, Ricardo Neri wrote:
> > This function returns the default values of the address and operand sizes
> > as specified in the segment descriptor. This information is determined
>
On Thu, 2017-06-15 at 11:37 -0700, Ricardo Neri wrote:
> > Yuck, didn't we talk about this already?
>
> I am sorry Borislav. I thought you agreed that I could use the values
> of
> the segment override prefixes to identify the segment registers [1].
This time with the ref
On Thu, 2017-06-15 at 11:37 -0700, Ricardo Neri wrote:
> > Yuck, didn't we talk about this already?
>
> I am sorry Borislav. I thought you agreed that I could use the values
> of
> the segment override prefixes to identify the segment registers [1].
This time with the ref
On Tue, 2017-05-30 at 12:35 +0200, Borislav Petkov wrote:
> 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 o
On Tue, 2017-05-30 at 12:35 +0200, Borislav Petkov wrote:
> 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 o
On Tue, 2017-06-06 at 13:58 +0200, Borislav Petkov wrote:
> On Mon, Jun 05, 2017 at 11:06:58PM -0700, Ricardo Neri wrote:
> > I agree that insn-eval reads somewhat funny. I did not want to go with
> > insn-dec.c as insn.c, in my opinion, already decodes the instruction
> > (i.
On Tue, 2017-06-06 at 13:58 +0200, Borislav Petkov wrote:
> On Mon, Jun 05, 2017 at 11:06:58PM -0700, Ricardo Neri wrote:
> > I agree that insn-eval reads somewhat funny. I did not want to go with
> > insn-dec.c as insn.c, in my opinion, already decodes the instruction
> > (i.
On Mon, 2017-05-29 at 15:07 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:03AM -0700, Ricardo Neri wrote:
> > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> > Developer's Manual volume 2A states that when a SIB byte is used and the
> >
On Mon, 2017-05-29 at 15:07 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:03AM -0700, Ricardo Neri wrote:
> > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> > Developer's Manual volume 2A states that when a SIB byte is used and the
> >
On Mon, 2017-05-29 at 18:37 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:05AM -0700, Ricardo Neri wrote:
> > We are not in a critical failure path. The invalid register type is caused
> > when trying to decode invalid instruction bytes from a user-space program.
&
On Mon, 2017-05-29 at 18:37 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:05AM -0700, Ricardo Neri wrote:
> > We are not in a critical failure path. The invalid register type is caused
> > when trying to decode invalid instruction bytes from a user-space program.
&
On Mon, 2017-05-29 at 19:16 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:06AM -0700, Ricardo Neri wrote:
> > The function get_reg_offset() returns the offset to the register the
> > argument specifies as indicated in an enumeration of type offset. Callers
>
On Mon, 2017-05-29 at 19:16 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:06AM -0700, Ricardo Neri wrote:
> > The function get_reg_offset() returns the offset to the register the
> > argument specifies as indicated in an enumeration of type offset. Callers
>
On Mon, 2017-05-29 at 23:48 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:07AM -0700, Ricardo Neri wrote:
> > String instructions are special because in protected mode, the linear
> > address is always obtained via the ES segment register in operands that
> > u
On Mon, 2017-05-29 at 23:48 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:07AM -0700, Ricardo Neri wrote:
> > String instructions are special because in protected mode, the linear
> > address is always obtained via the ES segment register in operands that
> > u
On Wed, 2017-05-31 at 18:58 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:10AM -0700, Ricardo Neri wrote:
> > With segmentation, the base address of the segment descriptor is needed
> > to compute a linear address. The segment descriptor used in the address
> >
On Wed, 2017-05-31 at 18:58 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:10AM -0700, Ricardo Neri wrote:
> > With segmentation, the base address of the segment descriptor is needed
> > to compute a linear address. The segment descriptor used in the address
> >
On Sat, 2017-05-27 at 12:13 +0200, Borislav Petkov wrote:
> On Fri, May 26, 2017 at 08:40:26PM -0700, Ricardo Neri wrote:
> > This change was initially intended to only rename the error codes,
> > without functional changes. Would making change be considered a
> change
&g
On Sat, 2017-05-27 at 12:13 +0200, Borislav Petkov wrote:
> On Fri, May 26, 2017 at 08:40:26PM -0700, Ricardo Neri wrote:
> > This change was initially intended to only rename the error codes,
> > without functional changes. Would making change be considered a
> change
&g
On Wed, 2017-05-24 at 15:37 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:02AM -0700, Ricardo Neri wrote:
> > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> > Developer's Manual volume 2A states that when ModRM.mod !=11b and
> > ModRM.rm =
On Wed, 2017-05-24 at 15:37 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:02AM -0700, Ricardo Neri wrote:
> > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> > Developer's Manual volume 2A states that when ModRM.mod !=11b and
> > ModRM.rm =
On Sun, 2017-05-21 at 16:23 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:00AM -0700, Ricardo Neri wrote:
> > Up to this point, only fault.c used the definitions of the page fault error
> > codes. Thus, it made sense to keep them within such file. Other portions of
On Sun, 2017-05-21 at 16:23 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:00AM -0700, Ricardo Neri wrote:
> > Up to this point, only fault.c used the definitions of the page fault error
> > codes. Thus, it made sense to keep them within such file. Other portions of
Hi Ingo, Thomas,
On Fri, 2017-05-05 at 11:16 -0700, Ricardo Neri wrote:
> This is v7 of this series. The six previous submissions can be found
> here [1], here [2], here[3], here[4], here[5] and here[6]. This
> version
> addresses the comments received in v6 plus improvements of th
Hi Ingo, Thomas,
On Fri, 2017-05-05 at 11:16 -0700, Ricardo Neri wrote:
> This is v7 of this series. The six previous submissions can be found
> here [1], here [2], here[3], here[4], here[5] and here[6]. This
> version
> addresses the comments received in v6 plus improvements of th
On Thu, 2017-05-04 at 13:02 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 02:51:56PM -0700, Ricardo Neri wrote:
> > > > +seg >=
> > > > current->active_mm->context.ldt->size)) {
> > >
> > > ldt->siz
On Thu, 2017-05-04 at 13:02 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 02:51:56PM -0700, Ricardo Neri wrote:
> > > > +seg >=
> > > > current->active_mm->context.ldt->size)) {
> > >
> > > ldt->siz
On Fri, 2017-05-05 at 19:19 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 03:37:44PM -0700, Ricardo Neri wrote:
> > I need a human-readable way of identifying what segment selector (in
> > pt_regs, vm86regs or directly reading the segment registers) to use.
> > Sin
On Fri, 2017-05-05 at 19:19 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 03:37:44PM -0700, Ricardo Neri wrote:
> > I need a human-readable way of identifying what segment selector (in
> > pt_regs, vm86regs or directly reading the segment registers) to use.
> > Sin
On Fri, 2017-05-05 at 19:28 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 03:52:41PM -0700, Ricardo Neri wrote:
> > Probably insn_get_seg_base() itself can verify if there are segment
> > override prefixes in the struct insn. If yes, use them except for
> > spec
On Fri, 2017-05-05 at 19:28 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 03:52:41PM -0700, Ricardo Neri wrote:
> > Probably insn_get_seg_base() itself can verify if there are segment
> > override prefixes in the struct insn. If yes, use them except for
> > spec
On Sun, 2017-05-07 at 19:20 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 06:29:59PM -0700, Ricardo Neri wrote:
> > > if (X86_MODRM_MOD(insn->modrm.value) == 0 &&
> > > X86_MODRM_RM(insn->modrm.value) == 5)
> > >
> > >
On Sun, 2017-05-07 at 19:20 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 06:29:59PM -0700, Ricardo Neri wrote:
> > > if (X86_MODRM_MOD(insn->modrm.value) == 0 &&
> > > X86_MODRM_RM(insn->modrm.value) == 5)
> > >
> > >
On Mon, 2017-05-08 at 13:42 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 08:33:46PM -0700, Ricardo Neri wrote:
> > This is the reason I check the value of long_bytes. If long_bytes is not
> > 4, being the only other possible value 8 (perhaps I need to issue an
> >
On Mon, 2017-05-08 at 13:42 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 08:33:46PM -0700, Ricardo Neri wrote:
> > This is the reason I check the value of long_bytes. If long_bytes is not
> > 4, being the only other possible value 8 (perhaps I need to issue an
> >
On Sat, 2017-05-06 at 11:04 +0200, Paolo Bonzini wrote:
>
>
> On 05/05/2017 20:17, Ricardo Neri wrote:
> > User-Mode Instruction Prevention is a security feature present in
> new
> > Intel processors that, when set, prevents the execution of a subset
> of
> >
On Sat, 2017-05-06 at 11:04 +0200, Paolo Bonzini wrote:
>
>
> On 05/05/2017 20:17, Ricardo Neri wrote:
> > User-Mode Instruction Prevention is a security feature present in
> new
> > Intel processors that, when set, prevents the execution of a subset
> of
> >
On Sun, 2017-04-30 at 19:15 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 01:44:43PM -0700, Ricardo Neri wrote:
> > I regard that the role of this function is to obtain the the segment
> > selector from either of the prefixes or inferred from the operands. It
> >
On Sun, 2017-04-30 at 19:15 +0200, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 01:44:43PM -0700, Ricardo Neri wrote:
> > I regard that the role of this function is to obtain the the segment
> > selector from either of the prefixes or inferred from the operands. It
> >
e...@linux.intel.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Dave Hansen <dave.han...@linux.intel.com>
Cc: Paul Gortmaker <paul.gortma...@windriver.com>
Cc: x...@kernel.org
Reviewed-by: Andy Lutomirski <l...@kernel.org>
Signed-off-by: Ricardo Neri <ricardo.neri-calde..
from MPX to decode instructions operands. For this purpose
code was put in a common location.
* Fixed two bugs in MPX code that decodes operands.
Ricardo Neri (26):
ptrace,x86: Make user_64bit_mode() available to 32-bit builds
x86/mm: Relocate page fault error codes to traps.h
x86/mpx: U
to be updated as well. No functional changes
were performed.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andy Lutomirski
Cc: "Kirill A. Shutemov"
Cc: Josh Poimboeuf
Cc: Dave Hansen
Cc: Paul Gortmaker
Cc: x...@kernel.org
Reviewed-by: Andy Lutomirski
Signed-
from MPX to decode instructions operands. For this purpose
code was put in a common location.
* Fixed two bugs in MPX code that decodes operands.
Ricardo Neri (26):
ptrace,x86: Make user_64bit_mode() available to 32-bit builds
x86/mm: Relocate page fault error codes to traps.h
x86/mpx: U
adrian.hun...@intel.com>
Cc: Kees Cook <keesc...@chromium.org>
Cc: Thomas Garnier <thgar...@google.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Borislav Petkov <b...@suse.de>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Ravi V. Shankar <ravi.v.shan.
Cc: Qiaowei Ren
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Adrian Hunter
Cc: Kees Cook
Cc: Thomas Garnier
Cc: Peter Zijlstra
Cc: Borislav Petkov
Cc: Dmitry Vyukov
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/include/asm/insn-eval.h | 1
g>
Cc: Nathan Howard <liverl...@gmail.com>
Cc: Adan Hawthorn <adanhawth...@gmail.com>
Cc: Joe Perches <j...@perches.com>
Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch/x86/
Cc: Colin Ian King
Cc: Lorenzo Stoakes
Cc: Qiaowei Ren
Cc: Peter Zijlstra
Cc: Nathan Howard
Cc: Adan Hawthorn
Cc: Joe Perches
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/mm/mpx.c | 27 ---
1 file changed, 20 insertions(+), 7
<pet...@infradead.org>
Cc: Borislav Petkov <b...@suse.de>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch/x86/lib/insn-eval.c | 155
.@suse.de>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch/x86/lib/insn-eval.c | 48 +++-
1 file chang
Zijlstra
Cc: Borislav Petkov
Cc: Dmitry Vyukov
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/lib/insn-eval.c | 155 +++
1 file changed, 155 insertions(+)
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn
. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/lib/insn-eval.c | 48 +++-
1 file changed, 43 insertions(+), 5 deletions(-)
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index 928a662..8914884 100644
--- a/arch
;tony.l...@intel.com>
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Liang Z. Li <liang.z...@intel.com>
Cc: Alexandre Julliard <julli...@winehq.org>
Cc: Stas Sergeev <s...@list.ru>
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org
Signed-off-by: Ricardo Neri <ricardo.n
kin
Cc: Paul Gortmaker
Cc: Peter Zijlstra
Cc: Ravi V. Shankar
Cc: Shuah Khan
Cc: Vlastimil Babka
Cc: Tony Luck
Cc: Paolo Bonzini
Cc: Liang Z. Li
Cc: Alexandre Julliard
Cc: Stas Sergeev
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/include/
501 - 600 of 958 matches
Mail list logo
