Re: SEV guest regression in 4.18
From: Brijesh Singh
Date: Fri Aug 24 2018 - 11:41:43 EST
On 08/23/2018 11:16 AM, Paolo Bonzini wrote:
On 23/08/2018 17:29, Sean Christopherson wrote:
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
On 22/08/2018 22:11, Brijesh Singh wrote:
Yes, this is one of approach I have in mind. It will avoid splitting
the larger pages; I am thinking that early in boot code we can lookup
for this special section and decrypt it in-place and probably maps with
C=0. Only downside, it will increase data section footprint a bit
because we need to align this section to PM_SIZE.
If you can ensure it doesn't span a PMD, maybe it does not need to be
aligned; you could establish a C=0 mapping of the whole 2M around it.
Wouldn't that result in exposing/leaking whatever code/data happened
to reside on the same 2M page (or corrupting it if the entire page
isn't decrypted)? Or are you suggesting that we'd also leave the
encrypted mapping intact?
Yes, exactly the latter, because...
Hardware does not enforce coherency between the encrypted and
unencrypted mapping for the same physical page. So, creating a
two mapping of same physical address will lead a possible data
corruption.
Note, SME creates two mapping of the same physical address to perform
in-place encryption of kernel and initrd images; this is a special case
and APM documents steps on how to do this.
Does hardware include the C-bit in the cache tag?
... the C-bit is effectively part of the physical address and hence of
the cache tag. The kernel is already relying on this to properly
encrypt/decrypt pages, if I remember correctly.
Paolo