Volume 2 System Programming (794096), страница 99
Текст из файла (страница 99)
The VMRUNinstruction loads this information into corresponding on-chip registers.The processor takes a virtual INTR interrupt if- V_IRQ and V_INTR_PRIO indicate that there is a virtual interrupt pending whose priority isgreater than the value in V_TPR,- interrupts are enabled in EFLAGS.IF,- interrupts are enabled using GIF, and- the processor is not in an interrupt shadow (see Section 15.20.5 on page 393).The only other difference between virtual INTR handling and normal interrupt handling is that, inthe latter case, the interrupt vector is obtained from the V_INTR_VECTOR register (as opposed torunning an INTAK cycle to the local APIC).The V_IGN_TPR field in the VMCB can be set to indicate that the currently pending virtualinterrupt is not subject to masking by TPR.
The priority comparison against V_TPR is omitted inthis case. This mechanism can be used to inject ExtINT-type interrupts into the guest.When the processor dispatches a virtual interrupt (through the IDT), V_IRQ is cleared afterchecking for intercepts of virtual interrupts and before the IDT is accessed.On #VMEXIT, V_IRQ is written back to the VMCB, allowing the VMM to track whether a virtualinterrupt has been taken.392Secure Virtual Machine24593—Rev. 3.13—July 2007••AMD64 TechnologyPhysical interrupts take priority over virtual interrupts, whether they are taken directly or through a#VMEXIT.On #VMEXIT, the processor clears its internal copies of V_IRQ and V_INTR_MASKING, sovirtual interrupts do not remain pending in the VMM, and interrupt control reverts to normal.15.20.5 Interrupt ShadowsThe x86 architecture defines the notion of an interrupt shadow—a single-instruction window duringwhich interrupts are not recognized. For example, the instruction after an STI instruction that setsEFLAGS.IF (from zero to one) does not recognize interrupts or certain debug traps.
The VMCBINTERRUPT_SHADOW field indicates whether the guest is currently in an interrupt shadow. Thisinformation is saved on #VMEXIT and loaded on VMRUN.15.20.6 Virtual Interrupt InterceptWhen virtualizing interrupt handling, a VMM typically needs only gain control when new interruptsfor a guest arrive or are generated, and when the guest issues an EOI (end-of-interrupt).
In somecircumstances, it may also be necessary for the VMM to gain control at the moment interrupts becomeenabled in the guest (i.e., just before the guest takes a virtual interrupt). The VMM can do so byenabling the VINTR intercept.15.20.7 INIT SupportThe INIT signal interrupts the processor at the next instruction boundary and causes an unconditionalcontrol transfer.
INIT reinitializes the control registers, segment registers and GP registers in a mannersimilar to RESET#, but does not alter the contents of most MSRs, caches or numeric coprocessor (x87or SSE) state, and then transfers control to the same instruction address as RESET# (physical addressFFFFFFF0h). Unlike RESET#, INIT is not expected to be visible to the memory controller, and hencewill not trigger automatic clearing of trusted memory pages by memory controller hardware.To maintain the security of such pages, the VMM can request that INITs be redirected and turned into#SX exceptions by setting the R_INIT bit in the VM_CR MSR (see Section 15.28.1, “VM_CR MSR(C001_0114h),” on page 417). This allows the VMM to gain control when an INIT is requested.
TheVMM may thus disable the redirection of INIT and then cause the platform to reassert INIT, at whichpoint the processor will respond in the normal manner. The actions initiated by the INIT pin may alsobe initiated by an incoming APIC INIT interrupt; the mechanisms described here apply in either case.Table 15-6 on page 393 summarizes the handling of INITs.Table 15-6.
INIT Handling in Different Operating ModesGIF INIT Intercept INIT Redirect01Secure Virtual MachineProcessor Response to INITxxHold pending until GIF = 1.1x#VMEXIT(INIT), INIT is still pending.0Taken normally.1#SX, INIT is no longer pending.0393AMD64 Technology24593—Rev. 3.13—July 200715.20.8 NMI SupportThe VMM can intercept non-maskable interrupts (NMI) using a VMCB control bit (see Table 15-7).When intercepted, NMIs cause an exit from the guest and are held pending.Table 15-7. NMI Handling in Different Operating ModesGIFNMI Intercept0XHold pending until GIF=1.1#VMEXIT(NMI), NMI is still pending.0Taken normally.115.21Processor Response to NMISMM SupportThis section describes SVM support for virtualization of System Management Mode (SMM).15.21.1 Sources of SMIVarious events can cause an assertion of a system management interrupt (SMI); these are classifiedinto three categories•••Internal, synchronous (also known as I/O Trapping)—implementation-specific IOIO or configspace trapping in the CPU itself; always synchronous in response to an IN or OUT instruction.
I/OTrapping is set up by means of MSRs and can be brought under the control of the VMM byintercepting guest access to those MSRs.External, synchronous—IOIO trapping in response to (and synchronous with) IN or OUTinstructions, but generated by an external agent (typically the Southbridge).External, asynchronous—generated externally in response to an external, physical event, e.g.,closing a laptop lid, temperature sensor triggering, etc.15.21.2 Response to SMIHow hardware responds to SMIs is a function of whether SMM interrupts are being intercepted andwhether interrupts are enabled globally, as shown in Table 15-8.Table 15-8.SMI Handling in Different Operating ModesGIFInterceptSMI0xLost.1Exit guest,#VMEXIT(SMI), SMI is still pending.code #VMEXIT(SMI), SMI is not pending.0Taken normally.1Internal SMIExternal SMIHold pending until GIF=1.Taken normally.By intercepting SMIs, the VMM can gain control before the processor enters SMM.394Secure Virtual Machine24593—Rev.
3.13—July 2007AMD64 Technology15.21.3 Containerizing Platform SMMIn some usage scenarios, the VMM may not trust the existing platform SMM code, or may otherwisewant to ensure that the SMM does not operate in the context of certain guests or the hypervisor. Toaddress these cases, SVM provides the ability to containerize SMM code, i.e., run it inside a guest,with the full protection mechanisms of the VMM in place.
In other scenarios, the VMM may not wantto exert control over SMM.There are three solutions for the VMM to control SMM handlers:•••The simplest solution is to not intercept SMI signals. SMIs encountered while in a guest contextare taken from within the guest context. In this case, the SMM handler is not subject to anyintercepts set up by the VMM and consequently runs outside of the virtualization controls.
Thestate saved in the SMM State-Save area as seen by the SMM handler reflects the state of the guestthat had been running at the time the SMI was encountered. When the SMM handler executes theRSM instruction, the processor returns to executing in the guest context, and any modifications tothe SMM State-Save area made by the SMM handler is reflected in the guest state.A hypervisor may want to emulate all SMI-based I/O interceptions for a guest and to take SMIsignals only in the hypervisor context. The hypervisor should set all IOIO intercept bits and theSMI intercept bit for the guest to ensure that there is no possibility of encountering synchronous(internal or external) SMI signals while running the guest.
Any #VMEXIT(SMI) encountered isthen known to be due to an external, asynchronous SMI. The hypervisor may respond to the#VMEXIT(SMI) by executing the STGI instruction, which causes the pending SMI to be takenimmediately. When an SMI due to an I/O instruction is pending, the effect of executing STGI in thehypervisor is undefined. To handle a pending SMI due to an I/O instruction, the hypervisor musteither containerize SMM or not intercept SMI.The most involved solution is to containerize SMM by placing it in a guest. Containerizing givesthe VMM full control over the state that the SMM handler can access.Containerizing Platform SMM. A VMM can containerize SMM by creating its own trusted SMMhypervisor and use that handler to run the platform SMM code in a container.
The SMM hypervisormay be the same code as the VMM itself, or may be an entirely different set of code. The trusted SMMhypervisor sets up a guest context to run the platform SMM as a guest. The guest context consists of aVMCB and related state and the guest's (real or virtual) SMM save area. The SMM hypervisoremulates SMM entry, including setup of the SMM save area, and emulates RSM at the end of SMMoperation. The guest executes the platform SMM code in paged real mode with appropriate SVMintercepts in place, thus ensuring security.For this approach to work, the VMM may need to write the SMM_BASE MSR, as well as relatedSMM control registers. As part of the emulation of SMM entry and RSM, the VMM needs to accessthe SMM_CTL MSR (see Section 15.28.3, “SMM_CTL MSR (C001_0116h),” on page 418).However, these actions conflict with any BIOS that locks SMM control registers.A VMM can determine if it is running with a compatible BIOS setup by checking the SMMLOCK bitin the HWCR MSR (described in the applicable BIOS and Kernel Developer's Guide for yourSecure Virtual Machine395AMD64 Technology24593—Rev.
3.13—July 2007processor). If the bit is 1, the BIOS has locked the SMM control registers and the VMM is unable tomove them or insert its own SMM hypervisor.As the processor physically enters SMM, the SMRAM regions are remapped. The VMM design mustensure that none of its code or data disappears when the SMRAM areas are mapped or unmapped.Also note that the ASEG region of the SMRAM overlaps with a portion of video memory, so the SMMhypervisor should not attempt to write diagnostic messages to the screen.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
