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

[lijiang]

在 2018年10月06日 17:56, Borislav Petkov 写道:
> On Fri, Oct 05, 2018 at 01:52:26PM +0800, lijiang wrote:
>>  b. add the parameter "mem_encrypt=on" for kernel command-line to 
>> grub.cfg, if
>> this machine has SME feature. And also add crashkernel=xx, which 
>> will reserve
>> memory for kdump.
> 
> Ok, I'm doing the simpler crashkernel= cmdline:
> 
> crashkernel=256M
> 
> That says:
> 
> [0.011918] Reserving 256MB of memory at 640MB for crashkernel (System 
> RAM: 262030MB)
> 
>> Step 5: reboot, and then load the crash kernel image and kdump initramfs.
>>
>>  a: When SME is enabled, i use this command to load them:
>>
>> #kexec -p /boot/vmlinuz-4.19.0-rc6+ 
>> --initrd=/boot/initramfs-4.19.0-rc6+kdump.img 
>> --command-line="root=/dev/mapper/rhel_hp--dl385g10--03-root ro 
>> rd.lvm.lv=rhel_hp-dl385g10-03/root rd.lvm.lv=rhel_hp-dl385g10-03/swap 
>> mem_encrypt=on console=ttyS0,115200n81 LANG=en_US.UTF-8 earlyprintk=serial 
>> debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off 
>> udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug 
>> transparent_hugepage=never disable_cpu_apicid=0"
> 
> Ok, did that, my cmdline is:
> 
> ~/bpetkov/src/kexec-tools/build/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 
> rd.lvm.lv=ubuntu--010236012132--vg-leap15/root 
> rd.lvm.lv=ubuntu--010236012132--vg-leap15/swap splash=silent showopts 
> console=ttyS5,115200 console=tty0 debug ignore_loglevel log_buf_len=16M 
> nr_cpus=1 irqpoll maxcpus=1 reset_devices vga=normal mem_encrypt=on 
> LANG=en_US.UTF-8 earlyprintk=serial cgroup_disable=memory mce=off numa=off 
> udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug 
> transparent_hugepage=never disable_cpu_apicid=0"
> 
> Verified it loaded ok:
> 
> $ grep . /sys/kernel/kexec_*
> /sys/kernel/kexec_crash_loaded:1
> /sys/kernel/kexec_crash_size:268435456
> /sys/kernel/kexec_loaded:0
> 
>> Step 6: trigger panic by sysrq
>> #echo c > /proc/sysrq-trigger
> 
> Did that and I got into the kdump kernel with SME. So I'd guess your kdump
> kernel command line was needed - I was missing a bunch of switches and
> remote-debugging a box kexecing is not fun.
> 
> So thanks a lot for the detailed steps, I'm putting them to my notes.
> 

It's my pleasure.
Also thanks for your patience and help.

Regards,
Lianbo

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Borislav Petkov]

On Fri, Oct 05, 2018 at 01:52:26PM +0800, lijiang wrote:
>  b. add the parameter "mem_encrypt=on" for kernel command-line to 
> grub.cfg, if
> this machine has SME feature. And also add crashkernel=xx, which will 
> reserve
> memory for kdump.

Ok, I'm doing the simpler crashkernel= cmdline:

crashkernel=256M

That says:

[0.011918] Reserving 256MB of memory at 640MB for crashkernel (System RAM: 
262030MB)

> Step 5: reboot, and then load the crash kernel image and kdump initramfs.
> 
>  a: When SME is enabled, i use this command to load them:
> 
> #kexec -p /boot/vmlinuz-4.19.0-rc6+ 
> --initrd=/boot/initramfs-4.19.0-rc6+kdump.img 
> --command-line="root=/dev/mapper/rhel_hp--dl385g10--03-root ro 
> rd.lvm.lv=rhel_hp-dl385g10-03/root rd.lvm.lv=rhel_hp-dl385g10-03/swap 
> mem_encrypt=on console=ttyS0,115200n81 LANG=en_US.UTF-8 earlyprintk=serial 
> debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off 
> udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug 
> transparent_hugepage=never disable_cpu_apicid=0"

Ok, did that, my cmdline is:

