public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: lijiang <lijiang@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
	tglx@linutronix.de, hpa@zytor.com, ebiederm@xmission.com,
	joro@8bytes.org, thomas.lendacky@amd.com, dyoung@redhat.com,
	kexec@lists.infradead.org, iommu@lists.linux-foundation.org,
	bhe@redhat.com
Subject: Re: [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled
Date: Fri, 20 Jul 2018 13:06:59 +0800	[thread overview]
Message-ID: <33453712-9b0b-e8b9-08a6-de09e0806dd6@redhat.com> (raw)
In-Reply-To: <20180713170857.GB17896@nazgul.tnic>

在 2018年07月14日 01:08, Borislav Petkov 写道:
> On Mon, Jul 09, 2018 at 09:55:35PM +0800, lijiang wrote:
>> About this issue, i want to use an example to describe it.
>> /* drivers/iommu/amd_iommu_init.c */
>> static u8 __iomem * __init iommu_map_mmio_space(u64 address, u64 end)
> 
> Those addresses come from the IVHD header which is an ACPI table. So the
> dump kernel can find that out too.
> Sure. I might understand your means, that will have to find all address out in
order to cover any cases in kdump kernel, those address  might include MMIO
space, HPET, ACPI device table, ERST, and so on... 

>> Obviously, the iommu mmio space is not encrypted, and the device
>> mmio space is outside kdump kernel. We know that the old memory is
>> encrypted, and the old memory is also outside kdump kernel. For the
>> current case, e820__get_entry_type() and walk_iomem_res_desc() can't
>> get the desired result, so we can't also decide whether encryption
>> or not according to this result(rules). If we want to know whether
>> encryption or not by deducing the address, we will need to read the
>> content of memory and have a reference value for comparison, then
>> what's a reference value? Sometimes we don't know that.
> 
> Again, if we don't know that how is the *caller* supposed to know
> whether the memory is encrypted or not? Because
> 
> "we" == "caller"
> 
> in the kdump kernel.
> 
> And the more important question is, why are we dumping MMIO space of the
> previous kernel *at* *all*? That doesn't make any sense to me.
> 
Sorry for my late reply.
Here, it doesn't need to dump MMIO space of the previous kernel, when the
kdump kernel boot, the MMIO address will be remapped in decryption manners,
but the MMIO address don't belong to the range of the crash reserved memory,
for the kdump kernel, the MMIO space(address) and IOMMU device table(address)
are outside address, whereas, the IOMMU device table is encrypted in the first
kernel, the kdump kernel will need to copy the content of IOMMU device table
from the first kernel when the kdump kernel boot, so the IOMMU device table will
be remapped in encryption manners.
So some of them require to be remapped in encryption manners, and some(address)
require to be remapped in decryption manners.


  reply	other threads:[~2018-07-20  5:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-02  7:26 [PATCH 0/5 V5] Support kdump for AMD secure memory encryption(SME) Lianbo Jiang
2018-07-02  7:26 ` [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled Lianbo Jiang
2018-07-02 10:14   ` Borislav Petkov
2018-07-03  2:17     ` lijiang
2018-07-03  9:39       ` Borislav Petkov
2018-07-03 11:25         ` lijiang
2018-07-03 10:58       ` lijiang
2018-07-03 11:14         ` Borislav Petkov
2018-07-03 11:44           ` lijiang
2018-07-09  6:28             ` lijiang
2018-07-09  9:29               ` Borislav Petkov
2018-07-09 13:55                 ` lijiang
2018-07-13 17:08                   ` Borislav Petkov
2018-07-20  5:06                     ` lijiang [this message]
2018-07-20  5:23                       ` Dave Young
2018-07-20  7:32                         ` Borislav Petkov
2018-07-20  9:55                           ` lijiang
2018-07-20 10:08                             ` Boris Petkov
2018-08-16  5:35                               ` lijiang
2018-08-23 15:21                                 ` Borislav Petkov
2018-07-02  7:26 ` [PATCH 2/5 V5] Allocate pages for kdump without encryption when SME is enabled Lianbo Jiang
2018-07-02  7:26 ` [PATCH 3/5 V5] Remap the device table of IOMMU in encrypted manner for kdump Lianbo Jiang
2018-07-02  7:26 ` [PATCH 4/5 V5] Adjust some permanent mappings in unencrypted ways for kdump when SME is enabled Lianbo Jiang
2018-07-02  7:26 ` [PATCH 5/5 V5] Help to dump the old memory encrypted into vmcore file Lianbo Jiang

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=33453712-9b0b-e8b9-08a6-de09e0806dd6@redhat.com \
    --to=lijiang@redhat.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    /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