From: Lianbo Jiang <lijiang@redhat.com> To: linux-kernel@vger.kernel.org Cc: kexec@lists.infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, akpm@linux-foundation.org, x86@kernel.org, hpa@zytor.com, dyoung@redhat.com, bhe@redhat.com, Thomas.Lendacky@amd.com, brijesh.singh@amd.com Subject: [PATCH 3/3 v2] kdump,proc/vmcore: Enable kdumping encrypted memory when SEV was active Date: Wed, 27 Mar 2019 13:36:29 +0800 [thread overview] Message-ID: <20190327053629.17935-4-lijiang@redhat.com> (raw) In-Reply-To: <20190327053629.17935-1-lijiang@redhat.com> 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 <brijesh.singh@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Lianbo Jiang <lijiang@redhat.com> --- 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
WARNING: multiple messages have this Message-ID (diff)
From: Lianbo Jiang <lijiang@redhat.com> To: linux-kernel@vger.kernel.org Cc: Thomas.Lendacky@amd.com, brijesh.singh@amd.com, bhe@redhat.com, x86@kernel.org, kexec@lists.infradead.org, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, tglx@linutronix.de, dyoung@redhat.com, akpm@linux-foundation.org Subject: [PATCH 3/3 v2] kdump, proc/vmcore: Enable kdumping encrypted memory when SEV was active Date: Wed, 27 Mar 2019 13:36:29 +0800 [thread overview] Message-ID: <20190327053629.17935-4-lijiang@redhat.com> (raw) In-Reply-To: <20190327053629.17935-1-lijiang@redhat.com> 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 <brijesh.singh@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Lianbo Jiang <lijiang@redhat.com> --- 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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2019-03-27 5:37 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-27 5:36 [PATCH 0/3 v2] Add kdump support for the SEV enabled guest Lianbo Jiang 2019-03-27 5:36 ` Lianbo Jiang 2019-03-27 5:36 ` [PATCH 1/3 v2] x86/kexec: Do not map the kexec area as decrypted when SEV is active Lianbo Jiang 2019-03-27 5:36 ` Lianbo Jiang 2019-04-02 10:32 ` Borislav Petkov 2019-04-02 10:32 ` Borislav Petkov 2019-04-26 1:59 ` lijiang 2019-04-26 1:59 ` lijiang 2019-04-26 13:02 ` Borislav Petkov 2019-04-26 13:02 ` Borislav Petkov 2019-04-28 1:29 ` lijiang 2019-04-28 1:29 ` lijiang 2019-03-27 5:36 ` [PATCH 2/3 v2] x86/kexec: Set the C-bit in the identity map page table " Lianbo Jiang 2019-03-27 5:36 ` Lianbo Jiang 2019-03-27 5:36 ` Lianbo Jiang [this message] 2019-03-27 5:36 ` [PATCH 3/3 v2] kdump, proc/vmcore: Enable kdumping encrypted memory when SEV was active Lianbo Jiang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190327053629.17935-4-lijiang@redhat.com \ --to=lijiang@redhat.com \ --cc=Thomas.Lendacky@amd.com \ --cc=akpm@linux-foundation.org \ --cc=bhe@redhat.com \ --cc=bp@alien8.de \ --cc=brijesh.singh@amd.com \ --cc=dyoung@redhat.com \ --cc=hpa@zytor.com \ --cc=kexec@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.