~/bpetkov/src/kexec-tools/build/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 
rd.lvm.lv=ubuntu--010236012132--vg-leap15/root 
rd.lvm.lv=ubuntu--010236012132--vg-leap15/swap splash=silent showopts 
console=ttyS5,115200 console=tty0 debug ignore_loglevel log_buf_len=16M 
nr_cpus=1 irqpoll maxcpus=1 reset_devices vga=normal mem_encrypt=on 
LANG=en_US.UTF-8 earlyprintk=serial cgroup_disable=memory mce=off numa=off 
udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug 
transparent_hugepage=never disable_cpu_apicid=0"

Verified it loaded ok:

$ grep . /sys/kernel/kexec_*
/sys/kernel/kexec_crash_loaded:1
/sys/kernel/kexec_crash_size:268435456
/sys/kernel/kexec_loaded:0

> Step 6: trigger panic by sysrq
> #echo c > /proc/sysrq-trigger

Did that and I got into the kdump kernel with SME. So I'd guess your kdump
kernel command line was needed - I was missing a bunch of switches and
remote-debugging a box kexecing is not fun.

So thanks a lot for the detailed steps, I'm putting them to my notes.

-- 
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

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

[lijiang]

在 2018年10月05日 03:02, Borislav Petkov 写道:
> On Thu, Oct 04, 2018 at 05:33:14PM +0800, lijiang wrote:
>> I have tested the patch again based on upstream 4.19.0-rc6, it works very 
>> well.
> 
> How have you tested this?
> 
> Please describe the steps in detail.
> 

There are eight steps:

Step 1: prepare for test tools, you might refer to the cover-letter.
 a. makedumpfile
 b. crash-7.2.3
 c. kexec-tools-2.0.17

 Compile and install these test tools.

Step 2: make sure that the kernel option is enabled if this machine has SME 
feature.
CONFIG_AMD_MEM_ENCRYPT=y 

Step 3: apply these patches based on upstream v4.19-rc6, compile and install 
kernel
#git am .patch
#make ARCH=x86_64 -j32
#make ARCH=x86_64 modules_install -j32
#make ARCH=x86_64 install

Step 4: configure kdump and modify some parameters for SME
 a. configure kdump.conf
#cat /etc/kdump.conf
path /var/crash
core_collector makedumpfile -l --message-level 1 -d 31

 b. add the parameter "mem_encrypt=on" for kernel command-line to grub.cfg, 
if
this machine has SME feature. And also add crashkernel=xx, which will 
reserve
memory for kdump.

Step 5: reboot, and then load the crash kernel image and kdump initramfs.

 a: When SME is enabled, i use this command to load them:

#kexec -p /boot/vmlinuz-4.19.0-rc6+ 
--initrd=/boot/initramfs-4.19.0-rc6+kdump.img 
--command-line="root=/dev/mapper/rhel_hp--dl385g10--03-root ro 
rd.lvm.lv=rhel_hp-dl385g10-03/root rd.lvm.lv=rhel_hp-dl385g10-03/swap 
mem_encrypt=on console=ttyS0,115200n81 LANG=en_US.UTF-8 earlyprintk=serial 
debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off 
udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug 
transparent_hugepage=never disable_cpu_apicid=0"

 b: When SME is disabled, i use this command to load them:

#kexec -p /boot/vmlinuz-4.19.0-rc6+ 
--initrd=/boot/initramfs-4.19.0-rc6+kdump.img 
--command-line="root=/dev/mapper/rhel_hp--dl385g10--03-root ro 
rd.lvm.lv=rhel_hp-dl385g10-03/root rd.lvm.lv=rhel_hp-dl385g10-03/swap 
mem_encrypt=off console=ttyS0,115200n81 LANG=en_US.UTF-8 earlyprintk=serial 
debug irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off 
udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug 
transparent_hugepage=never disable_cpu_apicid=0"

Step 6: trigger panic by sysrq
#echo c > /proc/sysrq-trigger

Step 7: check whether the vmcore has been created.

[root@hp-dl385g10-03 linux]# ls -al /var/crash/*
/var/crash/127.0.0.1-2018-10-05-01:20:20:
drwxr-xr-x. 2 root root 44 10月  5 01:20 .
drwxr-xr-x. 3 root root107 10月  5 01:20 ..
-rw---. 1 root root 1179265928 10月  5 01:20 vmcore
-rw-r--r--. 1 root root 126571 10月  5 01:20 vmcore-dmesg.txt

