Re: Runtime Memory Validation in Intel-TDX and AMD-SNP

[Joerg Roedel <joro@8bytes.org>]

On Thu, Jul 22, 2021 at 05:46:13PM +0200, David Hildenbrand wrote:
> +1, this smells like an anti-patter. I'm absolutely not in favor of a
> bitmap, we have the sparse memory model for a reason.

Well, I doubt that TDX or SNP guests will be set up with a sparse memory
layout.

> Also, I am not convinced that kexec/kdump is actually easy to realize with
> the bitmap?

> Who will forward that bitmap?

The kernel decompressor will create it and forward it to the
decompressed kernel image. The running kernel will pass it on to
kexec'ed kernels for the lifetime of the system.

> Where will it reside?

In Linux kernel owned memory, location decided by the kernel
decompressor.

>Who says it's not corrupted?

If the hypervisor corrupts it we can notice it. The guest kernel can
corrupt it on its own, but that is true for all data in the guest, also
the memmap.

> Just take a look at how we don't even have access to memmap of the
> oldkernel in the newkernel -- and have to locate and decipher it in
> constantly-to-be-updated user space makedumpfile. Any time you'd
> change anything about the bitmap ("hey, let's use larger chunks",
> "hey, let's split it up") you'd break the old_kernel
> <-> new_kernel agreement.

Im not sure if makedumpfile needs to know about that bitmap. If we
mirror the same information into the memmap, then there is definitly no
need for it.

Regards,

	Jörg