Message-ID: <2cabcbab-264a-2ac5-524e-6e3a9e388e56@redhat.com>
Date:   Wed, 23 May 2018 10:02:00 +0800
From:   lijiang <lijiang@...hat.com>
To:     Tom Lendacky <thomas.lendacky@....com>,
        linux-kernel@...r.kernel.org
Cc:     kexec@...ts.infradead.org, dyoung@...hat.com, bhe@...hat.com
Subject: Re: [PATCH 0/2] support kdump for AMD secure memory encryption(sme)

在 2018年05月21日 21:23, Tom Lendacky 写道:
> On 5/20/2018 10:45 PM, lijiang wrote:
>> 在 2018年05月17日 21:45, lijiang 写道:
>>> 在 2018年05月15日 21:31, Tom Lendacky 写道:
>>>> On 5/14/2018 8:51 PM, Lianbo Jiang wrote:
>>>>> It is convenient to remap the old memory encrypted to the second kernel by
>>>>> calling ioremap_encrypted().
>>>>>
>>>>> When sme enabled on AMD server, we also need to support kdump. Because
>>>>> the memory is encrypted in the first kernel, we will remap the old memory
>>>>> encrypted to the second kernel(crash kernel), and sme is also enabled in
>>>>> the second kernel, otherwise the old memory encrypted can not be decrypted.
>>>>> Because simply changing the value of a C-bit on a page will not
>>>>> automatically encrypt the existing contents of a page, and any data in the
>>>>> page prior to the C-bit modification will become unintelligible. A page of
>>>>> memory that is marked encrypted will be automatically decrypted when read
>>>>> from DRAM and will be automatically encrypted when written to DRAM.
>>>>>
>>>>> For the kdump, it is necessary to distinguish whether the memory is
>>>>> encrypted. Furthermore, we should also know which part of the memory is
>>>>> encrypted or decrypted. We will appropriately remap the memory according
>>>>> to the specific situation in order to tell cpu how to deal with the
>>>>> data(encrypted or decrypted). For example, when sme enabled, if the old
>>>>> memory is encrypted, we will remap the old memory in encrypted way, which
>>>>> will automatically decrypt the old memory encrypted when we read those data
>>>>> from the remapping address.
>>>>>
>>>>>  ----------------------------------------------
>>>>> | first-kernel | second-kernel | kdump support |
>>>>> |      (mem_encrypt=on|off)    |   (yes|no)    | 
>>>>> |--------------+---------------+---------------|
>>>>> |     on       |     on        |     yes       |
>>>>> |     off      |     off       |     yes       |
>>>>> |     on       |     off       |     no        |
>>>>> |     off      |     on        |     no        |
>>>>> |______________|_______________|_______________|
>>>>>
>>>>> Test tools:
>>>>> makedumpfile[v1.6.3]: https://github.com/LianboJ/makedumpfile
>>>>> commit e1de103eca8f (A draft for kdump vmcore about AMD SME)
>>>>> Author: Lianbo Jiang <lijiang@...hat.com>
>>>>> Date:   Mon May 14 17:02:40 2018 +0800
>>>>> Note: This patch can only dump vmcore in the case of SME enabled.
>>>>>
>>>>> crash-7.2.1: https://github.com/crash-utility/crash.git
>>>>> commit 1e1bd9c4c1be (Fix for the "bpf" command display on Linux 4.17-rc1)
>>>>> Author: Dave Anderson <anderson@...hat.com>
>>>>> Date:   Fri May 11 15:54:32 2018 -0400
>>>>>
>>>>> Test environment:
>>>>> HP ProLiant DL385Gen10 AMD EPYC 7251
>>>>> 8-Core Processor
>>>>> 32768 MB memory
>>>>> 600 GB disk space
>>>>>
>>>>> Linux 4.17-rc4:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>>>> commit 75bc37fefc44 ("Linux 4.17-rc4")
>>>>> Author: Linus Torvalds <torvalds@...ux-foundation.org>
>>>>> Date:   Sun May 6 16:57:38 2018 -1000
>>>>>
>>>>> Reference:
>>>>> AMD64 Architecture Programmer's Manual
>>>>> https://support.amd.com/TechDocs/24593.pdf
>>>>>
>>>>
>>>> Have you also tested this with SEV?  It would be nice if the kdump
>>>> changes you make work with both SME and SEV.
>>>>
>>> Thank you, Tom.
>>> This is a great question, we originally plan to implement SEV in subsequent patches, and
>>> we are also working on SEV at present.
>>> Furthermore, we have another known issue that the system can't jump into the second kernel
>>> when SME is enabled and kaslr is disabled in kdump mode. It seems that is a complex problems,
>>> maybe it is related to kaslr and SME, currently, i'm not sure the root cause, but we will
>>> also plan to fix it. Can you give me any advice about this issue?
>>>
>> Based on upstream 4.17-rc5, we have recently found a new issue that the system can't boot to
>> use kexec when SME is enabled and kaslr is disabled. Have you ever run into this issue? 
>> They have similar reproduction scenarios.
>>
>> CC Tom & Baoquan
> 
> I haven't encountered this issue.  Can you send the kernel config that you
> are using?  And your kernel command line?  I'll try your config and see if
> I can reproduce the issue.
> 
Thank you, Tom.
It doesn't have anything special config, and it's always reproduced.
I will send another email to you about kernel config and command line.
> Just to be clarify, you perform a power-on boot with SME enabled and KASLR
> disabled (e.g. mem_encrypt=on nokaslr), correct, and that won't boot?
>
The system can boot in this case.

Thanks.
Lianbo
> Thanks,
> Tom
> 
>>
>> Thanks.
>> Lianbo
>>
>>> Thanks.
>>> Lianbo
>>>> Thanks,
>>>> Tom
>>>>
>>>>> Lianbo Jiang (2):
>>>>>   add a function(ioremap_encrypted) for kdump when AMD sme enabled.
>>>>>   support kdump when AMD secure memory encryption is active
>>>>>
>>>>>  arch/x86/include/asm/dmi.h      | 14 +++++++++++++-
>>>>>  arch/x86/include/asm/io.h       |  2 ++
>>>>>  arch/x86/kernel/acpi/boot.c     |  8 ++++++++
>>>>>  arch/x86/kernel/crash_dump_64.c | 27 +++++++++++++++++++++++++++
>>>>>  arch/x86/mm/ioremap.c           | 25 +++++++++++++++++--------
>>>>>  drivers/acpi/tables.c           | 14 +++++++++++++-
>>>>>  drivers/iommu/amd_iommu_init.c  |  9 ++++++++-
>>>>>  fs/proc/vmcore.c                | 36 +++++++++++++++++++++++++++++++-----
>>>>>  include/linux/crash_dump.h      |  4 ++++
>>>>>  kernel/kexec_core.c             | 12 ++++++++++++
>>>>>  10 files changed, 135 insertions(+), 16 deletions(-)
>>>>>

Powered by blists - more mailing lists