Re: [PATCH v7 16/26] x86/insn-eval: Support both signed 32-bit and 64-bit effective addresses

2017-06-07 Thread Borislav Petkov
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_addr, seg_base_addr, seg_limit; > long eff_addr, base, indx; > - int addr_offset,

Re: [PATCH v7 16/26] x86/insn-eval: Support both signed 32-bit and 64-bit effective addresses

2017-06-07 Thread Borislav Petkov
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 we > can use the same function in both cases. In order to reuse the function > for 32-bit address encodings, we must sign-extend our 32-bit signed > operands to

Re: [PATCH v7 18/26] x86/insn-eval: Add support to resolve 16-bit addressing encodings

2017-06-07 Thread Borislav Petkov
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 > D bit will use 16-bit addressing form encodings as described in the Intel > 64 and IA-32

Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type

2017-06-07 Thread Stas Sergeev
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. :) I think all non-kernel-dev MLs should be treated with more care. Eg your initial questions were certainly

Re: [PATCH v7 20/26] x86/cpufeature: Add User-Mode Instruction Prevention definitions

2017-06-07 Thread Borislav Petkov
On Fri, May 05, 2017 at 11:17:18AM -0700, 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 > instructions if such instructions are executed in user mode (CPL > 0). > Attempting to

Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type

2017-06-07 Thread Borislav Petkov
On Tue, Jun 06, 2017 at 05:28:52PM -0700, Ricardo Neri wrote: > I see. You were more concerned about the naming of the coding artifacts > (e.g., function names, error prints, etc) than the actual filenames. Well, I'm not sure here. We could either have a generalized prefix or put the function

Re: [PATCH v7 13/26] x86/insn-eval: Add function to get default params of code segment

2017-06-07 Thread Borislav Petkov
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 > from the D and L bits. Hence, it can be used for both IA-32e 64-bit and > 32-bit

Re: [PATCH v7 14/26] x86/insn-eval: Indicate a 32-bit displacement if ModRM.mod is 0 and ModRM.rm is 5

2017-06-07 Thread Borislav Petkov
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.rm is 101b, a 32-bit displacement follows the ModRM byte. This means > that none of the