On Thu, Jun 27, 2024, Tom Lendacky wrote: > On 6/27/24 10:35, Sean Christopherson wrote: > >> The page states are documented in the SNP API (Chapter 5, Page > >> Management): > > > > Heh, but then that section says: > > > > Pages in the Firmware state are owned by the firmware. Because the RMP.Immutable > > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > bit is set, the hypervisor cannot write to Firmware pages nor alter the RMP entry > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > with the RMPUPDATE instruction. > > > > which to me very clearly suggests that the RMP.Immutable bit is what makes the > > page read-only. > > > > Can you ask^Wbribe someone to add a "Table 11. Page State Properties" or something? > > E.g. to explicitly list out the read vs. write protections and the state of the > > page's data (encrypted, integrity-protected, zeroed?, etc). I've read through > > all of "5.2 Page States" and genuinely have no clue as to what protections most > > of the states have. > > I'll get with the document owner and provide that feedback and see what we > can do to remove some of the ambiguity and improve upon it. Thanks! > > Ah, never mind, I found "Table 15-39. RMP Memory Access Checks" in the APM. FWIW, > > that somewhat contradicts this blurb from the SNP ABI spec: > > > > The content of a Context page is encrypted and integrity protected so that the > > hypervisor cannot read or write to it. > > > > I also find that statement confusing. IIUC, the fact that the Context page is > > encrypted and integrity protected doesn't actually have anything to do with the > > host's ability to access the data. The host _can_ read the data, but it will get > > ciphertext. But the host can't write the data because the page isn't HV-owned. > > > > Actually, isn't the intregrity protected part wrong? I thought one of the benefits > > The RMP protection is what helps provide the integrity protection. So if a > hypervisor tries to write to a non-hypervisor owned page, it will generate > an RMP #PF. If the page can't be RMPUPDATEd (the immutable bit is set for > the page in the RMP), then the page can't be written to by the hypervisor. My confusion (ok, maybe it's more annoyance than true confusion) is that that applies to _all_ non-hypervisor pages, not just Context pages. Reading things from a "the exception proves the rule" viewpoint, stating that Context pages are encrypted and integrity protected strongly suggests that all other pages are NOT encrypted and NOT integrity protected.
