On Tue, 2023-10-31 at 18:13 +0100, Petr Tesařík wrote: > Thank you for the explanation. So, after set_memory_decrypted() > fails, > the pages become Schroedinger-crypted, but since its true state > cannot > be observed by the guest kernel, it stays as such forever. > > Sweet. > Yes... The untrusted host (the part of the VMM TDX is defending against) gets to specify the return code of these operations (success or failure). But the coco(a general term for TDX and similar from other vendors) threat model doesn't include DOS. So the guest should trust the return code as far as trying to not crash, but not trust it in regards to the potential to leak data. It's a bit to ask of the callers, but the other solution we discussed was to panic the guest if any weirdness is observed by the VMM, in which case the callers would never see the error. And of course panicing the kernel is Bad. So that is how we arrived at this request of the callers. Appreciate the effort to handle it on that side. > Hm, should I incorporate this knowledge into a v2 of my patch and > address both issues? That sounds good to me! Feel free to CC me if you would like, and I can scrutinize it for this particular issue.
