From: Borislav Petkov <bp@suse.de>
To: lijiang <lijiang@redhat.com>
Cc: thomas.lendacky@amd.com, jroedel@suse.de, brijesh.singh@amd.com,
bhe@redhat.com, tiwai@suse.de, x86@kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
mingo@redhat.com, baiyaowei@cmss.chinamobile.com, hpa@zytor.com,
bhelgaas@google.com, tglx@linutronix.de, dyoung@redhat.com,
akpm@linux-foundation.org, dan.j.williams@intel.com
Subject: Re: [PATCH v9 4/4] kdump/vmcore: support encrypted old memory with SME enabled
Date: Mon, 1 Oct 2018 22:22:44 +0200 [thread overview]
Message-ID: <20181001202244.GB8350@zn.tnic> (raw)
In-Reply-To: <be7b47f9-6be6-e0d1-2c2a-9125bc74b818@redhat.com>
On Sun, Sep 30, 2018 at 04:37:41PM +0800, lijiang wrote:
> In kdump kernel, the old memory needs to be dumped into vmcore file.
> If SME is enabled in the first kernel, the old memory has to be
> remapped with the memory encryption mask, which will be automatically
> decrypted when read from DRAM.
>
> For SME kdump, there are two cases that doesn't support:
Get rid of those two cases in the commit message.
>
> ----------------------------------------------
> | first-kernel | second-kernel | kdump support |
> | (mem_encrypt=on|off) | (yes|no) |
> |--------------+---------------+---------------|
> | on | on | yes |
> | off | off | yes |
> | on | off | no |
> | off | on | no |
> |______________|_______________|_______________|
>
> 1. SME is enabled in the first kernel, but SME is disabled in kdump kernel
> In this case, because the old memory is encrypted, it can't be decrypted.
> The root cause is that the encryption key is not visible to any software
> runnint on the CPU cores(AMD cpu with SME), and is randomly generated on
> eache system reset. That is to say, kdump kernel won't have a chance to
> get the encryption key. So the encrypted memory can not be decrypted
> unless SME is active.
>
> 2. SME is disabled in the first kernel, but SME is enabled in kdump kernel
> On the one hand, the old memory is decrypted, the old memory can be dumped
> as usual, so SME doesn't need to be enabled in kdump kernel; On the other
> hand, it will increase the complexity of the code, because that will have
> to consider how to pass the SME flag from the first kernel to the kdump
> kernel, it is really too expensive to do this.
>
> This patches are only for SME kdump, the patches don't support SEV kdump.
>
> Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
You cannot keep Reviewed-by: tags on patches which you change in a
non-trivial manner.
> ---
> Changes since v7:
> 1. Delete a file arch/x86/kernel/crash_dump_encrypt.c, and move the
> copy_oldmem_page_encrypted() to arch/x86/kernel/crash_dump_64.c, also
> rewrite some functions.(Suggested by Borislav)
> 2. Modify all code style issue.(Suggested by Borislav)
> 3. Remove a reduntant header file.(Suggested by Borislav)
> 4. Improve patch log.(Suggested by Borislav)
> 5. Modify compile error "fs/proc/vmcore.c:115: undefined reference
> to `copy_oldmem_page_encrypted'"
> 6. Modify compile error "arch/x86//kernel/crash_dump_64.c:93:9:
> error: redefinition of 'copy_oldmem_page_encrypted'"
>
> arch/x86/kernel/crash_dump_64.c | 65 ++++++++++++++++++++++++++++-----
> fs/proc/vmcore.c | 24 +++++++++---
> include/linux/crash_dump.h | 13 +++++++
> 3 files changed, 87 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c
> index 4f2e0778feac..6adbde592c44 100644
> --- a/arch/x86/kernel/crash_dump_64.c
> +++ b/arch/x86/kernel/crash_dump_64.c
> @@ -12,7 +12,7 @@
> #include <linux/io.h>
>
> /**
> - * copy_oldmem_page - copy one page from "oldmem"
> + * __copy_oldmem_page - copy one page from "old memory encrypted or decrypted"
Dammit, what's it with those "old memory encrypted or decrypted" in quotation
marks?! What is wrong with simply saying:
Copy one page of the old kernel's memory. If @encrypted is set, the old
memory will be remapped with the encryption mask.
How hard is that?!
> * @pfn: page frame number to be copied
> * @buf: target memory address for the copy; this can be in kernel address
> * space or user address space (see @userbuf)
> @@ -20,31 +20,78 @@
> * @offset: offset in bytes into the page (based on pfn) to begin the copy
> * @userbuf: if set, @buf is in user address space, use copy_to_user(),
> * otherwise @buf is in kernel address space, use memcpy().
> + * @encrypted: if true, the old memory is encrypted.
> + * if false, the old memory is decrypted.
> *
> - * Copy a page from "oldmem". For this page, there is no pte mapped
> - * in the current kernel. We stitch up a pte, similar to kmap_atomic.
> + * Copy a page from "old memory encrypted or decrypted". For this page, there
> + * is no pte mapped in the current kernel. We stitch up a pte, similar to
> + * kmap_atomic.
> */
This function is static now - why does it need to keep the comments
above it? And you've duplicated almost the same comment *three* times
now. Why?
Have the whole comment *once* and only one line sentences over the other
functions explaining the difference only.
> -ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
> - size_t csize, unsigned long offset, int userbuf)
> +static ssize_t __copy_oldmem_page(unsigned long pfn, char *buf, size_t csize,
> + unsigned long offset, int userbuf,
> + bool encrypted)
> {
> void *vaddr;
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2018-10-01 20:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-30 3:10 [PATCH v8 RESEND 0/4] Support kdump for AMD secure memory encryption(SME) Lianbo Jiang
2018-09-30 3:10 ` [PATCH v8 RESEND 1/4] x86/ioremap: add a function ioremap_encrypted() to remap kdump old memory Lianbo Jiang
2018-09-30 3:10 ` [PATCH v8 RESEND 2/4] kexec: allocate decrypted control pages for kdump in case SME is enabled Lianbo Jiang
2018-09-30 3:10 ` [PATCH v8 RESEND 3/4] iommu/amd: Remap the device table of IOMMU with the memory encryption mask for kdump Lianbo Jiang
2018-09-30 3:10 ` [PATCH v8 RESEND 4/4] kdump/vmcore: support encrypted old memory with SME enabled Lianbo Jiang
2018-09-30 4:22 ` kbuild test robot
2018-09-30 8:37 ` [PATCH v9 " lijiang
2018-10-01 20:22 ` Borislav Petkov [this message]
2018-10-02 11:40 ` [PATCH v8 RESEND 0/4] Support kdump for AMD secure memory encryption(SME) Borislav Petkov
2018-10-03 3:57 ` lijiang
2018-10-03 11:34 ` Borislav Petkov
2018-10-04 9:33 ` lijiang
2018-10-04 19:02 ` Borislav Petkov
2018-10-05 5:52 ` lijiang
2018-10-06 9:56 ` Borislav Petkov
2018-10-07 6:09 ` lijiang
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=20181001202244.GB8350@zn.tnic \
--to=bp@suse.de \
--cc=akpm@linux-foundation.org \
--cc=baiyaowei@cmss.chinamobile.com \
--cc=bhe@redhat.com \
--cc=bhelgaas@google.com \
--cc=brijesh.singh@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=jroedel@suse.de \
--cc=kexec@lists.infradead.org \
--cc=lijiang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tiwai@suse.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox