Received: by 2002:ac0:a874:0:0:0:0:0 with SMTP id c49csp323906ima; Fri, 15 Mar 2019 03:44:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqycPoYiEN9/2ajwVijLF9GfeeD07ddK06MPHoTxv9W0wT2s7pm/5XTr7WuEeLGpzYZ8ybiW X-Received: by 2002:a63:5b43:: with SMTP id l3mr2730528pgm.298.1552646667304; Fri, 15 Mar 2019 03:44:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552646667; cv=none; d=google.com; s=arc-20160816; b=X2LclcKVW8IbwiT3IdHU7/5AVRxQHSFiegBzYQmWt1am/8HhkHmHoYfkSfYcajKJd/ F6PbcuSW3mWncTkfnUUfJHyF/BooiVzwoHDwf6O0hElq7UTwn7i5M+Knhvw8UbTKIYVp 73cbrJIrD4LVbtBoW4a5YL2xMHSQsPyI/c5iRKCBqodQqoqXEtC1gh5WEWrm+ewcPhn/ VxmLdyh9O9Ibnu9cVNq8dbU4dyq0M2MBRIrQ4SF0IikW3ZMmxJolOzoDuyfU75a/5+5B E2h6aM1LfOXoHMhHBsl3aQ64OiwqGMitlLMgSnvlx2UigWieR+SjhapFZE0h1di1OxSf nxnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=Q3ipBf5nrg66tjD3ec9dBWtbWBxN+MmmIrqWgZP2B8k=; b=ZMvuA9P8blwkLxkqPGkANAFOaa8mInQGJpatbvI7yNUybqMeLJaB17Bl0B+DTNwQjC YrbRO6/CnSppjF75wiB3aHG6Em9g/FMO/gPzK7ejEKZ45qL5F7bGdhM4KpoEnD5A6OZ+ 8ioxKfzUFQRSexU1FOZGamgCKupuNMEwDhvxKWk24mCjXA/mkm5BvFXu/7Tn03tV8N7X iCKpr6gORZpzAShADJ8/ccJUiE8w4W7OjoTUOpje59nxILwOozZujNGYPktHiuNyLGCd gVMXclx33pFBoADLSXr4wInBqVBTk9USiUwb/NrJBO2QnGpjZu6CjsHtCG3CBi9ls9lH se1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k7si889835pgq.476.2019.03.15.03.44.09; Fri, 15 Mar 2019 03:44:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728898AbfCOKc5 (ORCPT + 99 others); Fri, 15 Mar 2019 06:32:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37722 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728886AbfCOKc5 (ORCPT ); Fri, 15 Mar 2019 06:32:57 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 61245308218D; Fri, 15 Mar 2019 10:32:57 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-12-223.pek2.redhat.com [10.72.12.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0712A5C21F; Fri, 15 Mar 2019 10:32:46 +0000 (UTC) From: Lianbo Jiang To: linux-kernel@vger.kernel.org Cc: kexec@lists.infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, akpm@linux-foundation.org, dyoung@redhat.com, brijesh.singh@amd.com, thomas.lendacky@amd.com, bhe@redhat.com Subject: [PATCH 3/3] kdump,proc/vmcore: Enable kdumping encrypted memory when SEV was active Date: Fri, 15 Mar 2019 18:32:03 +0800 Message-Id: <20190315103203.13128-4-lijiang@redhat.com> In-Reply-To: <20190315103203.13128-1-lijiang@redhat.com> References: <20190315103203.13128-1-lijiang@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Fri, 15 Mar 2019 10:32:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In the kdump kernel, the memory of first kernel needs to be dumped into the vmcore file. It is similar to the SME, if SEV is enabled in the first kernel, the old memory has to be remapped with memory encryption mask in order to access it properly. Following commit 992b649a3f01 ("kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled") took care of the SME case but it uses sme_active() which checks for SME only. Lets use the mem_encrypt_active() which returns true when either of them are active. Unlike the SME, the first kernel is loaded into the encrypted memory when SEV was enabled, hence the kernel elf header must be remapped as encrypted in order to access it properly. Co-developed-by: Brijesh Singh Signed-off-by: Brijesh Singh Signed-off-by: Lianbo Jiang --- fs/proc/vmcore.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c index 3fe90443c1bb..cda6c1922e4f 100644 --- a/fs/proc/vmcore.c +++ b/fs/proc/vmcore.c @@ -165,7 +165,7 @@ void __weak elfcorehdr_free(unsigned long long addr) */ ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos) { - return read_from_oldmem(buf, count, ppos, 0, false); + return read_from_oldmem(buf, count, ppos, 0, sev_active()); } /* @@ -173,7 +173,7 @@ ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos) */ ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64 *ppos) { - return read_from_oldmem(buf, count, ppos, 0, sme_active()); + return read_from_oldmem(buf, count, ppos, 0, mem_encrypt_active()); } /* @@ -373,7 +373,7 @@ static ssize_t __read_vmcore(char *buffer, size_t buflen, loff_t *fpos, buflen); start = m->paddr + *fpos - m->offset; tmp = read_from_oldmem(buffer, tsz, &start, - userbuf, sme_active()); + userbuf, mem_encrypt_active()); if (tmp < 0) return tmp; buflen -= tsz; -- 2.17.1