From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.100, mailfrom: michael.d.kinney@intel.com) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by groups.io with SMTP; Wed, 21 Aug 2019 08:48:46 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2019 08:48:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,412,1559545200"; d="scan'208";a="203062445" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga004.fm.intel.com with ESMTP; 21 Aug 2019 08:48:44 -0700 Received: from orsmsx156.amr.corp.intel.com (10.22.240.22) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 21 Aug 2019 08:48:44 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.198]) by ORSMSX156.amr.corp.intel.com ([169.254.8.12]) with mapi id 14.03.0439.000; Wed, 21 Aug 2019 08:48:44 -0700 From: "Michael D Kinney" To: "rfc@edk2.groups.io" , "Yao, Jiewen" , Paolo Bonzini , "Kinney, Michael D" CC: Alex Williamson , Laszlo Ersek , "devel@edk2.groups.io" , "qemu devel list" , Igor Mammedov , "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 Thread-Topic: [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF Thread-Index: AQHVUfF5vU6QBeHgZE+cN7DIWDHHwKb6jzUA//+ZRQCAAaHSAIAAFq8AgAEuZqD//8zIAIAAiChAgABQUYCAACK6gIAAmpdAgAJgcwCAALs9d4AEPCbw Date: Wed, 21 Aug 2019 15:48:43 +0000 Message-ID: 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> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.140] MIME-Version: 1.0 Return-Path: michael.d.kinney@intel.com Content-Language: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Perhaps there is a way to avoid the 3000:8000 startup vector. If a CPU is added after a cold reset, it is already in a different state because one of the active CPUs needs to release it by interacting with the hot plug controller. Can the SMRR for CPUs in that state be pre-programmed to match the SMRR in the rest of the active CPUs? For OVMF we expect all the active CPUs to use the same SMRR value, so a check can be made to verify that all=20 the active CPUs have the same SMRR value. If they do, then any CPU released through the hot plug controller=20 can have its SMRR pre-programmed and the initial SMI will start within TSEG. We just need to decide what to do in the unexpected=20 case where all the active CPUs do not have the same SMRR value. This should also reduce the total number of steps. Mike > -----Original Message----- > From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io] On > Behalf Of Yao, Jiewen > Sent: Sunday, August 18, 2019 4:01 PM > To: Paolo Bonzini > Cc: Alex Williamson ; Laszlo > Ersek ; 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 > > Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using > SMM with QEMU+OVMF >=20 > 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. >=20 > thank you! > Yao, Jiewen >=20 >=20 > > =1B$B:_=1B(B 2019=1B$BG/=1B(B8=1B$B7n=1B(B19=1B$BF|!$>e8a=1B(B3:50=1B$= B!$=1B(BPaolo Bonzini > =1B$B > > >> On 17/08/19 02:20, Yao, Jiewen wrote: > >> [Jiewen] That is OK. Then we MUST add the third > adversary. > >> -- Adversary: Simple hardware attacker, who can use > device to perform DMA attack in the virtual world. > >> NOTE: The DMA attack in the real world is out of > scope. That is be handled by IOMMU in the real world, > such as VTd. -- Please do clarify if this is TRUE. > >> > >> In the real world: > >> #1: the SMM MUST be non-DMA capable region. > >> #2: the MMIO MUST be non-DMA capable region. > >> #3: the stolen memory MIGHT be DMA capable region or > non-DMA capable > >> region. It depends upon the silicon design. > >> #4: the normal OS accessible memory - including ACPI > reclaim, ACPI > >> NVS, and reserved memory not included by #3 - MUST be > DMA capable region. > >> As such, IOMMU protection is NOT required for #1 and > #2. IOMMU > >> protection MIGHT be required for #3 and MUST be > required for #4. > >> I assume the virtual environment is designed in the > same way. Please > >> correct me if I am wrong. > >> > > > > Correct. The 0x30000...0x3ffff area is the only > problematic one; > > Igor's idea (or a variant, for example optionally > remapping > > 0xa0000..0xaffff SMRAM to 0x30000) is becoming more > and more attractive. > > > > Paolo >=20 >=20