Dave Hansen wrote:
On 4/1/25 08:07, Tom Lendacky wrote:
I haven't tested this, yet, but with SME the BIOS is not encrypted, so that would need an unencrypted mapping.
Could you qualify your mapping with a TDX check? Or can you do something in the /dev/mem support to map appropriately?
I'm adding @Naveen since he is preparing a patch to prevent /dev/mem from accessing ROM areas under SNP as those can trigger #VC for a page that is mapped encrypted but has not been validated. He's looking at possibly adding something to x86_platform_ops that can be overridden. The application would get a bad return code vs an exception.
How many more /dev/mem band-aids will we need for TDX and SEV before we just throw up our hands and turn it off?
I think the problem is bigger than this, we have no data structure besides the iomem resource tree for maintaining mapping consistency and this problem gets worse with the impending TEE I/O work where devices are going to be dynamically transitioning from shared-to-private and back for their MMIO.
Maybe the x86_platform_ops call should just be "Do we allow /dev/mem at all?"
At least x86_platform_ops is the answer if TDX and SEV-SNP have different answers to the question of whether the first 1MB of address should always be mapped encrypted or unencrypted.