lkml.org 
[lkml]   [2020]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Ability to read the MKTME status from userspace (patch v2)
From
Date
On 6/25/20 2:27 PM, Borislav Petkov wrote:
> On Thu, Jun 25, 2020 at 06:16:12PM -0300, Daniel Gutson wrote:
>> What didn't become clear from the thread last time is the direction to
>> proceed. Concrete suggestion?
> Here are two:
>
> https://lkml.kernel.org/r/20200619161752.GG32683@zn.tnic
> https://lkml.kernel.org/r/20200619161026.GF32683@zn.tnic
>
> but before that happens, I'd like to hear Dave confirm that when we
> expose all that information to userspace, it will actually be true and
> show the necessary bits which *actually* tell you that encryption is
> enabled.
>
> If you're still unclear, go over the thread again pls.

It boils down to this: we shouldn't expose low-level, vendor-specific
implementation details if we can avoid it. Let's expose something that
app can actually use.

Something that will work for all of the TME, MKTME and SEV platforms
that I know of and continue to work for a while would be to have a
per-numa-node (/sys/devices/system/node[X]/file) that says: "user data
on this node is protected by memory encryption".

SEV guests would always have a 1 in all nodes.

TME systems with no platform screwiness like PMEM would always have a 1.

Old systems would have a 0 in there.

TME systems which also have PMEM-only nodes would set 0 in PMEM nodes
and 1 on DRAM nodes.

Systems with screwy EFI_MEMORY_CPU_CRYPTO mixing within NUMA nodes would
turn it off for the screwy nodes.

Is that concrete enough?

\
 
 \ /
  Last update: 2020-06-25 23:39    [W:0.040 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site