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: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 21 Aug 2019 05:07:47 -0700 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 5705C195DCEA; Wed, 21 Aug 2019 12:07:47 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-79.ams2.redhat.com [10.36.117.79]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8A02D194BE; Wed, 21 Aug 2019 12:07:42 +0000 (UTC) Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF To: Paolo Bonzini , "Yao, Jiewen" Cc: Alex Williamson , "devel@edk2.groups.io" , edk2-rfc-groups-io , qemu devel list , Igor Mammedov , "Chen, Yingwen" , "Nakajima, Jun" , Boris Ostrovsky , Joao Marcal Lemos Martins , Phillip Goerl References: <8091f6e8-b1ec-f017-1430-00b0255729f4@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C503F75B680@shsmsx102.ccr.corp.intel.com> <047801f8-624a-2300-3cf7-1daa1395ce59@redhat.com> <99219f81-33a3-f447-95f8-f10341d70084@redhat.com> <6f8b9507-58d0-5fbd-b827-c7194b3b2948@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C503F75FAD3@shsmsx102.ccr.corp.intel.com> <7cb458ea-956e-c1df-33f7-025e4f0f22df@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C503F7600B9@shsmsx102.ccr.corp.intel.com> <20190816161933.7d30a881@x1.home> <74D8A39837DF1E4DA445A8C0B3885C503F761B96@shsmsx102.ccr.corp.intel.com> <35396800-32d2-c25f-b0d0-2d7cd8438687@redhat.com> <4afa24cb-1ab7-b085-ba84-70271712d62e@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 21 Aug 2019 14:07:41 +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: <4afa24cb-1ab7-b085-ba84-70271712d62e@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.62]); Wed, 21 Aug 2019 12:07:47 +0000 (UTC) Content-Type: text/plain; charset=iso-2022-jp Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/19/19 16:10, Paolo Bonzini wrote: > On 19/08/19 01:00, Yao, Jiewen wrote: >> in real world, we deprecate AB-seg usage because they are vulnerable >> to smm cache poison attack. I assume cache poison is out of scope in >> the virtual world, or there is a way to prevent ABseg cache poison. > > Indeed the SMRR would not cover the A-seg on real hardware. However, if > the chipset allowed aliasing A-seg SMRAM to 0x30000, it would only be > used for SMBASE relocation of hotplugged CPU. The firmware would still > keep low SMRAM disabled, *except around SMBASE relocation of hotplugged > CPUs*. To avoid cache poisoning attacks, you only have to issue a > WBINVD before enabling low SMRAM and before disabling it. Hotplug SMI > is not a performance-sensitive path, so it's not a big deal. > > So I guess you agree that PCI DMA attacks are a potential vector also on > real hardware. As Alex pointed out, VT-d is not a solution because > there could be legitimate DMA happening during CPU hotplug. Alex, thank you for the help! Please let us know if we should remove you from the CC list, in order not to clutter your inbox. (I've kept your address for now, for saying thanks. Feel free to stop reading here. Thanks!) > For OVMF > we'll probably go with Igor's idea, it would be nice if Intel chipsets > supported it too. :) So what is Igor's idea? Please do spoon-feed it to me. I've seen the POC patch but the memory region manipulation isn't obvious to me. Regarding TSEG, QEMU doesn't implement it differently from normal RAM. Instead, if memory serves, there is an extra "black hole" region that is overlaid, which hides the RAM contents when TSEG is supposed to be closed (and the guest is not running in SMM). But this time we're doing something else, right? Is the idea to overlay the RAM range at 0x30000 with a window (alias) into the "compatible" SMRAM at 0xA0000-0xBFFFF? I don't know how the "compatible" SMRAM is implemented in QEMU. Does the compatible SMRAM behave in sync with TSEG? OVMF doesn't configure or touch compatible SMRAM at all, at the moment. Thanks Laszlo