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

[David Hildenbrand <david@redhat.com>]

On 26.07.21 21:02, Joerg Roedel wrote:
> 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.

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.

> 
>> 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.

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?

> 
>> Where will it reside?
> 
> In Linux kernel owned memory, location decided by the kernel
> decompressor.

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

> 
>> 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.

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.

> 
>> 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.

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.

-- 
Thanks,

David / dhildenb