On Tue, Jul 27, 2021 at 11:34:47AM +0200, David Hildenbrand wrote:

What makes you think that? I already heard people express desires for memory
hot(un)plug, especially in the context of running containers inside
encrypted VMs. And static bitmaps are naturally a bad choice for changing
memory layouts.

In the worst case some memory in the bitmap is wasted when memory is
hot-unplugged. The amount depends on how much memory one bit covers, but
I don't see this as a show stopper.

How will the second kernel figure out the location? Similar to how we pass
the physical address of the vmcore header via the cmdline to the new kernel?

As I wrote in the initial proposal, the bitmap will be passed via
boot_params.

Okay, owned by the old kernel, not initially mapped by new kernel in the
identity mapping. Is there a prototype/code that implements that?

No, besides the prototype patch which Kirill sent around.

Yes, but it does not affect the kdump kernel booting, only makedumpfile
might bail out later when it detects a corruption.

I'm wondering, why exactly would a kdump kernel (not touching memory of the
old kernel while booting up) need access to the bitmap? Just wondering, for
ACPI tables and such? I can understand why makedumpfile would need that
information when actually dumping memory of the old kernel, but it would
have access to the memmap of the old kernel to obtain that information.

The kdump kernel needs the bitmap to detect when the Hypervisor is doing
something malicious, well, at least on its own memory. The kdump kernel
has full access to the previous kernels memory and could also be tricked
by the Hypervisor to reveal secrets.

Mirroring is a good point. But I'd suggest using the bitmap only during
early boot if really necessary and after syncing it to the bitmap, get rid
of it. Sure, kexec is more challenging, but at least it's a clean design. We
can always try expressing the state of validated memory in the e820 map we
present to the kexec kernel.

It depends on how fragmented the validated/unvalidated regions will get
over time. I think currently it is not very fragmented, the biggest
shared regions are the .bss_decrypted section and the DMA bounce buffer.
But there are also a couple of page-size regions which need to be
shared. For kexec these regions can be validated again when tearing down
the APs, but for kdump it would be too fragile to do such extensive
stuff before jumping the the kdump kernel.

Regards,

	Joerg