1. 20 11月, 2014 2 次提交
    • N
      KVM: x86: Stack size is overridden by __linearize · 1c1c35ae
      Nadav Amit 提交于
      When performing segmented-read/write in the emulator for stack operations, it
      ignores the stack size, and uses the ad_bytes as indication for the pointer
      size. As a result, a wrong address may be accessed.
      
      To fix this behavior, we can remove the masking of address in __linearize and
      perform it beforehand.  It is already done for the operands (so currently it is
      inefficiently done twice). It is missing in two cases:
      1. When using rip_relative
      2. On fetch_bit_operand that changes the address.
      
      This patch masks the address on these two occassions, and removes the masking
      from __linearize.
      
      Note that it does not mask EIP during fetch. In protected/legacy mode code
      fetch when RIP >= 2^32 should result in #GP and not wrap-around. Since we make
      limit checks within __linearize, this is the expected behavior.
      
      Partial revert of commit 518547b3 (KVM: x86: Emulator does not
      calculate address correctly, 2014-09-30).
      Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      1c1c35ae
    • N
      KVM: x86: Revert NoBigReal patch in the emulator · 7d882ffa
      Nadav Amit 提交于
      Commit 10e38fc7cab6 ("KVM: x86: Emulator flag for instruction that only support
      16-bit addresses in real mode") introduced NoBigReal for instructions such as
      MONITOR. Apparetnly, the Intel SDM description that led to this patch is
      misleading.  Since no instruction is using NoBigReal, it is safe to remove it,
      we fully understand what the SDM means.
      Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      7d882ffa
  2. 08 11月, 2014 3 次提交
  3. 07 11月, 2014 10 次提交
  4. 03 11月, 2014 7 次提交
  5. 02 11月, 2014 1 次提交
  6. 29 10月, 2014 3 次提交
    • N
      KVM: x86: Fix far-jump to non-canonical check · cd9b8e2c
      Nadav Amit 提交于
      Commit d1442d85 ("KVM: x86: Handle errors when RIP is set during far
      jumps") introduced a bug that caused the fix to be incomplete.  Due to
      incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit
      segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may
      not trigger #GP.  As we know, this imposes a security problem.
      
      In addition, the condition for two warnings was incorrect.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
      [Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      cd9b8e2c
    • P
      KVM: emulator: fix execution close to the segment limit · fd56e154
      Paolo Bonzini 提交于
      Emulation of code that is 14 bytes to the segment limit or closer
      (e.g. RIP = 0xFFFFFFF2 after reset) is broken because we try to read as
      many as 15 bytes from the beginning of the instruction, and __linearize
      fails when the passed (address, size) pair reaches out of the segment.
      
      To fix this, let __linearize return the maximum accessible size (clamped
      to 2^32-1) for usage in __do_insn_fetch_bytes, and avoid the limit check
      by passing zero for the desired size.
      
      For expand-down segments, __linearize is performing a redundant check.
      (u32)(addr.ea + size - 1) <= lim can only happen if addr.ea is close
      to 4GB; in this case, addr.ea + size - 1 will also fail the check against
      the upper bound of the segment (which is provided by the D/B bit).
      After eliminating the redundant check, it is simple to compute
      the *max_size for expand-down segments too.
      
      Now that the limit check is done in __do_insn_fetch_bytes, we want
      to inject a general protection fault there if size < op_size (like
      __linearize would have done), instead of just aborting.
      
      This fixes booting Tiano Core from emulated flash with EPT disabled.
      
      Cc: stable@vger.kernel.org
      Fixes: 719d5a9bReported-by: NBorislav Petkov <bp@suse.de>
      Tested-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      fd56e154
    • P
      KVM: emulator: fix error code for __linearize · 3606189f
      Paolo Bonzini 提交于
      The error code for #GP and #SS is zero when the segment is used to
      access an operand or an instruction.  It is only non-zero when
      a segment register is being loaded; for limit checks this means
      cases such as:
      
      * for #GP, when RIP is beyond the limit on a far call (before the first
      instruction is executed).  We do not implement this check, but it
      would be in em_jmp_far/em_call_far.
      
      * for #SS, if the new stack overflows during an inter-privilege-level
      call to a non-conforming code segment.  We do not implement stack
      switching at all.
      
      So use an error code of zero.
      Reviewed-by: NNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3606189f
  7. 24 10月, 2014 7 次提交
  8. 24 9月, 2014 1 次提交
    • N
      KVM: x86: emulating descriptor load misses long-mode case · 040c8dc8
      Nadav Amit 提交于
      In 64-bit mode a #GP should be delivered to the guest "if the code segment
      descriptor pointed to by the selector in the 64-bit gate doesn't have the L-bit
      set and the D-bit clear." - Intel SDM "Interrupt 13—General Protection
      Exception (#GP)".
      
      This patch fixes the behavior of CS loading emulation code. Although the
      comment says that segment loading is not supported in long mode, this function
      is executed in long mode, so the fix is necassary.
      Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      040c8dc8
  9. 29 8月, 2014 3 次提交
    • P
      KVM: x86: remove Aligned bit from movntps/movntpd · d5b77069
      Paolo Bonzini 提交于
      These are not explicitly aligned, and do not require alignment on AVX.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d5b77069
    • A
      KVM: x86 emulator: emulate MOVNTDQ · 0a37027e
      Alex Williamson 提交于
      Windows 8.1 guest with NVIDIA driver and GPU fails to boot with an
      emulation failure.  The KVM spew suggests the fault is with lack of
      movntdq emulation (courtesy of Paolo):
      
      Code=02 00 00 b8 08 00 00 00 f3 0f 6f 44 0a f0 f3 0f 6f 4c 0a e0 <66> 0f e7 41 f0 66 0f e7 49 e0 48 83 e9 40 f3 0f 6f 44 0a 10 f3 0f 6f 0c 0a 66 0f e7 41 10
      
      $ as -o a.out
              .section .text
              .byte 0x66, 0x0f, 0xe7, 0x41, 0xf0
              .byte 0x66, 0x0f, 0xe7, 0x49, 0xe0
      $ objdump -d a.out
          0:  66 0f e7 41 f0          movntdq %xmm0,-0x10(%rcx)
          5:  66 0f e7 49 e0          movntdq %xmm1,-0x20(%rcx)
      
      Add the necessary emulation.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0a37027e
    • N
      KVM: vmx: VMXOFF emulation in vm86 should cause #UD · 0f54a321
      Nadav Amit 提交于
      Unlike VMCALL, the instructions VMXOFF, VMLAUNCH and VMRESUME should cause a UD
      exception in real-mode or vm86.  However, the emulator considers all these
      instructions the same for the matter of mode checks, and emulation upon exit
      due to #UD exception.
      
      As a result, the hypervisor behaves incorrectly on vm86 mode. VMXOFF, VMLAUNCH
      or VMRESUME cause on vm86 exit due to #UD. The hypervisor then emulates these
      instruction and inject #GP to the guest instead of #UD.
      
      This patch creates a new group for these instructions and mark only VMCALL as
      an instruction which can be emulated.
      Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0f54a321
  10. 20 8月, 2014 2 次提交
  11. 19 8月, 2014 1 次提交