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.120, mailfrom: jiewen.yao@intel.com) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by groups.io with SMTP; Sun, 18 Aug 2019 16:00:48 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2019 16:00:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,402,1559545200"; d="scan'208";a="377255834" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga005.fm.intel.com with ESMTP; 18 Aug 2019 16:00:47 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 18 Aug 2019 16:00:47 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 18 Aug 2019 16:00:47 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.19]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.250]) with mapi id 14.03.0439.000; Mon, 19 Aug 2019 07:00:44 +0800 From: "Yao, Jiewen" 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-devel] CPU hotplug using SMM with QEMU+OVMF Thread-Topic: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF Thread-Index: AQHVUfF5lMVYZhTq/0GuokGqDPas2Kb6jzUA//+ZRQCAAaHSAIAAFq8AgAEuZqD//8zIAIAAiChAgABQUYCAACK6gIAAmpdAgAJgcwCAALs9dw== Date: Sun, 18 Aug 2019 23:00: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: <35396800-32d2-c25f-b0d0-2d7cd8438687@redhat.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Return-Path: jiewen.yao@intel.com Content-Language: zh-CN Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable 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 w= ay to prevent ABseg cache poison.=20 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=20 >> 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 DM= A attack in the virtual world. >> NOTE: The DMA attack in the real world is out of scope. That is be handl= ed by IOMMU in the real world, such as VTd. -- Please do clarify if this is= TRUE. >>=20 >> 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. >>=20 >=20 > 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. >=20 > Paolo