On Mon, Jul 19, 2021 at 01:39:48PM -0700, Andi Kleen wrote: > It's actually not just the first X. As I understand there is a proposal for > a new UEFI memory type, that will allow the firmware (and anyone else) to > declare memory regions as accepted in a fine grained manner. Yes, but relying on this means we 1) introduce a dependency to UEFI into booting confidential guests and 2) the decompressor stub in the kernel needs to parse UEFI tables. None of this is a good idea for several reasons. > I don't think it's that bad. If we know what has been validated already > using the memory map, then it's straight forward to check what is a valid > validation request and what is not. Anything that's in a BIOS reserved > region or in a region already marked as validated must be already validated > and and can be rejected (or rather panic'ed). So I don't see the need to > pass a fine grained validation bitmap around. Of course the kernel needs to > maintain something (likely not a bitmap, but rather some form of page flag) > on its own, but it doesn't need to be visible in any outside interfaces. Using page flags means that the information about what is already validated/accepted needs to be carried in another form until the struct-page array is initialized. A lot can happen until then, and every modification in the code that runs before carries the risk of breaking TDX and SNP guests. The Validation Bitmap on the other side is set up on the first boot and kept alive for the rest of the guests life-time (even over kexec/kdump) and will be updated by the allocators in use. This is a much more robust solution than carrying the information in some other way forward until the page array is there. I must admit that I was also voting for a page-flag in the past, but the benefits for robustness, supporting kexec/kdump, and the boot process in general made me re-visit this opinion. > 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. Kexec and kdump are not obscure cases, those are real-world requirements for TDX and SNP guests. > I'm not sure about AMD, but in TDX we're certainly have no need to reaccept > after something was shared. Re-validation is needed on AMD, if I am not mistaken AMD hardware even enforces that shared memory is mapped unencrypted and private memory encrypted. Regards, Joerg
