[PATCH v7 02/26] x86/mm: Relocate page fault error codes to traps.h

2017-05-05 Thread Ricardo Neri
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 code might be interested in those definitions too. For instance, the User- Mode Instruction Prevention emulation code will use such definitions to

[PATCH v7 03/26] x86/mpx: Use signed variables to compute effective addresses

2017-05-05 Thread Ricardo Neri
Even though memory addresses are unsigned, the operands used to compute the effective address do have a sign. This is true for the ModRM.rm, SIB.base, SIB.index as well as the displacement bytes. Thus, signed variables shall be used when computing the effective address from these operands. Once

[PATCH v7 05/26] x86/mpx: Do not use SIB.base if its value is 101b and ModRM.mod = 0

2017-05-05 Thread Ricardo Neri
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 base of the SIB byte points is base = 101b and the mod part of the ModRM byte is zero, the base port on the effective address computation is null. In this case,

[PATCH v7 08/26] x86/insn-eval: Add a utility function to get register offsets

2017-05-05 Thread Ricardo Neri
The function get_reg_offset() returns the offset to the register the argument specifies as indicated in an enumeration of type offset. Callers of this function would need the definition of such enumeration. This is not needed. Instead, add helper functions for this purpose. These functions are

[PATCH v7 19/26] x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings

2017-05-05 Thread Ricardo Neri
Convert the function insn_get_add_ref() into a wrapper function that calls the correct static address-decoding function depending on the address size In this way, callers do not need to worry about calling the correct function and decreases the number of functions that need to be exposed. To this

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

2017-05-05 Thread Ricardo Neri
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 Architecture Software Developer's Manual Volume 2A Section 2.1.5. 16-bit

[PATCH v7 21/26] x86: Add emulation code for UMIP instructions

2017-05-05 Thread Ricardo Neri
The feature User-Mode Instruction Prevention present in recent Intel processor prevents a group of instructions from being executed with CPL > 0. Otherwise, a general protection fault is issued. Rather than relaying this fault to the user space (in the form of a SIGSEGV signal), the instructions

[PATCH v7 22/26] x86/umip: Force a page fault when unable to copy emulated result to user

2017-05-05 Thread Ricardo Neri
fixup_umip_exception() will be called from do_general_protection. If the former returns false, the latter will issue a SIGSEGV with SEND_SIG_PRIV. However, when emulation is successful but the emulated result cannot be copied to user space memory, it is more accurate to issue a SIGSEGV with

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

2017-05-05 Thread Ricardo Neri
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 execute such instructions causes a general protection exception. The

[PATCH v7 04/26] x86/mpx: Do not use SIB.index if its value is 100b and ModRM.mod is not 11b

2017-05-05 Thread Ricardo Neri
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 = 100b indexed register-indirect addressing is used. In other words, a SIB byte follows the ModRM byte. In the specific case of SIB.index = 100b, the

[PATCH v7 23/26] x86/traps: Fixup general protection faults caused by UMIP

2017-05-05 Thread Ricardo Neri
If the User-Mode Instruction Prevention CPU feature is available and enabled, a general protection fault will be issued if the instructions sgdt, sldt, sidt, str or smsw are executed from user-mode context (CPL > 0). If the fault was caused by any of the instructions protected by UMIP,

[PATCH v7 09/26] x86/insn-eval: Add utility function to identify string instructions

2017-05-05 Thread Ricardo Neri
String instructions are special because in protected mode, the linear address is always obtained via the ES segment register in operands that use the (E)DI register. Segment override prefixes are ignored. non- string instructions use DS as the default segment register and it can be overridden with

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

2017-05-05 Thread Ricardo Neri
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. Thus, simply print an error message. To prevent this warning from being abused from user space programs, use the rate-limited variant of printk.

[PATCH v7 15/26] x86/insn-eval: Incorporate segment base and limit in linear address computation

2017-05-05 Thread Ricardo Neri
insn_get_addr_ref() returns the effective address as defined by the section 3.7.5.1 Vol 1 of the Intel 64 and IA-32 Architectures Software Developer's Manual. In order to compute the linear address, we must add to the effective address the segment base address as set in the segment descriptor.

[PATCH v7 11/26] x86/insn-eval: Add utility function to get segment descriptor

2017-05-05 Thread Ricardo Neri
The segment descriptor contains information that is relevant to how linear address need to be computed. It contains the default size of addresses as well as the base address of the segment. Thus, given a segment selector, we ought look at segment descriptor to correctly calculate the linear

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

2017-05-05 Thread Ricardo Neri
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 64-bit signed variables (only for 64-bit builds). To decide on whether

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

2017-05-05 Thread Ricardo Neri
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 legacy modes. For virtual-8086 mode, the default address and operand sizes

[PATCH v7 12/26] x86/insn-eval: Add utility functions to get segment descriptor base address and limit

2017-05-05 Thread Ricardo Neri
With segmentation, the base address of the segment descriptor is needed to compute a linear address. The segment descriptor used in the address computation depends on either any segment override prefixes in the instruction or the default segment determined by the registers involved in the address

[PATCH v7 10/26] x86/insn-eval: Add utility functions to get segment selector

2017-05-05 Thread Ricardo Neri
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 of the cases, the segment base address will be zero as in USER_DS/USER32_DS. However, it may be possible that a user space program defines its own segments

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

2017-05-05 Thread Ricardo Neri
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 registers are used in the computation of the effective address. A return

[PATCH v7 24/26] x86: Enable User-Mode Instruction Prevention

2017-05-05 Thread Ricardo Neri
User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a bit in %cr4. It makes sense to enable UMIP at some point while booting, before user spaces come up. Like SMAP and SMEP, is not critical to have it enabled very early during boot. This is because UMIP is relevant only when

[PATCH v7 26/26] selftests/x86: Add tests for instruction str and sldt

2017-05-05 Thread Ricardo Neri
The instructions str and sldt are not recognized when running on virtual- 8086 mode and generate an invalid operand exception. These two instructions are protected by the Intel User-Mode Instruction Prevention (UMIP) security feature. In protected mode, if UMIP is enabled, these instructions

[PATCH v7 25/26] selftests/x86: Add tests for User-Mode Instruction Prevention

2017-05-05 Thread Ricardo Neri
Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a

[PATCH v7 17/26] x86/insn-eval: Handle 32-bit address encodings in virtual-8086 mode

2017-05-05 Thread Ricardo Neri
It is possible to utilize 32-bit address encodings in virtual-8086 mode via an address override instruction prefix. However, the range of address is still limited to [0x-0x]. In such a case, return error. Also, linear addresses in virtual-8086 mode are limited to 20 bits. Enforce such limit

[PATCH v7 00/26] x86: Enable User-Mode Instruction Prevention

2017-05-05 Thread Ricardo Neri
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 the handling of exceptions unrelated to UMIP as well as corner cases in virtual-8086 mode. Please

Re: [v6 PATCH 08/21] x86/insn-eval: Add utility function to get segment descriptor base address

2017-05-05 Thread Borislav Petkov
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 > specific cases such as CS. ... and depending on whether in long mode or not. > On an unrelated

Re: [v6 PATCH 08/21] x86/insn-eval: Add utility function to get segment descriptor base address

2017-05-05 Thread Borislav Petkov
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. > Since there is a segment override prefix for all of them, I thought I > could use them.