On 08/24/2018 10:50 AM, Paolo Bonzini wrote:
On 24/08/2018 17:41, Brijesh Singh wrote:
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.
Ah, so that's what I was thinking about. But a single cache line would
never be used both encrypted and unencrypted, would it?
No.
If we create two mapping of same physical address and ensure that
accesses are cache line aligned and size then I think we will safe from
cache point of view.
I have not tried early remap from kvmclock_init() yet and not sure if it
will work so early. The downside of this approach is, we will put
too many constraints on caller; it will need to ensure that variables
are cache line aligned and sized, never accessed with C=1, and must
create a new mapping before accessing it.
I am more inclined towards creating a new section with PMD aligned and
sized. This section will contains the decrypted data. In early
boot code we will update the mapping with C=0. If caller wants to create
a shared variable then it can do so with:
static int foo __decrypted;
I will submit patch fir review.
thanks
