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

[David Hildenbrand <david@redhat.com>]

>>
>> 	8. When memory is returned to the memblock or page allocators,
>> 	   it is _not_ invalidated. In fact, all memory which is freed
>> 	   need to be valid. If it was marked invalid in the meantime
>> 	   (e.g. if it the memory was used for DMA buffers), the code
>> 	   owning the memory needs to validate it again before freeing
>> 	   it.
>>
>> 	   The benefit of doing memory validation at allocation time is
>> 	   that it keeps the exception handler for invalid memory
>> 	   simple, because no exceptions of this kind are expected under
>> 	   normal operation.
> 
> During early boot I treat unaccepted memory as a usable RAM. It only
> requires special treatment on memblock_reserve(), which used for early
> memory allocation: unaccepted usable RAM has to be accepted, before
> reserving.
> 
> For fine-grained accepting/validation tracking I use PageOffline() flags
> (it's encoded into mapcount): before adding an unaccepted page to free
> list I set the PageOffline() to indicate that the page has to be accepted
> before returning from the page allocator. Currently, we never have
> PageOffline() set for pages on free lists, so we won't have confusion with
> ballooning or memory hotplug.

I was just about to propose something similar. Something like that 
sounds like the best approach to me

1. Sync e820 to memblock
2. Sync memblock to memmap
3. Let the page allocator deal with validation once initializing/handing 
out memory

PageOffline() does exactly what you want, just be aware that 
PageBuddy()+PageOffline() won't be recognized by crash anymore, as it 
tests for a single memmap value. Can be fixed with makedumpfile updates 
once that applies.

Alternatively, you could use any other page flag that is yet unsued 
combined with PageBuddy.

Sure, there might be obstacles, but it certainly sounds like a clean 
approach to me.

> 
> I try to keep pages accepted in 2M or 4M chunks (pageblock_order or
> MAX_ORDER). It is reasonable compromise on speed/latency.
> 
> I still debugging the code, but hopefully will get working PoC this week.
> 

[...]

> 
> I'm not sure a bitmap is needed. I hope we can use E820 for early
> tracking. But let's see if it works.

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

Also, I am not convinced that kexec/kdump is actually easy to realize 
with the bitmap? Who will forward that bitmap? Where will it reside? Who 
says it's not corrupted? 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.

-- 
Thanks,

David / dhildenb