On 09/02/19 10:45, Igor Mammedov wrote: > On Fri, 30 Aug 2019 20:46:14 +0200 > Laszlo Ersek <ler...@redhat.com> wrote: > >> On 08/30/19 16:48, Igor Mammedov wrote: >> >>> (01) On boot firmware maps and initializes SMI handler at default SMBASE >>> (30000) >>> (using dedicated SMRAM at 30000 would allow us to avoid save/restore >>> steps and make SMM handler pointer not vulnerable to DMA attacks) >>> >>> (02) QEMU hotplugs a new CPU in reset-ed state and sends SCI >>> >>> (03) on receiving SCI, host CPU calls GPE cpu hotplug handler >>> which writes to IO port 0xB2 (broadcast SMI) >>> >>> (04) firmware waits for all existing CPUs rendezvous in SMM mode, >>> new CPU(s) have SMI pending but does nothing yet >>> >>> (05) host CPU wakes up one new CPU (INIT-INIT-SIPI) >>> SIPI vector points to RO flash HLT loop. >>> (how host CPU will know which new CPUs to relocate? >>> possibly reuse QEMU CPU hotplug MMIO interface???) >>> >>> (06) new CPU does relocation. >>> (in case of attacker sends SIPI to several new CPUs, >>> open question how to detect collision of several CPUs at the same >>> default SMBASE) >>> >>> (07) once new CPU relocated host CPU completes initialization, returns >>> from IO port write and executes the rest of GPE handler, telling OS >>> to online new CPU. >> >> In step (03), it is the OS that handles the SCI; it transfers control to >> ACPI. The AML can write to IO port 0xB2 only because the OS allows it. >> >> If the OS decides to omit that step, and sends an INIT-SIPI-SIPI >> directly to the new CPU, can it steal the CPU? > It sure can but this way it won't get access to privileged SMRAM > so OS can't subvert firmware. > The next time SMI broadcast is sent the CPU will use SMI handler at > default 30000 SMBASE. It's up to us to define behavior here (for example > relocation handler can put such CPU in shutdown state). > > It's in the best interest of OS to cooperate and execute AML > provided by firmware, if it does not follow proper cpu hotplug flow > we can't guarantee that stolen CPU will work.
This sounds convincing enough, for the hotplugged CPU; thanks. So now my concern is with step (01). While preparing for the initial relocation (of cold-plugged CPUs), the code assumes the memory at the default SMBASE (0x30000) is normal RAM. Is it not a problem that the area is written initially while running in normal 32-bit or 64-bit mode, but then executed (in response to the first, synchronous, SMI) as SMRAM? Basically I'm confused by the alias. TSEG (and presumably, A/B seg) work like this: - when open, looks like RAM to normal mode and SMM - when closed, looks like black-hole to normal mode, and like RAM to SMM The generic edk2 code knows this, and manages the SMRAM areas accordingly. The area at 0x30000 is different: - looks like RAM to both normal mode and SMM If we set up the alias at 0x30000 into A/B seg, - will that *permanently* hide the normal RAM at 0x30000? - will 0x30000 start behaving like A/B seg? Basically my concern is that the universal code in edk2 might or might not keep A/B seg open while initially populating the area at the default SMBASE. Specifically, I can imagine two issues: - if the alias into A/B seg is inactive during the initial population, then the initial writes go to RAM, but the execution (the first SMBASE relocation) will occur from A/B seg through the alias - alternatively, if the alias is always active, but A/B seg is closed during initial population (which happens in normal mode), then the initial writes go to the black hole, and execution will occur from a "blank" A/B seg. Am I seeing things? (Sorry, I keep feeling dumber and dumber in this thread.) Anyway, I guess we could try and see if OVMF still boots with the alias... Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#46690): https://edk2.groups.io/g/devel/message/46690 Mute This Topic: https://groups.io/mt/32979681/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
