stage2: Use IGVM memory map to resize SVSM kernel

[AdamCDunlap]

If the IGVM memory map contains a PARAVISOR_RESERVED entry, then place the SVSM kernel at that region instead of the region specified in the IgvmParamBlock. If no such entry exists in the memory map, then continue using the IgvmParamBlock.

This allows the hypervisor to dynamically resize the SVSM based on the machine shape without changing the IgvmParamBlock and thus the launch measurement. This is necessary because the SVSM uses more memory when there are more vCPUs (and, in the future, guest memory).

Note this relies on an unpublished IGVM spec change to add the PARAVISOR_RESERVED MemoryMapEntryType.

[AdamCDunlap]

Thanks for taking a look. It seems like the fundamental question here is if a maliciously-chosen kernel region could cause anything worse than DoS. If it can, then we should add checks for the specific conditions necessary (e.g. check alignment, check it doesn't overlap anything important, check a size minimum, or in the worst case check against a few known-good values).

I was under the impression that an incorrect region wouldn't cause anything worse than a DoS, however, which is why I didn't add any checks (besides 4k alignment which is implicit in the multiplication). I'd certainly be open to adding generic checks for things that are weird even if not currently exploitable.

[msft-jlange]

@AdamCDunlap Version 0.3.4 of the igvm crate will be released within the next couple of hours. It defines a new memory type, HIDDEN, which indicates that memory is hidden from the guest outside of the enumeration in the IGVM memory map. You should change your PR to use that name and to update the IGVM version in Cargo.toml. Once that's done, I can approve this PR.

[msft-jlange]

Thanks for getting this done!

[AdamCDunlap]

Thanks for your help!