On Thu, Jun 04, 2020 at 01:11:29PM +1000, David Gibson wrote: > On Mon, Jun 01, 2020 at 10:16:18AM +0100, Dr. David Alan Gilbert wrote: > > * Sean Christopherson (sean.j.christopherson@xxxxxxxxx) wrote: > > > On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote: > > > > Note: I'm using the term "guest memory protection" throughout to refer > > > > to mechanisms like this. I don't particular like the term, it's both > > > > long and not really precise. If someone can think of a succinct way > > > > of saying "a means of protecting guest memory from a possibly > > > > compromised hypervisor", I'd be grateful for the suggestion. > > > > > > Many of the features are also going far beyond just protecting memory, so > > > even the "memory" part feels wrong. Maybe something like protected-guest > > > or secure-guest? > > > > > > A little imprecision isn't necessarily a bad thing, e.g. memory-encryption > > > is quite precise, but also wrong once it encompasses anything beyond plain > > > old encryption. > > > > The common thread I think is 'untrusted host' - but I don't know of a > > better way to describe that. > > Hrm.. UntrustedHost? CompromisedHostMitigation? HostTrustMitigation > (that way it has the same abbreviation as hardware transactional > memory for extra confusion)? HypervisorPowerLimitation? GuestWithTrustIssues? Then we can shorten it to InsecureGuest and cause all kinds of confusion :-D. > HostTrustLimitation? "HTL". That's not too bad, actually, I might go > with that unless someone suggests something better. DePrivelegedHost? "DPH". The "de-privelege" phrase seems to be another recurring theme.
