>
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: Alexandre Julliard <julli...@winehq.org>
Cc: Stas Sergeev <s...@list.ru>
Cc: x...@kerne
...@vger.kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/kernel/umip.c | 45 +++--
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
index c7c5795..ff7366a 100644
--- a/arch/x86/kernel/umip.c
+++ b/arch
: Peter Zijlstra <pet...@infradead.org>
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..
: Dave Hansen
Cc: Adam Buchbinder
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 | 20 ++--
1 file
<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 delet
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 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff
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 e746a6f..182e2ae 100644
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/lib/insn-eval.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index 4f600de..1a5f5a6 100644
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib
v <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 | 55
1
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/lib/insn-eval.c | 55
1 file changed, 55 insertions(+)
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index 0a496f4..f46cb31 100644
--- a/arch/x86
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...@intel.com>
Cc
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..
: 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 | 67
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
tel.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...@intel.com>
Cc: x...@kern
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 | 256
gt;
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...@intel.com>
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde
: 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 | 6
arch/x86/lib/insn-eval.c | 65
r...@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...@intel.com>
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
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.neri-calde...@linux.intel.com>
---
arch/x86/Kconfig | 10 ++
arch/x86/kernel/cpu/common.c | 16 +++-
rislav 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/include/asm/insn-eval.h | 2 +
arch/x86/lib/insn-eva
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 | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/x86/lib/insn
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/Kconfig | 10 ++
arch/x86/kernel/cpu/common.c | 16 +++-
2 files changed, 25 insertions(+), 1 deletion
: Dmitry Vyukov
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/include/asm/insn-eval.h | 2 +
arch/x86/lib/insn-eval.c | 127 +++
2 files changed, 129 insertions(+)
diff --git a/arch/x86/include/asm/insn-eval.h b/arch
;
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.neri-calde...@linux.intel.co
: 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.
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/x86/entry_from_vm86.c
b/to
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
..@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 | 10 ++
1
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...@intel.com>
Cc: x...@kernel.org
Signed
;
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
Reviewed-by: Andy Lutomirski <l...@kernel.org>
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@l
.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.neri-calde...@linux.intel.
: Borislav Petkov
Cc: Dmitry Vyukov
Cc: Ravi V. Shankar
Cc: x...@kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/lib/insn-eval.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index c7c1239..9822061 100644
--- a/arch/x86/lib
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 | 99
kar
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
Reviewed-by: Andy Lutomirski
Signed-off-by: Ricardo Neri
---
arch/x86/kernel/traps.c | 4
1 file changed
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: Alexandre Julliard
Cc: Stas Sergeev
Cc: x...@kernel.org
Cc: linux-ms...@vger.kernel.org
Signed-off-by: Ricardo Neri
---
arch/x86/include/asm/cpufeature
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 | 15 +---
: 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...@intel.com>
Cc: x...@kernel.org
Sig
: 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 | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/x86/mm/mpx.c b
: 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/ptrace.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
On Wed, 2017-04-26 at 10:05 +0200, Borislav Petkov wrote:
> On Tue, Apr 25, 2017 at 07:04:20PM -0700, Ricardo Neri wrote:
> > For the specific case of ModRM.mod being 0, I feel I need to clarify
> > that REX.B is not decoded and if SIB.base is %r13 the base is also 0.
>
> W
On Wed, 2017-04-26 at 10:05 +0200, Borislav Petkov wrote:
> On Tue, Apr 25, 2017 at 07:04:20PM -0700, Ricardo Neri wrote:
> > For the specific case of ModRM.mod being 0, I feel I need to clarify
> > that REX.B is not decoded and if SIB.base is %r13 the base is also 0.
>
> W
On Tue, 2017-04-25 at 15:51 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:45PM -0800, Ricardo Neri wrote:
> > The 32-bit and 64-bit address encodings are identical. This means that we
> > can use the same function in both cases. In order to reuse the function for
>
On Tue, 2017-04-25 at 15:51 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:45PM -0800, Ricardo Neri wrote:
> > The 32-bit and 64-bit address encodings are identical. This means that we
> > can use the same function in both cases. In order to reuse the function for
>
On Fri, 2017-04-21 at 16:55 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:44PM -0800, Ricardo Neri wrote:
> > insn_get_addr_ref returns the effective address as defined by the
>
> Please end function names with parentheses.
Will do.
>
> > section 3.7.5
On Fri, 2017-04-21 at 16:55 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:44PM -0800, Ricardo Neri wrote:
> > insn_get_addr_ref returns the effective address as defined by the
>
> Please end function names with parentheses.
Will do.
>
> > section 3.7.5
On Fri, 2017-04-21 at 12:52 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:43PM -0800, 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 the mod part of the ModRM
> > b
On Fri, 2017-04-21 at 12:52 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:43PM -0800, 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 the mod part of the ModRM
> > b
On Thu, 2017-04-20 at 15:06 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:42PM -0800, Ricardo Neri wrote:
> > These functions read the default values of the address and operand sizes
> > as specified in the segment descriptor. This information is determined
>
On Thu, 2017-04-20 at 15:06 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:42PM -0800, Ricardo Neri wrote:
> > These functions read the default values of the address and operand sizes
> > as specified in the segment descriptor. This information is determined
>
On Thu, 2017-04-20 at 10:25 +0200, Borislav Petkov wrote:
> > + * insn_get_seg_base() - Obtain base address contained in
> descriptor
> > + * @regs:Set of registers containing the segment selector
> > + * @insn:Instruction structure with selector override prefixes
> > + * @regoff: Operand
On Thu, 2017-04-20 at 10:25 +0200, Borislav Petkov wrote:
> > + * insn_get_seg_base() - Obtain base address contained in
> descriptor
> > + * @regs:Set of registers containing the segment selector
> > + * @insn:Instruction structure with selector override prefixes
> > + * @regoff: Operand
On Thu, 2017-04-20 at 10:25 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:41PM -0800, 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 Thu, 2017-04-20 at 10:25 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:41PM -0800, 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-04-19 at 12:26 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:40PM -0800, Ricardo Neri wrote:
> > The segment descriptor contains information that is relevant to how linear
> > address need to be computed. It contains the default size of addres
On Wed, 2017-04-19 at 12:26 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:40PM -0800, Ricardo Neri wrote:
> > The segment descriptor contains information that is relevant to how linear
> > address need to be computed. It contains the default size of addres
On Wed, 2017-04-26 at 13:44 -0700, Ricardo Neri wrote:
> >
> > > +*/
> > > + for (i = 0; i < insn->prefixes.nbytes; i++) {
> > > + switch (insn->prefixes.bytes[i]) {
> > > + case SEG_CS:
> > > +
On Wed, 2017-04-26 at 13:44 -0700, Ricardo Neri wrote:
> >
> > > +*/
> > > + for (i = 0; i < insn->prefixes.nbytes; i++) {
> > > + switch (insn->prefixes.bytes[i]) {
> > > + case SEG_CS:
> > > +
On Tue, 2017-04-18 at 11:42 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:39PM -0800, 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-04-18 at 11:42 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:39PM -0800, 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 Wed, 2017-04-12 at 18:28 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:38PM -0800, Ricardo Neri wrote:
> > The function insn_get_reg_offset takes as argument an enumeration that
>
> Please end function names with parentheses.
Will do!
>
> And do yo
On Wed, 2017-04-12 at 18:28 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:38PM -0800, Ricardo Neri wrote:
> > The function insn_get_reg_offset takes as argument an enumeration that
>
> Please end function names with parentheses.
Will do!
>
> And do yo
On Wed, 2017-04-12 at 12:03 +0200, Borislav Petkov wrote:
> > + * 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
>
On Wed, 2017-04-12 at 12:03 +0200, Borislav Petkov wrote:
> > + * 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
>
On Wed, 2017-04-12 at 00:08 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:36PM -0800, 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 Wed, 2017-04-12 at 00:08 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:36PM -0800, 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 Tue, 2017-04-11 at 23:56 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:34PM -0800, Ricardo Neri wrote:
> > Even though memory addresses are unsigned. The operands used to compute the
>
> ... unsigned, the operands ...
Oops! I will correct.
On Tue, 2017-04-11 at 23:56 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:34PM -0800, Ricardo Neri wrote:
> > Even though memory addresses are unsigned. The operands used to compute the
>
> ... unsigned, the operands ...
Oops! I will correct.
Hi Boris,
I am sorry I missed your feedback earlier. Thanks for commenting!
On Tue, 2017-04-11 at 13:31 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:35PM -0800, Ricardo Neri wrote:
> > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> > Developer'
Hi Boris,
I am sorry I missed your feedback earlier. Thanks for commenting!
On Tue, 2017-04-11 at 13:31 +0200, Borislav Petkov wrote:
> On Tue, Mar 07, 2017 at 04:32:35PM -0800, Ricardo Neri wrote:
> > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> > Developer'
On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote:
> 30.03.2017 08:14, Ricardo Neri пишет:
> >>>>>> You know the wine's
> >>>>>> requirements now - they are very small. And
> >>>>>> dosemu doesn't need anything at all bu
On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote:
> 30.03.2017 08:14, Ricardo Neri пишет:
> >>>>>> You know the wine's
> >>>>>> requirements now - they are very small. And
> >>>>>> dosemu doesn't need anything at all bu
On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote:
> Ricardo Neri <ricardo.neri-calde...@linux.intel.com> writes:
>
> > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote:
> >> 30.03.2017 08:14, Ricardo Neri пишет:
> >> >>>> But at leas
On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote:
> Ricardo Neri writes:
>
> > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote:
> >> 30.03.2017 08:14, Ricardo Neri пишет:
> >> >>>> But at least dosemu implements it
On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote:
> 30.03.2017 08:14, Ricardo Neri пишет:
> >>>> But at least dosemu implements it, so probably it is needed.
> >>> Right.
> >>>
> >>>> Of course if it is used by one of 100 DOS prog
On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote:
> 30.03.2017 08:14, Ricardo Neri пишет:
> >>>> But at least dosemu implements it, so probably it is needed.
> >>> Right.
> >>>
> >>>> Of course if it is used by one of 100 DOS prog
On Wed, 2017-03-29 at 23:55 +0300, Stas Sergeev wrote:
> 29.03.2017 07:38, Ricardo Neri пишет:
> >> Probably you could also remove
> >> the sldt and str emulation for protected mode, because,
> >> as I understand from this thread, wine does not
> >> need th
On Wed, 2017-03-29 at 23:55 +0300, Stas Sergeev wrote:
> 29.03.2017 07:38, Ricardo Neri пишет:
> >> Probably you could also remove
> >> the sldt and str emulation for protected mode, because,
> >> as I understand from this thread, wine does not
> >> need th
On Tue, 2017-03-28 at 12:38 +0300, Stas Sergeev wrote:
> 28.03.2017 02:46, Ricardo Neri пишет:
> > On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote:
> >> 11.03.2017 02:59, Ricardo Neri пишет:
> >>> On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
>
On Tue, 2017-03-28 at 12:38 +0300, Stas Sergeev wrote:
> 28.03.2017 02:46, Ricardo Neri пишет:
> > On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote:
> >> 11.03.2017 02:59, Ricardo Neri пишет:
> >>> On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
>
On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote:
> 11.03.2017 02:59, Ricardo Neri пишет:
> > On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
> >
> >> Why would you need one?
> >> Or do you really want to allow these instructions
> >&g
On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote:
> 11.03.2017 02:59, Ricardo Neri пишет:
> > On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
> >
> >> Why would you need one?
> >> Or do you really want to allow these instructions
> >&g
On Fri, 2017-03-10 at 06:17 -0800, Andy Lutomirski wrote:
> On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeev <s...@list.ru> wrote:
> > 10.03.2017 05:39, Andy Lutomirski пишет:
> >
> >> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev <s...@list.ru> wrote:
> >>
On Fri, 2017-03-10 at 06:17 -0800, Andy Lutomirski wrote:
> On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeev wrote:
> > 10.03.2017 05:39, Andy Lutomirski пишет:
> >
> >> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev wrote:
> >>>
> >>> 09.03.2017 04:1
On Sat, 2017-03-11 at 02:58 +0300, Stas Sergeev wrote:
> 11.03.2017 02:47, Ricardo Neri пишет:
> >>
> >>>> 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
On Sat, 2017-03-11 at 02:58 +0300, Stas Sergeev wrote:
> 11.03.2017 02:47, Ricardo Neri пишет:
> >>
> >>>> 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
On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
> 10.03.2017 05:39, Andy Lutomirski пишет:
> > On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev <s...@list.ru> wrote:
> >> 09.03.2017 04:15, Ricardo Neri пишет:
> >>
> >>> On Wed, 2017-03-08 at 08:4
On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
> 10.03.2017 05:39, Andy Lutomirski пишет:
> > On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev wrote:
> >> 09.03.2017 04:15, Ricardo Neri пишет:
> >>
> >>> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski
On Thu, 2017-03-09 at 18:39 -0800, Andy Lutomirski wrote:
> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev <s...@list.ru> wrote:
> > 09.03.2017 04:15, Ricardo Neri пишет:
> >
> >> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
> >>>
> >&g
On Thu, 2017-03-09 at 18:39 -0800, Andy Lutomirski wrote:
> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev wrote:
> > 09.03.2017 04:15, Ricardo Neri пишет:
> >
> >> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
> >>>
> >>> On
On Fri, 2017-03-10 at 01:01 +0300, Stas Sergeev wrote:
> 09.03.2017 03:46, Ricardo Neri пишет:
> > On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev wrote:
> >> 08.03.2017 03:32, Ricardo Neri пишет:
> >>> These are the instructions covered by UMIP:
> >>&
On Fri, 2017-03-10 at 01:01 +0300, Stas Sergeev wrote:
> 09.03.2017 03:46, Ricardo Neri пишет:
> > On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev wrote:
> >> 08.03.2017 03:32, Ricardo Neri пишет:
> >>> These are the instructions covered by UMIP:
> >>&
On Wed, 2017-03-08 at 07:56 -0800, Andy Lutomirski wrote:
> On Tue, Mar 7, 2017 at 4:32 PM, Ricardo Neri
> <ricardo.neri-calde...@linux.intel.com> wrote:
> > Certain user space programs that run on virtual-8086 mode may utilize
> > instructions protected by the User-Mod
On Wed, 2017-03-08 at 07:56 -0800, Andy Lutomirski wrote:
> On Tue, Mar 7, 2017 at 4:32 PM, Ricardo Neri
> wrote:
> > Certain user space programs that run on virtual-8086 mode may utilize
> > instructions protected by the User-Mode Instruction Prevention (UMIP)
> > securit
On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev 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 Descript
On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev 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 Descript
On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev <s...@list.ru> wrote:
> > 08.03.2017 19:06, Andy Lutomirski пишет:
> >>
> >> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <s...@list.ru> wrote:
> >
On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote:
> > 08.03.2017 19:06, Andy Lutomirski пишет:
> >>
> >> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev 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
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
601 - 700 of 958 matches
Mail list logo