/var/crash/127.0.0.1-2018-10-05-01:35:21:
drwxr-xr-x. 2 root root 44 10月  5 01:35 .
drwxr-xr-x. 4 root root144 10月  5 01:35 ..
-rw---. 1 root root 1084270120 10月  5 01:35 vmcore
-rw-r--r--. 1 root root 125578 10月  5 01:35 vmcore-dmesg.txt

Step 8: check whether the crash tool can parse the vmcore
 a. When SME is enabled.
#crash vmlinux /var/crash/127.0.0.1-2018-10-05-01\:20\:20/vmcore

crash 7.2.3++
Copyright (C) 2002-2017  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
 
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

WARNING: kernel relocated [308MB]: patching 85986 gdb minimal_symbol values

  KERNEL: vmlinux  
DUMPFILE: /var/crash/127.0.0.1-2018-10-05-01:20:20/vmcore  [PARTIAL DUMP]
CPUS: 32
DATE: Fri Oct  5 01:19:40 2018
  UPTIME: 00:04:04
LOAD AVERAGE: 0.18, 0.33, 0.16
   TASKS: 462
NODENAME: hp-dl385g10-03.lab.eng.pek2.redhat.com
 RELEASE: 4.19.0-rc6+
 VERSION: #223 SMP Fri Oct 5 01:05:56 EDT 2018
 MACHINE: x86_64  (2095 Mhz)
  MEMORY: 31.8 GB
   PANIC: "sysrq: SysRq : Trigger a crash"
 PID: 9451
 COMMAND: "bash"
  

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

[Borislav Petkov]

On Thu, Oct 04, 2018 at 05:33:14PM +0800, lijiang wrote:
> I have tested the patch again based on upstream 4.19.0-rc6, it works very 
> well.

How have you tested this?

Please describe the steps in detail.

Thx.

-- 
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

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

[lijiang]

在 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-9125bc74b...@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-9125bc74b...@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: 
> 
> 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

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[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-9125bc74b...@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-9125bc74b...@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: 

It looks to me it is already v9, no?

-- 
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

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

[lijiang]

在 2018年10月02日 19:40, Borislav Petkov 写道:
> On Sun, Sep 30, 2018 at 11:10:29AM +0800, Lianbo Jiang wrote:
>> When SME is enabled on AMD machine, it also needs to support kdump. Because
> 
> Ok, I've cleaned them up heavily and pushed them here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git, branch 
> rc6+0-sme-kdump
> 
> However, testing on my zen box doesn't go as planned. And this is even before
> your patches.
> 
> I load the kdump kernel with kexec-tools from the git-repo + the patch you
> mention:
> 
> # ~/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"
> 
> verify that it has been loaded:
> 
> # grep . /sys/kernel/kexec_*
> /sys/kernel/kexec_crash_loaded:1
> /sys/kernel/kexec_crash_size:268435456
> /sys/kernel/kexec_loaded:0
> 
> and then trigger the panic:
> 
> # echo c > /proc/sysrq-trigger
> 
> and I see the panic happening in the serial console but then nothing.
> The box resets instead.
> 
> So something's still broken.
> 

Sorry for my late reply because of a holiday.

I noticed that your test was based on [patch v8 RESEND 4/4], could you please
test it based on [patch v9 4/4]? Because the [patch v8 RESEND 4/4] had a compile
error, and that had been fixed in [patch v9 4/4].

Or i improve patch log and comment in the code for [patch v9 4/4] based on your
comments, and post the series again, also provide my test result about the 
series. 
Do you think about?

Thanks.
Lianbo

> Trying the kexec -l/kexec -e game works - the second kernel gets kexeced
> properly.
> 

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Borislav Petkov]

On Sun, Sep 30, 2018 at 11:10:29AM +0800, Lianbo Jiang wrote:
> When SME is enabled on AMD machine, it also needs to support kdump. Because

Ok, I've cleaned them up heavily and pushed them here:

https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git, branch 
rc6+0-sme-kdump

However, testing on my zen box doesn't go as planned. And this is even before
your patches.

I load the kdump kernel with kexec-tools from the git-repo + the patch you
mention:

# ~/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"

verify that it has been loaded:

# grep . /sys/kernel/kexec_*
/sys/kernel/kexec_crash_loaded:1
/sys/kernel/kexec_crash_size:268435456
/sys/kernel/kexec_loaded:0

