--- /dev/null
+;------------------------------------------------------------------------------\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
--- /dev/null
+/** @file\r
+ SMBASE relocation for hot-plugged CPUs.\r
+\r
+ Copyright (c) 2020, Red Hat, Inc.\r
+\r
+ SPDX-License-Identifier: BSD-2-Clause-Patent\r
+**/\r
+\r
+#include <Base.h> // BASE_1MB\r
+#include <Library/BaseMemoryLib.h> // CopyMem()\r
+#include <Library/DebugLib.h> // DEBUG()\r
+\r
+#include "Smbase.h"\r
+\r
+extern CONST UINT8 mPostSmmPen[];\r
+extern CONST UINT16 mPostSmmPenSize;\r
+\r
+/**\r
+ Allocate a non-SMRAM reserved memory page for the Post-SMM Pen for hot-added\r
+ CPUs.\r
+\r
+ This function may only be called from the entry point function of the driver.\r
+\r
+ @param[out] PenAddress The address of the allocated (normal RAM) reserved\r
+ page.\r
+\r
+ @param[in] BootServices Pointer to the UEFI boot services table. Used for\r
+ allocating the normal RAM (not SMRAM) reserved page.\r
+\r
+ @retval EFI_SUCCESS Allocation successful.\r
+\r
+ @retval EFI_BAD_BUFFER_SIZE The Post-SMM Pen template is not smaller than\r
+ EFI_PAGE_SIZE.\r
+\r
+ @return Error codes propagated from underlying services.\r
+ DEBUG_ERROR messages have been logged. No\r
+ resources have been allocated.\r
+**/\r
+EFI_STATUS\r
+SmbaseAllocatePostSmmPen (\r
+ OUT UINT32 *PenAddress,\r
+ IN CONST EFI_BOOT_SERVICES *BootServices\r
+ )\r
+{\r
+ EFI_STATUS Status;\r
+ EFI_PHYSICAL_ADDRESS Address;\r
+\r
+ //\r
+ // The pen code must fit in one page, and the last byte must remain free for\r
+ // signaling the SMM Monarch.\r
+ //\r
+ if (mPostSmmPenSize >= EFI_PAGE_SIZE) {\r
+ Status = EFI_BAD_BUFFER_SIZE;\r
+ DEBUG ((DEBUG_ERROR, "%a: mPostSmmPenSize=%u: %r\n", __FUNCTION__,\r
+ mPostSmmPenSize, Status));\r
+ return Status;\r
+ }\r
+\r
+ Address = BASE_1MB - 1;\r
+ Status = BootServices->AllocatePages (AllocateMaxAddress,\r
+ EfiReservedMemoryType, 1, &Address);\r
+ if (EFI_ERROR (Status)) {\r
+ DEBUG ((DEBUG_ERROR, "%a: AllocatePages(): %r\n", __FUNCTION__, Status));\r
+ return Status;\r
+ }\r
+\r
+ DEBUG ((DEBUG_INFO, "%a: Post-SMM Pen at 0x%Lx\n", __FUNCTION__, Address));\r
+ *PenAddress = (UINT32)Address;\r
+ return EFI_SUCCESS;\r
+}\r
+\r
+/**\r
+ Copy the Post-SMM Pen template code into the reserved page allocated with\r
+ SmbaseAllocatePostSmmPen().\r
+\r
+ Note that this effects an "SMRAM to normal RAM" copy.\r
+\r
+ The SMM Monarch is supposed to call this function from the root MMI handler.\r
+\r
+ @param[in] PenAddress The allocation address returned by\r
+ SmbaseAllocatePostSmmPen().\r
+**/\r
+VOID\r
+SmbaseReinstallPostSmmPen (\r
+ IN UINT32 PenAddress\r
+ )\r
+{\r
+ CopyMem ((VOID *)(UINTN)PenAddress, mPostSmmPen, mPostSmmPenSize);\r
+}\r
+\r
+/**\r
+ Release the reserved page allocated with SmbaseAllocatePostSmmPen().\r
+\r
+ This function may only be called from the entry point function of the driver,\r
+ on the error path.\r
+\r
+ @param[in] PenAddress The allocation address returned by\r
+ SmbaseAllocatePostSmmPen().\r
+\r
+ @param[in] BootServices Pointer to the UEFI boot services table. Used for\r
+ releasing the normal RAM (not SMRAM) reserved page.\r
+**/\r
+VOID\r
+SmbaseReleasePostSmmPen (\r
+ IN UINT32 PenAddress,\r
+ IN CONST EFI_BOOT_SERVICES *BootServices\r
+ )\r
+{\r
+ BootServices->FreePages (PenAddress, 1);\r
+}\r