UefiCpuPkg: Move AsmRelocateApLoopStart from Mpfuncs.nasm to AmdSev.nasm

[mirror_edk2.git] / OvmfPkg / CpuHotplugSmm / PostSmmPen.nasm

;------------------------------------------------------------------------------\r
; @file\r
; Pen any hot-added CPU in a 16-bit, real mode HLT loop, after it leaves SMM by\r
; executing the RSM instruction.\r
;\r
; Copyright (c) 2020, Red Hat, Inc.\r
;\r
; SPDX-License-Identifier: BSD-2-Clause-Patent\r
;\r
; The routine implemented here is stored into normal RAM, under 1MB, at the\r
; beginning of a page that is allocated as EfiReservedMemoryType. On any\r
; hot-added CPU, it is executed after *at least* the first RSM (i.e., after\r
; SMBASE relocation).\r
;\r
; The first execution of this code occurs as follows:\r
;\r
; - The hot-added CPU is in RESET state.\r
;\r
; - The ACPI CPU hotplug event handler triggers a broadcast SMI, from the OS.\r
;\r
; - Existent CPUs (BSP and APs) enter SMM.\r
;\r
; - The hot-added CPU remains in RESET state, but an SMI is pending for it now.\r
;   (See "SYSTEM MANAGEMENT INTERRUPT (SMI)" in the Intel SDM.)\r
;\r
; - In SMM, pre-existent CPUs that are not elected SMM Monarch, keep themselves\r
;   busy with their wait loops.\r
;\r
; - From the root MMI handler, the SMM Monarch:\r
;\r
;   - places this routine in the reserved page,\r
;\r
;   - clears the "about to leave SMM" byte in SMRAM,\r
;\r
;   - clears the last byte of the reserved page,\r
;\r
;   - sends an INIT-SIPI-SIPI sequence to the hot-added CPU,\r
;\r
;   - un-gates the default SMI handler by APIC ID.\r
;\r
; - The startup vector in the SIPI that is sent by the SMM Monarch points to\r
;   this code; i.e., to the reserved page. (Example: 0x9_F000.)\r
;\r
; - The SMM Monarch starts polling the "about to leave SMM" byte in SMRAM.\r
;\r
; - The hot-added CPU boots, and immediately enters SMM due to the pending SMI.\r
;   It starts executing the default SMI handler.\r
;\r
; - Importantly, the SMRAM Save State Map captures the following information,\r
;   when the hot-added CPU enters SMM:\r
;\r
;   - CS selector: assumes the 16 most significant bits of the 20-bit (i.e.,\r
;     below 1MB) startup vector from the SIPI. (Example: 0x9F00.)\r
;\r
;   - CS attributes: Accessed, Readable, User (S=1), CodeSegment (bit#11),\r
;     Present.\r
;\r
;   - CS limit: 0xFFFF.\r
;\r
;   - CS base: the CS selector value shifted left by 4 bits. That is, the CS\r
;     base equals the SIPI startup vector. (Example: 0x9_F000.)\r
;\r
;   - IP: the least significant 4 bits from the SIPI startup vector. Because\r
;     the routine is page-aligned, these bits are zero (hence IP is zero).\r
;\r
;   - ES, SS, DS, FS, GS selectors: 0.\r
;\r
;   - ES, SS, DS, FS, GS attributes: same as the CS attributes, minus\r
;     CodeSegment (bit#11).\r
;\r
;   - ES, SS, DS, FS, GS limits: 0xFFFF.\r
;\r
;   - ES, SS, DS, FS, GS bases: 0.\r
;\r
; - The hot-added CPU sets its new SMBASE value in the SMRAM Save State Map.\r
;\r
; - The hot-added CPU sets the "about to leave SMM" byte in SMRAM, then\r
;   executes the RSM instruction immediately after, leaving SMM.\r
;\r
; - The SMM Monarch notices that the "about to leave SMM" byte in SMRAM has\r
;   been set, and starts polling the last byte in the reserved page.\r
;\r
; - The hot-added CPU jumps ("returns") to the code below (in the reserved\r
;   page), according to the register state listed in the SMRAM Save State Map.\r
;\r
; - The hot-added CPU sets the last byte of the reserved page, then halts\r
;   itself.\r
;\r
; - The SMM Monarch notices that the hot-added CPU is done with SMBASE\r
;   relocation.\r
;\r
; Note that, if the OS is malicious and sends INIT-SIPI-SIPI to the hot-added\r
; CPU before allowing the ACPI CPU hotplug event handler to trigger a broadcast\r
; SMI, then said broadcast SMI will yank the hot-added CPU directly into SMM,\r
; without becoming pending for it (as the hot-added CPU is no longer in RESET\r
; state). This is OK, because:\r
;\r
; - The default SMI handler copes with this, as it is gated by APIC ID. The\r
;   hot-added CPU won't start the actual SMBASE relocation until the SMM\r
;   Monarch lets it.\r
;\r
; - The INIT-SIPI-SIPI sequence that the SMM Monarch sends to the hot-added CPU\r
;   will be ignored in this sate (it won't even be latched). See "SMI HANDLER\r
;   EXECUTION ENVIRONMENT" in the Intel SDM: "INIT operations are inhibited\r
;   when the processor enters SMM".\r
;\r
; - When the hot-added CPU (e.g., CPU#1) executes the RSM (having relocated\r
;   SMBASE), it returns to the OS. The OS can use CPU#1 to attack the last byte\r
;   of the reserved page, while another CPU (e.g., CPU#2) is relocating SMBASE,\r
;   in order to trick the SMM Monarch (e.g., CPU#0) to open the APIC ID gate\r
;   for yet another CPU (e.g., CPU#3). However, the SMM Monarch won't look at\r
;   the last byte of the reserved page, until CPU#2 sets the "about to leave\r
;   SMM" byte in SMRAM. This leaves a very small window (just one instruction's\r
;   worth before the RSM) for CPU#3 to "catch up" with CPU#2, and overwrite\r
;   CPU#2's SMBASE with its own.\r
;\r
; In other words, we do not / need not prevent a malicious OS from booting the\r
; hot-added CPU early; instead we provide benign OSes with a pen for hot-added\r
; CPUs.\r
;------------------------------------------------------------------------------\r
\r
SECTION .data\r
BITS 16\r
\r
GLOBAL ASM_PFX (mPostSmmPen)     ; UINT8[]\r
GLOBAL ASM_PFX (mPostSmmPenSize) ; UINT16\r
\r
ASM_PFX (mPostSmmPen):\r
  ;\r
  ; Point DS at the same reserved page.\r
  ;\r
  mov ax, cs\r
  mov ds, ax\r
\r
  ;\r
  ; Inform the SMM Monarch that we're done with SMBASE relocation, by setting\r
  ; the last byte in the reserved page.\r
  ;\r
  mov byte [ds : word 0xFFF], 1\r
\r
  ;\r
  ; Halt now, until we get woken by another SMI, or (more likely) the OS\r
  ; reboots us with another INIT-SIPI-SIPI.\r
  ;\r
HltLoop:\r
  cli\r
  hlt\r
  jmp HltLoop\r
\r
ASM_PFX (mPostSmmPenSize):\r
  dw $ - ASM_PFX (mPostSmmPen)\r