Message-ID: <ZfCIz8JIziuvl8Xp@google.com>
Date: Tue, 12 Mar 2024 09:54:39 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Kai Huang <kai.huang@...el.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org, kvm@...r.kernel.org, 
	michael.roth@....com, isaku.yamahata@...el.com, thomas.lendacky@....com
Subject: Re: [PATCH 07/21] KVM: VMX: Introduce test mode related to EPT
 violation VE

On Tue, Mar 12, 2024, Kai Huang wrote:
> On 28/02/2024 12:20 pm, Paolo Bonzini wrote:
> > From: Isaku Yamahata <isaku.yamahata@...el.com>
> > 
> > To support TDX, KVM is enhanced to operate with #VE.  For TDX, KVM uses the
> > suppress #VE bit in EPT entries selectively, in order to be able to trap
> > non-present conditions.  However, #VE isn't used for VMX and it's a bug
> > if it happens.  To be defensive and test that VMX case isn't broken
> > introduce an option ept_violation_ve_test and when it's set, BUG the vm.
> 
> I am wondering from HW's point of view, is it OK for the kernel to
> explicitly send #VE IPI, in which case, IIUC, the guest can legally get the
> #VE w/o being a TDX guest?

Ooh, fun.  Short answer: there's nothing to worry about here.

Legally, no.  Vectors 0-31 are reserved.  However, I do _think_ the guest could
technically send IPIs on vectors 16-31, as the local APIC doesn't outright reject
such vectors.  But such software would be in clear violation of the SDM.

  11.5.2 Valid Interrupt Vectors
  
  The Intel 64 and IA-32 architectures define 256 vector numbers, ranging from
  0 through 255 (see Section 6.2, “Exception and Interrupt Vectors”). Local and
  I/O APICs support 240 of these vectors (in the range of 16 to 255) as valid
  interrupts.
  
  When an interrupt vector in the range of 0 to 15 is sent or received through
  the local APIC, the APIC indicates an illegal vector in its Error Status
  Register (see Section 11.5.3, “Error Handling”). The Intel 64 and IA-32
  architectures reserve vectors 16 through 31 for predefined interrupts,
  exceptions, and Intel-reserved encodings (see Table 6-1). However, the local
  APIC does not treat vectors in this range as illegal.

  When an illegal vector value (0 to 15) is written to an LVT entry and the delivery
  mode is Fixed (bits 8-11 equal 0), the APIC may signal an illegal vector error,
  without regard to whether the mask bit is set or whether an interrupt is actually
  seen on the input.

where Table 6-1 defines the various exceptions, including #VE, and for vectors
22-31 says "Intel reserved. Do not use."  Vectors 32-255 are explicitly described
as "User Defined (Non-reserved) Interrupts" that can be generated via "External
interrupt or INT n instruction."

However, INTn is far more interesting than IPIs, as INTn can definitely generate
interrupts for vectors 0-31, and the legality of software generating such interrupts
is questionable.  E.g. KVM used to "forward" NMI VM-Exits to the kernel by doing
INTn with vector 2.

Key word "interrupts"!  IPIs are hardware interrupts, and INTn generates software
interrupts, neither of which are subject to exception bitmap interception:

  Exceptions (faults, traps, and aborts) cause VM exits based on the exception
  bitmap (see Section 25.6.3). If an exception occurs, its vector (in the range
  0–31) is used to select a bit in the exception bitmap. If the bit is 1, a VM
  exit occurs; if the bit is 0, the exception is delivered normally through the
  guest IDT. This use of the exception bitmap applies also to exceptions generated
  by the instructions INT1, INT3, INTO, BOUND, UD0, UD1, and UD2.

with a footnote that further says:

  INT1 and INT3 refer to the instructions with opcodes F1 and CC, respectively,
  and not to INT n with value 1 or 3 for n.

So while a misbehaving guest could generate a software interrupt on vector 20,
it would not be a true #VE, i.e. not an exception, and thus would not generate
an EXCEPTION_NMI VM-Exit.  I.e. the KVM_BUG_ON() can't be triggered by the guest
(assuming hardware isn't broken).

Powered by blists - more mailing lists