From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DEB0C3A59E for ; Mon, 2 Sep 2019 19:11:01 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 51C5721881 for ; Mon, 2 Sep 2019 19:11:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 51C5721881 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:39378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4rjA-0007gb-An for qemu-devel@archiver.kernel.org; Mon, 02 Sep 2019 15:11:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48112) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4riQ-0007Aq-AO for qemu-devel@nongnu.org; Mon, 02 Sep 2019 15:10:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i4riN-0002Dd-8y for qemu-devel@nongnu.org; Mon, 02 Sep 2019 15:10:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39882) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i4riN-000258-0Z for qemu-devel@nongnu.org; Mon, 02 Sep 2019 15:10:11 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4340A3082D9E; Mon, 2 Sep 2019 19:10:07 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-152.ams2.redhat.com [10.36.117.152]) by smtp.corp.redhat.com (Postfix) with ESMTP id DDC2B19C78; Mon, 2 Sep 2019 19:09:59 +0000 (UTC) To: Igor Mammedov 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> <20190902104534.46e58c95@redhat.com> From: Laszlo Ersek Message-ID: <2ef1910e-8879-028a-4db6-97a0ecc64083@redhat.com> Date: Mon, 2 Sep 2019 21:09:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190902104534.46e58c95@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Mon, 02 Sep 2019 19:10:07 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Chen, Yingwen" , "devel@edk2.groups.io" , Phillip Goerl , qemu devel list , Alex Williamson , "Yao, Jiewen" , "Nakajima, Jun" , "Kinney, Michael D" , Paolo Bonzini , Boris Ostrovsky , "rfc@edk2.groups.io" , Joao Marcal Lemos Martins Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 09/02/19 10:45, Igor Mammedov wrote: > 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. 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