From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: imammedo@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Mon, 02 Sep 2019 01:45:41 -0700 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 404DC10C6975; Mon, 2 Sep 2019 08:45:41 +0000 (UTC) Received: from localhost (unknown [10.43.2.182]) by smtp.corp.redhat.com (Postfix) with ESMTP id 85E165D6A7; Mon, 2 Sep 2019 08:45:36 +0000 (UTC) Date: Mon, 2 Sep 2019 10:45:34 +0200 From: Igor Mammedov To: Laszlo Ersek Cc: "Yao, Jiewen" , "Kinney, Michael D" , Paolo Bonzini , "rfc@edk2.groups.io" , Alex Williamson , "devel@edk2.groups.io" , qemu devel list , "Chen, Yingwen" , "Nakajima, Jun" , Boris Ostrovsky , Joao Marcal Lemos Martins , Phillip Goerl Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF Message-ID: <20190902104534.46e58c95@redhat.com> In-Reply-To: References: <8091f6e8-b1ec-f017-1430-00b0255729f4@redhat.com> <2b4ba607-f0e3-efee-6712-6dcef129b310@redhat.com> <7f2d2f1e-2dd8-6914-c55e-61067e06b142@redhat.com> <3661c0c5-3da4-1453-a66a-3e4d4022e876@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C503F76FDAF@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503F7728AB@shsmsx102.ccr.corp.intel.com> <20190827203102.56d0d048@redhat.com> <033ced1a-1399-968e-cce6-6b15a20b0baf@redhat.com> <20190830164802.1b17ff26@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.65]); Mon, 02 Sep 2019 08:45:41 +0000 (UTC) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 30 Aug 2019 20:46:14 +0200 Laszlo Ersek 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. > Thanks! > Laszlo