Re: [PATCH v2 2/3] x86/mm: add .data..decrypted section to hold shared variables

[Brijesh Singh]

On 08/29/2018 10:03 AM, Sean Christopherson wrote:
> On Tue, Aug 28, 2018 at 05:12:56PM -0500, Brijesh Singh wrote:
> > kvmclock defines few static variables which are shared with hypervisor
> > during the kvmclock initialization.
> >
> > When SEV is active, memory is encrypted with a guest-specific key, and
> > if guest OS wants to share the memory region with hypervisor then it must
> > clear the C-bit before sharing it. Currently, we use
> > kernel_physical_mapping_init() to split large pages before clearing the
> > C-bit on shared pages. But the kernel_physical_mapping_init fails when
> > called from the kvmclock initialization (mainly because memblock allocator
> > was not ready).
> >
> > The '__decrypted' can be used to define a shared variable; the variables
> > will be put in the .data.decryption section. This section is mapped with
> > C=0 early in the boot, we also ensure that the initialized values are
> > updated to match with C=0 (i.e perform an in-place decryption). The
> > .data..decrypted section is PMD aligned and sized so that we avoid the
> > need to split the large pages when mapping this section.
>
> What about naming the attribute (and section) '__unencrypted' instead
> of '__decrypted'?  The attribute should be a property describing how
> the data must be accessed, it shouldn't imply anything regarding the
> history of the data.  Decrypted implies that data was once encrypted,
> whereas unencrypted simply states that the data is stored in plain
> text.  All data that has been decrypted is also unencrypted, but the
> reverse does not hold true.


During the initial SEV/SME patch review cycle we had some discussion 
about using decrypted vs unencrypted. At that time the consensus was
that a memory range mapped with C=0 should be referred as 'decrypted'.
Having said so, I do see your point and I am not oppose to calling it
'unencrypted' if others agrees to it.

Tom and Boris, thoughts ?