On Mon, Jul 19, 2021 at 8:30 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > What’s the attack you have in mind? With TDX, the guest using the wrong shared vs secure type should, at worst, cause > crashes. With SEV, I can imagine it’s possible for a guest to read or write the ciphertext of a private page, but actually > turning that into an attack seems like it would require convincing a guest to use the same page with both modes. There are a couple of things that can go wrong (maybe more): Imagine Guest set a page shared. It is assumed that the host should remove the SEPT entry but it does not have to, so that entry might stay there with a valid bit set. Guest should accept a page before it accesses it the first time or guest can accept a page as part of #VE handler when a PENDING page is accessed. Current guest patch series (v3) from intel does not have any #VE handler to accept pages on the fly. It seems like it has an assumption that all the pages are accepted by UEFI (I have not reviewed the code yet in detail). Now let's say the kernel wants to access a page for the first time, or after a kexec it wants to make sure all the pages are private. it needs to call tdx_hcall_gpa_intent or tdg_accept_page individually. If the page is already accepted, tdg_accept_page does not return any error in the current implementation in v3. Depending on how this page is being used, it's content is now "not zeroed" as opposed to what it is being expected. Converting this to an attack is not trivial but possible. I did not see any #VE implementation to handle SEPT violations when a page is in PENDING state. I am assuming that this needs to be supported at some point (If not then we need to discuss the use cases for such support). In such an implementation, hypervisor can inject a zeroed page anytime. This seems like a not big deal but IMO it is and it can be used as an attack vector to change conditions, masking variables etc. > >> At the risk of asking a potentially silly question, would it be > >> reasonable to treat non-validated memory as not-present for kernel > >> purposes and hot-add it in a thread as it gets validated? > > My concern with this is, it assumes that all the present memory is private. UEFI might have some pages which are shared therefore also are present. > > > Why is this a problem? In TDX, I don’t think shared pages need any sort of validation. The private memory needs acceptance, but only DoS should be possible by getting it wrong. If EFI passed in a messy map with shared and private transitions all over, there will be a lot of extents in the map, but what actually goes wrong? I mean if the only attack vector is DoS (which is not part of the threat model that TDX is addressing), then why do we even need tdaccept? I thought we need tdaccept to prevent VMM to change the content of a page without guest knowing it. My comment was about if we assume all non-validated memory as not-present, how we were going to handle the shared pages transferred from UEFI to kernel. Those are not validated but the range is present. How can the guest kernel read those shared pages if it does not know that they need to be mapped as shared in the first place. Depending on how the guest kernel is handling shared to private page conversion or how it is initializing the private pages for the first time, a lot of things can go wrong but I need to look at the code to provide more concrete examples. -Erdem
