LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: lijiang <lijiang@redhat.com>
To: Tom Lendacky <thomas.lendacky@amd.com>, linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org, dyoung@redhat.com, bhe@redhat.com
Subject: Re: [PATCH 0/2] support kdump for AMD secure memory encryption(sme)
Date: Mon, 21 May 2018 11:45:57 +0800	[thread overview]
Message-ID: <a0b95743-209a-aca7-33e4-828375df1826@redhat.com> (raw)
In-Reply-To: <18309611-c8c4-92cb-161e-f35ef3d243ea@redhat.com>

在 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@redhat.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@redhat.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@linux-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

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

  reply	other threads:[~2018-05-21  3:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-15  1:51 Lianbo Jiang
2018-05-15  1:51 ` [PATCH 1/2] add a function(ioremap_encrypted) for kdump when AMD sme enabled Lianbo Jiang
2018-05-15 14:34   ` Tom Lendacky
2018-05-16 13:19     ` lijiang
2018-05-15  1:51 ` [PATCH 2/2] support kdump when AMD secure memory encryption is active Lianbo Jiang
2018-05-15 12:42   ` kbuild test robot
2018-05-15 20:18   ` Tom Lendacky
2018-05-16 15:02     ` lijiang
2018-05-17  0:47     ` lijiang
2018-05-15 13:31 ` [PATCH 0/2] support kdump for AMD secure memory encryption(sme) Tom Lendacky
2018-05-17 13:45   ` lijiang
2018-05-21  3:45     ` lijiang [this message]
2018-05-21 13:23       ` Tom Lendacky
2018-05-23  2:02         ` 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=a0b95743-209a-aca7-33e4-828375df1826@redhat.com \
    --to=lijiang@redhat.com \
    --cc=bhe@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas.lendacky@amd.com \
    --subject='Re: [PATCH 0/2] support kdump for AMD secure memory encryption(sme)' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).