From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.93, mailfrom: michael.d.kinney@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by groups.io with SMTP; Wed, 21 Aug 2019 10:25:36 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2019 10:25:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,412,1559545200"; d="scan'208";a="330087089" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga004.jf.intel.com with ESMTP; 21 Aug 2019 10:25:36 -0700 Received: from orsmsx159.amr.corp.intel.com (10.22.240.24) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 21 Aug 2019 10:25:35 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.198]) by ORSMSX159.amr.corp.intel.com ([169.254.11.78]) with mapi id 14.03.0439.000; Wed, 21 Aug 2019 10:25:35 -0700 From: "Michael D Kinney" To: Paolo Bonzini , "rfc@edk2.groups.io" , "Yao, Jiewen" , "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//8zIAIAAiChAgABQUYCAACK6gIAAmpdAgAJgcwCAALs9d4AEPCbwgACNBoD//467cA== Date: Wed, 21 Aug 2019 17:25:34 +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.139] 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 Could we have an initial SMBASE that is within TSEG. If we bring in hot plug CPUs one at a time, then initial SMBASE in TSEG can reprogram the SMBASE to the correct=20 value for that CPU. Can we add a register to the hot plug controller that allows the BSP to set the initial SMBASE value for=20 a hot added CPU? The default can be 3000:8000 for compatibility. Another idea is when the SMI handler runs for a hot add CPU event, the SMM monarch programs the hot plug controller register with the SMBASE to use for the CPU that is being added. As each CPU is added, a different SMBASE value can be programmed by the SMM Monarch. Mike > -----Original Message----- > From: Paolo Bonzini [mailto:pbonzini@redhat.com] > Sent: Wednesday, August 21, 2019 10:06 AM > To: Kinney, Michael D ; > rfc@edk2.groups.io; Yao, Jiewen > 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 >=20 > On 21/08/19 17:48, Kinney, Michael D wrote: > > 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 the active CPUs > have the same > > SMRR value. If they do, then any CPU released through > the hot plug > > controller 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 > case where all the > > active CPUs do not have the same SMRR value. > > > > This should also reduce the total number of steps. >=20 > The problem is not the SMRR but the SMBASE. If the > SMBASE area is outside TSEG, it is vulnerable to DMA > attacks independent of the SMRR. > SMBASE is also different for all CPUs, so it cannot be > preprogrammed. >=20 > (As an aside, virt platforms are also immune to cache > poisoning so they don't have SMRR yet - we could use > them for SMM_CODE_CHK_EN and block execution outside > SMRR but we never got round to it). >=20 > An even simpler alternative would be to make A0000h the > initial SMBASE. > However, I would like to understand what hardware > platforms plan to do, if anything. >=20 > Paolo >=20 > > 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 devel@nongnu.org>; 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 > >> > >> 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. > >> > >> thank you! > >> Yao, Jiewen > >> > >> > >>> =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 > >