Hi, On Tue, 31 Oct 2023 17:29:25 +0000 "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx> wrote: > 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. I'm sorry I missed that free_decrypted_pages() is added by the very same series, so I cannot use it just yet. I can open-code it and let you convert the code to the new function. You may then also want to convert another open-coded instance further down in swiotlb_free_tlb(). In any case, there is an interdependency between the two patches, so we should agree in which order to apply them. Petr T
