Re: [PATCH] KVM: x86: fix #UD address of failed Hyper-V hypercalls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2018-05-24 18:22+0200, Paolo Bonzini:
> On 24/05/2018 18:08, Konrad Rzeszutek Wilk wrote:
> > On Thu, May 24, 2018 at 05:50:56PM +0200, Radim Krčmář wrote:
> >> If the hypercall was called from userspace or real mode, KVM injects #UD
> >> and then advances RIP, so it looks like #UD was caused by the following
> >> instruction.  This probably won't cause more than confusion, but could
> >> give an unexpected access to guest OS' instruction emulator.
> >
> > What does the SDM say about this? Or does the HyperV specification give
> > a firm statement that this is the expectation ?
> 
> #UD is a fault and its RIP always points to the instruction that caused
> the exception.  But you of course know this already, so I'm not sure I
> understand the question.

That was my reasoning.  And for completeness, TLFS only says this:

  Hypercalls can be invoked only from the most privileged guest processor
  mode. In the case of x64, this means protected mode with a current
  privilege level (CPL) of zero.  Although real-mode code runs with an
  effective CPL of zero, hypercalls are not allowed in real mode. An
  attempt to invoke a hypercall within an illegal processor mode will
  generate a #UD (undefined operation) exception.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux