From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fVsMk-000706-Tf for kexec@lists.infradead.org; Thu, 21 Jun 2018 05:42:44 +0000 Subject: Re: [PATCH 3/4 V3] Remap the device table of IOMMU in encrypted manner for kdump References: <20180616082714.32035-1-lijiang@redhat.com> <20180616082714.32035-4-lijiang@redhat.com> <60c6f00e-0eb3-d39c-6a1e-8a1dc1e095af@amd.com> From: lijiang Message-ID: Date: Thu, 21 Jun 2018 13:42:24 +0800 MIME-Version: 1.0 In-Reply-To: <60c6f00e-0eb3-d39c-6a1e-8a1dc1e095af@amd.com> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Tom Lendacky , linux-kernel@vger.kernel.org Cc: dyoung@redhat.com, iommu@lists.linux-foundation.org, kexec@lists.infradead.org 5ZyoIDIwMTjlubQwNuaciDIx5pelIDAwOjQyLCBUb20gTGVuZGFja3kg5YaZ6YGTOgo+IE9uIDYv MTYvMjAxOCAzOjI3IEFNLCBMaWFuYm8gSmlhbmcgd3JvdGU6Cj4+IEluIGtkdW1wIG1vZGUsIGl0 IHdpbGwgY29weSB0aGUgZGV2aWNlIHRhYmxlIG9mIElPTU1VIGZyb20gdGhlIG9sZAo+PiBkZXZp Y2UgdGFibGUsIHdoaWNoIGlzIGVuY3J5cHRlZCB3aGVuIFNNRSBpcyBlbmFibGVkIGluIHRoZSBm aXJzdAo+PiBrZXJuZWwuIFNvIHdlIG11c3QgcmVtYXAgaXQgaW4gZW5jcnlwdGVkIG1hbm5lciBp biBvcmRlciB0byBiZQo+PiBhdXRvbWF0aWNhbGx5IGRlY3J5cHRlZCB3aGVuIHdlIHJlYWQuCj4+ Cj4+IFNpZ25lZC1vZmYtYnk6IExpYW5ibyBKaWFuZyA8bGlqaWFuZ0ByZWRoYXQuY29tPgo+PiAt LS0KPj4gU29tZSBjaGFuZ2VzOgo+PiAxLiBhZGQgc29tZSBjb21tZW50cwo+PiAyLiBjbGVhbiBj b21waWxlIHdhcm5pbmcuCj4+Cj4+ICBkcml2ZXJzL2lvbW11L2FtZF9pb21tdV9pbml0LmMgfCAx NSArKysrKysrKysrKysrKy0KPj4gIDEgZmlsZSBjaGFuZ2VkLCAxNCBpbnNlcnRpb25zKCspLCAx IGRlbGV0aW9uKC0pCj4+Cj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2lvbW11L2FtZF9pb21tdV9p bml0LmMgYi9kcml2ZXJzL2lvbW11L2FtZF9pb21tdV9pbml0LmMKPj4gaW5kZXggOTA0YzU3NS4u YTIwYWY0YyAxMDA2NDQKPj4gLS0tIGEvZHJpdmVycy9pb21tdS9hbWRfaW9tbXVfaW5pdC5jCj4+ ICsrKyBiL2RyaXZlcnMvaW9tbXUvYW1kX2lvbW11X2luaXQuYwo+PiBAQCAtODg5LDExICs4ODks MjQgQEAgc3RhdGljIGJvb2wgY29weV9kZXZpY2VfdGFibGUodm9pZCkKPj4gIAl9Cj4+ICAKPj4g IAlvbGRfZGV2dGJfcGh5cyA9IGVudHJ5ICYgUEFHRV9NQVNLOwo+PiArCj4+ICsJLyoKPj4gKwkg KiAgV2hlbiBzbWUgZW5hYmxlIGluIHRoZSBmaXJzdCBrZXJuZWwsIG9sZF9kZXZ0Yl9waHlzIGlu Y2x1ZGVzIHRoZQo+PiArCSAqICBtZW1vcnkgZW5jcnlwdGlvbiBtYXNrKHNtZV9tZV9tYXNrKSwg d2UgbXVzdCByZW1vdmUgdGhlIG1lbW9yeQo+PiArCSAqICBlbmNyeXB0aW9uIG1hc2sgdG8gb2J0 YWluIHRoZSB0cnVlIHBoeXNpY2FsIGFkZHJlc3MgaW4ga2R1bXAgbW9kZS4KPj4gKwkgKi8KPj4g KwlpZiAobWVtX2VuY3J5cHRfYWN0aXZlKCkgJiYgaXNfa2R1bXBfa2VybmVsKCkpCj4+ICsJCW9s ZF9kZXZ0Yl9waHlzID0gX19zbWVfY2xyKG9sZF9kZXZ0Yl9waHlzKTsKPj4gKwo+IAo+IFlvdSBj YW4gcHJvYmFibHkganVzdCB1c2UgImlmIChpc19rZHVtcF9rZXJuZWwoKSkiIGhlcmUsIHNpbmNl IG1lbW9yeQo+IGVuY3J5cHRpb24gaXMgZWl0aGVyIG9uIGluIGJvdGggdGhlIGZpcnN0IGFuZCBz ZWNvbmQga2VybmVsIG9yIG9mZiBpbgo+IGJvdGggdGhlIGZpcnN0IGFuZCBzZWNvbmQga2VybmVs LiAgQXQgd2hpY2ggcG9pbnQgX19zbWVfY2xyKCkgd2lsbCBkbwo+IHRoZSBwcm9wZXIgdGhpbmcu Cj4gCj4gQWN0dWFsbHksIHRoaXMgbmVlZHMgdG8gYmUgZG9uZSBubyBtYXR0ZXIgd2hhdC4gIFdo ZW4gZG9pbmcgZWl0aGVyIHRoZQo+IGlvcmVtYXBfZW5jcnlwdGVkKCkgb3IgdGhlIG1lbXJlbWFw KCksIHRoZSBwaHlzaWNhbCBhZGRyZXNzIHNob3VsZCBub3QKPiBpbmNsdWRlIHRoZSBlbmNyeXB0 aW9uIGJpdC9tYXNrLgo+IAo+IFRoYW5rcywKPiBUb20KPiAKVGhhbmtzIGZvciB5b3VyIGNvbW1l bnRzLiBJZiB3ZSBkb24ndCByZW1vdmUgdGhlIG1lbW9yeSBlbmNyeXB0aW9uIG1hc2ssIGl0IHdp bGwKcmV0dXJuIGZhbHNlIGJlY2F1c2UgdGhlICdvbGRfZGV2dGJfcGh5cyA+PSAweDEwMDAwMDAw MFVMTCcgbWF5IGJlY29tZSB0cnVlLgoKTGlhbmJvCj4+ICAJaWYgKG9sZF9kZXZ0Yl9waHlzID49 IDB4MTAwMDAwMDAwVUxMKSB7Cj4+ICAJCXByX2VycigiVGhlIGFkZHJlc3Mgb2Ygb2xkIGRldmlj ZSB0YWJsZSBpcyBhYm92ZSA0Rywgbm90IHRydXN0d29ydGh5IVxuIik7Cj4+ICAJCXJldHVybiBm YWxzZTsKPj4gIAl9Cj4+IC0Jb2xkX2RldnRiID0gbWVtcmVtYXAob2xkX2RldnRiX3BoeXMsIGRl dl90YWJsZV9zaXplLCBNRU1SRU1BUF9XQik7Cj4+ICsJb2xkX2RldnRiID0gKG1lbV9lbmNyeXB0 X2FjdGl2ZSgpICYmIGlzX2tkdW1wX2tlcm5lbCgpKQo+PiArCQkgICAgPyAoX19mb3JjZSB2b2lk ICopaW9yZW1hcF9lbmNyeXB0ZWQob2xkX2RldnRiX3BoeXMsCj4+ICsJCQkJCQkJZGV2X3RhYmxl X3NpemUpCj4+ICsJCSAgICA6IG1lbXJlbWFwKG9sZF9kZXZ0Yl9waHlzLCBkZXZfdGFibGVfc2l6 ZSwgTUVNUkVNQVBfV0IpOz4gKwo+PiAgCWlmICghb2xkX2RldnRiKQo+PiAgCQlyZXR1cm4gZmFs c2U7Cj4+ICAKPj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmtleGVjIG1haWxpbmcgbGlzdAprZXhlY0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9s aXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8va2V4ZWMK From mboxrd@z Thu Jan 1 00:00:00 1970 From: lijiang Subject: Re: [PATCH 3/4 V3] Remap the device table of IOMMU in encrypted manner for kdump Date: Thu, 21 Jun 2018 13:42:24 +0800 Message-ID: References: <20180616082714.32035-1-lijiang@redhat.com> <20180616082714.32035-4-lijiang@redhat.com> <60c6f00e-0eb3-d39c-6a1e-8a1dc1e095af@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <60c6f00e-0eb3-d39c-6a1e-8a1dc1e095af@amd.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Tom Lendacky , linux-kernel@vger.kernel.org Cc: iommu@lists.linux-foundation.org, kexec@lists.infradead.org, dyoung@redhat.com List-Id: iommu@lists.linux-foundation.org 在 2018年06月21日 00:42, Tom Lendacky 写道: > On 6/16/2018 3:27 AM, Lianbo Jiang wrote: >> In kdump mode, it will copy the device table of IOMMU from the old >> device table, which is encrypted when SME is enabled in the first >> kernel. So we must remap it in encrypted manner in order to be >> automatically decrypted when we read. >> >> Signed-off-by: Lianbo Jiang >> --- >> Some changes: >> 1. add some comments >> 2. clean compile warning. >> >> drivers/iommu/amd_iommu_init.c | 15 ++++++++++++++- >> 1 file changed, 14 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c >> index 904c575..a20af4c 100644 >> --- a/drivers/iommu/amd_iommu_init.c >> +++ b/drivers/iommu/amd_iommu_init.c >> @@ -889,11 +889,24 @@ static bool copy_device_table(void) >> } >> >> old_devtb_phys = entry & PAGE_MASK; >> + >> + /* >> + * When sme enable in the first kernel, old_devtb_phys includes the >> + * memory encryption mask(sme_me_mask), we must remove the memory >> + * encryption mask to obtain the true physical address in kdump mode. >> + */ >> + if (mem_encrypt_active() && is_kdump_kernel()) >> + old_devtb_phys = __sme_clr(old_devtb_phys); >> + > > You can probably just use "if (is_kdump_kernel())" here, since memory > encryption is either on in both the first and second kernel or off in > both the first and second kernel. At which point __sme_clr() will do > the proper thing. > > Actually, this needs to be done no matter what. When doing either the > ioremap_encrypted() or the memremap(), the physical address should not > include the encryption bit/mask. > > Thanks, > Tom > Thanks for your comments. If we don't remove the memory encryption mask, it will return false because the 'old_devtb_phys >= 0x100000000ULL' may become true. Lianbo >> if (old_devtb_phys >= 0x100000000ULL) { >> pr_err("The address of old device table is above 4G, not trustworthy!\n"); >> return false; >> } >> - old_devtb = memremap(old_devtb_phys, dev_table_size, MEMREMAP_WB); >> + old_devtb = (mem_encrypt_active() && is_kdump_kernel()) >> + ? (__force void *)ioremap_encrypted(old_devtb_phys, >> + dev_table_size) >> + : memremap(old_devtb_phys, dev_table_size, MEMREMAP_WB);> + >> if (!old_devtb) >> return false; >> >>