and then trigger the panic:

# echo c > /proc/sysrq-trigger

and I see the panic happening in the serial console but then nothing.
The box resets instead.

So something's still broken.

Trying the kexec -l/kexec -e game works - the second kernel gets kexeced
properly.

-- 
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

[PATCH v8 RESEND 0/4] Support kdump for AMD secure memory encryption(SME)

[Lianbo Jiang]

When SME is enabled on AMD machine, it also needs to support kdump. Because
the memory is encrypted in the first kernel, the old memory will be remapped
to kdump kernel for dumping data, and SME is also enabled in kdump kernel,
otherwise the old memory can not be decrypted.

For the kdump, it is necessary to distinguish whether the memory is encrypted.
Furthermore, that should also know which part of the memory is encrypted or
decrypted. It will appropriately remap the memory according to the specific
situation in order to tell cpu how to access the memory.

As we know, a page of memory that is marked as encrypted, which will be
automatically decrypted when read from DRAM, and will also be automatically
encrypted when written to DRAM. If the old memory is encrypted, it has to
remap the old memory with the memory encryption mask, which will automatically
decrypt the old memory when read from DRAM.

For kdump(SME), there are two cases that doesn't support:

 --
| 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
It is unnecessary to support in this case, because the old memory is
dencrypted, the old memory can be dumped as usual, that doesn't need to
enable SME in kdump kernel. Another, If the scenario must be supported, it
will increase the complexity of the code, that will have to consider how to
pass the SME flag from the first kernel to the kdump kernel, in order to let
kdump kernel know that whether the old memory is encrypted.

There are two methods to pass the SME flag to the kdump kernel. The first
method is to modify the assembly code, which includes some common code and
the path is too long. The second method is to use kexec tool, which could
require the SME flag to be exported in the first kernel by "proc" or "sysfs",
kexec tools will read the SME flag from "proc" or "sysfs" when we use kexec
tools to load image, subsequently the SME flag will be saved in boot_params,
that can properly remap the old memory according to the previously saved SME
flag. But it is too expensive to do this.

This patches are only for SME kdump, the patches don't support SEV kdump.

Test tools:
makedumpfile[v1.6.3]: https://github.com/LianboJ/makedumpfile
commit  "A draft for kdump vmcore about AMD SME"
Note: This patch can only dump vmcore in the case of SME enabled.

crash-7.2.3: https://github.com/crash-utility/crash.git
commit <001f77a05585> "Fix for Linux 4.19-rc1 and later kernels that contain 
kernel commit <7290d5809571>"

kexec-tools-2.0.17: 
git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
commit  "kexec: fix for "Unhandled rela relocation: 
R_X86_64_PLT32" error"

Note:
Before you load the kernel and initramfs for kdump, this patch(
http://lists.infradead.org/pipermail/kexec/2018-September/021460.html) must be 
merged
to kexec-tools, and then the kdump kernel will work well. Because there is a 
patch
which is removed based on v6(x86/ioremap: strengthen the logic in
early_memremap_pgprot_adjust() to adjust encryption mask).

Test environment:
HP ProLiant DL385Gen10 AMD EPYC 7251
8-Core Processor
32768 MB memory
600 GB disk space

Linux 4.19-rc5:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
commit <6bf4ca7fbc85> "Linux 4.19-rc5"

Reference:
AMD64 Architecture Programmer's Manual
https://support.amd.com/TechDocs/24593.pdf

Changes since v6:
1. There is a patch which is removed based on v6.
(x86/ioremap: strengthen the logic in early_memremap_pgprot_adjust() to adjust 
encryption mask)
Dave Young suggests that this patch can be removed and fix the kexec-tools.
Reference: 
http://lists.infradead.org/pipermail/kexec/2018-September/021460.html)
2. Update the patch log.

Changes since v7:
1. Improve patch log for patch 1/4(Suggested by Baoquan He)
2. Add Reviewed-by for all patches(Tom Lendacky )
3. Add Acked-by for patch 3/4(Joerg Roedel )
4. Remove header file(linux/crash_dump.h) from
arch/x86/mm/ioremap.c(Suggested by Borislav)
5. Modify comment and patch log for patch 2/4(Suggested by Borislav)
6. Delete a file arch/x86/kernel/crash_dump_encrypt.c and rewrite some
functions(Sugg