Messages in this thread | | | Date | Fri, 13 Jul 2018 19:08:57 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled |
| |
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.
> 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.
-- Regards/Gruss, Boris.
ECO tip #101: Trim your mails when you reply. --
| |