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

PS: Apologize for sending this twice (resending in plain text mode).

With the new UEFI memory type, option 2 seems like a better option to me.

I was thinking with the lack of new UEFI memory type support yet,
option 3 can be implemented as a temporary solution. IMO, this is
crucial for a reasonable boot performance.

There's one exception to this, which is the previous memory view in
crash kernels. But that's an relatively obscure case and there might be
other solutions for this.

I think this is an important angle. It might cause reliability issues.
if kexec kernel does not know which page is shared or private, it can
use a previously shared page as a code page which will not work. It is
also a security concern. Hosts can always cause crashes which forces
guests to do kexec for crash dump. If the kexec kernel does not know
which pages are validated before, it might be compromised with page
replay attacks.

Also kexec is not only for crash dumps. For warm resets, kexec kernel
needs to know the valid page map.

quoted

Also in general i don't think it will really happen, at least initially.
All the shared buffers we use are allocated and never freed. So such a
problem could be deferred.

Does it not depend on kernel configs? Currently, there is a valid
control path in dma_alloc_coherent which might alloc and free shared
pages.

quoted

At the risk of asking a potentially silly question, would it be
reasonable to treat non-validated memory as not-present for kernel
purposes and hot-add it in a thread as it gets validated?

My concern with this is, it assumes that all the present memory is
private. UEFI might have some pages which are shared therefore also
are present.

On Mon, Jul 19, 2021 at 5:26 PM Andy Lutomirski [off-list ref] wrote:

quoted

On 7/19/21 5:58 AM, Joerg Roedel wrote:

quoted

Memory Validation through the Boot Process and in the Running System
--------------------------------------------------------------------

The memory is validated throughout the boot process as described below.
These steps assume a firmware is present, but this proposal does not
strictly require a firmware. The tasks done be the firmware can also be
done by the hypervisor before starting the guest. The steps are:

      1. The firmware validates all memory which will not be owned by
         the boot loader or the OS.

      2. The firmware also validates the first X MB of memory, just
         enough to run a boot loader and to load the compressed Linux
         kernel image. X is not expected to be very large, 64 or 128
         MB should be enough. This pre-validation should not cause
         significant delays in the boot process.

      3. The validated memory is marked E820-Usable in struct
         boot_params for the Linux decompressor. The rest of the
         memory is also passed to Linux via new special E820 entries
         which mark the memory as Usable-but-Invalid.

      4. When the Linux decompressor takes over control, it evaluates
         the E820 table and calculates to total amount of memory
         available to Linux (valid and invalid memory).

         The decompressor allocates a physically contiguous data
         structure at a random memory location which is big enough to
         hold the the validation states of all 4kb pages available to
         the guest. This data structure will be called the Validation
         Bitmap through the rest of this document. The Validation
         Bitmap is indexed by page frame numbers.

At the risk of asking a potentially silly question, would it be
reasonable to treat non-validated memory as not-present for kernel
purposes and hot-add it in a thread as it gets validated?  Or would this
result in poor system behavior before enough memory is validated?
Perhaps we should block instead of failing allocations if we want more
memory than is currently validated?

--Andy