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
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
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
Hi Stas,
On Wed, 2017-06-07 at 21:54 +0300, Stas Sergeev wrote:
> Hi Ricardo, would you mind unsubscribing
> linux-msdos@ from all your future mails on
> this subject? Otherwise I am afraid there
> would be no subscribers left when you are
> finally done. :)
Sure! I will drop linux-msdos in the
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 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 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 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 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 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 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 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
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 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 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 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
> >
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..
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 +---
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/
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.
.@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
<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
;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-msdos@vger.kernel.org
Signed-off-by: Ricardo Neri <ricardo.n
>
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
.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-msdos@vger.kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.
: 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..
;
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-msdos@vger.kernel.org
Reviewed-by: Andy Lutomirski <l...@kernel.org>
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@l
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
<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
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
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
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
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
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
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-msdos@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 +++-
;
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.
..@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
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
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 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 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:
> 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-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 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 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!
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 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 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 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 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 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 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 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 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 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
;
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-msdos@vger.kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch/x86/kernel/traps.c | 4
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 | 19 +--
1 file c
Julliard <julli...@winehq.org>
Cc: Stas Sergeev <s...@list.ru>
Cc: x...@kernel.org
Cc: linux-msdos@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 +++-
er <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.
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>
---
arch/x86/lib/insn-ev
gle.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 | 45 -
1 file changed, 40 insertions(+), 5 deletions(-)
diff
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
t;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: Alexandre Julliard <julli...@winehq.org>
Cc: Stas Sergeev <s...@list.ru>
Cc: x...@ke
..@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/include/asm/insn-eval.h | 2 ++
arch/
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
with
SEGV_MAPERR with the offending address. A new function is inspired in
force_sig_info_fault is introduced to model the page fault.
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch/x86/kernel/umip.c | 45 +++--
1 file changed, 43 inse
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
Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
---
arch
ad.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...@linux.intel.com>
---
arch/x
kar <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.com>
---
tools/testing/selftests/x86/entry_from_vm86.c | 39 ++-
1 file changed,
..@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 --
homas 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-ca
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 | 61
1
On Sun, 2017-03-05 at 08:18 -0800, Andy Lutomirski wrote:
> > + */
> > +static void __force_sig_info_umip_fault(void __user *address,
> > + struct pt_regs *regs)
> > +{
> > + siginfo_t info;
> > + struct task_struct *tsk = current;
> > +
> > +
1 - 100 of 171 matches
Mail list logo
