linux-kernel - Re: [PATCH v8 RESEND 0/4] Support kdump for AMD secure memory encryption(SME)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dac69aae-27cf-9c93-a0ee-b65e241e1dd6@redhat.com>
Date:   Thu, 4 Oct 2018 17:33:14 +0800
From:   lijiang <lijiang@...hat.com>
To:     Borislav Petkov <bp@...e.de>
Cc:     linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
        tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
        x86@...nel.org, akpm@...ux-foundation.org,
        dan.j.williams@...el.com, thomas.lendacky@....com,
        bhelgaas@...gle.com, baiyaowei@...s.chinamobile.com, tiwai@...e.de,
        brijesh.singh@....com, dyoung@...hat.com, bhe@...hat.com,
        jroedel@...e.de
Subject: Re: [PATCH v8 RESEND 0/4] Support kdump for AMD secure memory
 encryption(SME)

在 2018年10月03日 19:34, Borislav Petkov 写道:
> On Wed, Oct 03, 2018 at 11:57:59AM +0800, lijiang wrote:
>> I noticed that your test was based on [patch v8 RESEND 4/4],
> 
> How did you notice that?
> 
> Let's see, the patch in question is this one:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/commit/?h=rc6%2b0-sme-kdump&id=4a0f2adf6cf374ed3e742134e40591ea33d55b05
> 
> and it has a Link tag:
> 
> Link: https://lkml.kernel.org/r/be7b47f9-6be6-e0d1-2c2a-9125bc74b818@redhat.com
> 
> Now let's open that link tag. I don't know about you but my browser says:
> 
> https://lore.kernel.org/lkml/be7b47f9-6be6-e0d1-2c2a-9125bc74b818@redhat.com/T/#u
> 
> which points to
> 
> Subject: Re: [PATCH v9 4/4] kdump/vmcore: support encrypted old memory with SME enabled
> 
> Looking at that mail, its message id is:
> 
> Message-ID: <be7b47f9-6be6-e0d1-2c2a-9125bc74b818@...hat.com>
> 
> It looks to me it is already v9, no?
> 

According to your description, it seems that the patch is v9. In fact, there is only
different the content of header file between [patch v8 RESEND 4/4] and [patch v9 4/4].

diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index 3e4ba9d753c8..84d8ddcb818e 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -26,6 +26,19 @@ extern int remap_oldmem_pfn_range(struct vm_area_struct *vma,
 
 extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
 						unsigned long, int);
+#if defined(CONFIG_AMD_MEM_ENCRYPT) || defined(CONFIG_X86_64)
+extern ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf,
+					  size_t csize, unsigned long offset,
+					  int userbuf);
+#else
+static inline
+ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
+				   unsigned long offset, int userbuf)
+{
+	return 0;
+}
+#endif
+


I have tested the patch again based on upstream 4.19.0-rc6, it works very well.

I'm not sure whether your machine has also SME feature. If it has no SME feature and
previously kdump could work well, after we apply these patches, kdump should be able
to work properly too. I suggest a comparison test for them. Because it is similar to
the situation that SME is disabled.

If your machine has SME feature and SME is also enabled, these patches should be applied
before we test kdump, otherwise kdump won't work.

This was your command that loaded crash kernel and initrd:
# ~/bpetkov/bin/sbin/kexec -p /boot/vmlinuz-4.19.0-rc6+ --initrd /boot/initrd-4.19.0-rc6+ --command-line="root=/dev/mapper/ubuntu--010236012132--vg-leap15 splash=silent showopts console=ttyS5,115200 console=tty0 debug ignore_loglevel log_buf_len=16M 1 irqpoll maxcpus=1 reset_devices vga=normal"

If this option(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT) was not enabled by default,
that just tested the case which SME was disabled(because it had no "mem_encrypt=on"
in the kernel command-line). As previously mentioned, maybe it is necessary to do
a comparison test for them.

I have no test environment for Ubuntu. Would you like to share the panic log? 

Thanks.
Lianbo