All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Borislav Petkov <bp@alien8.de>,
	Martin Fernandez <martin.fernandez@eclypsium.com>
Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
	platform-driver-x86@vger.kernel.org, linux-mm@kvack.org,
	tglx@linutronix.de, mingo@redhat.com,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	ardb@kernel.org, dvhart@infradead.org, andy@infradead.org,
	gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org,
	akpm@linux-foundation.org, daniel.gutson@eclypsium.com,
	hughsient@gmail.com, alex.bazhaniuk@eclypsium.com,
	alison.schofield@intel.com, keescook@chromium.org, "Williams,
	Dan J" <dan.j.williams@intel.com>,
	Ben Widawsky <ben.widawsky@intel.com>,
	"Huang, Kai" <kai.huang@intel.com>
Subject: Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption
Date: Fri, 6 May 2022 08:32:29 -0700	[thread overview]
Message-ID: <6d90c832-af4a-7ed6-4f72-dae08bb69c37@intel.com> (raw)
In-Reply-To: <YnUYLDjIThbIz/Uf@zn.tnic>

On 5/6/22 05:44, Borislav Petkov wrote:
>> Dave Hansen pointed those out in a previuos patch serie, here is the
>> quote:
>>
>>> CXL devices will have normal RAM on them, be exposed as "System RAM" and
>>> they won't have encryption capabilities.  I think these devices were
>>> probably the main motivation for EFI_MEMORY_CPU_CRYPTO.
> So this would mean that if a system doesn't have CXL devices and has
> TME/SME/SEV-* enabled, then it is running with encrypted memory.
> 
> Which would then also mean, you don't need any of that code - you only
> need to enumerate CXL devices which, it seems, do not support memory
> encryption, and then state that memory encryption is enabled on the
> whole system, except for the memory of those devices.

CXL devices are just the easiest example to explain, but they are not
the only problem.

For example, Intel NVDIMMs don't support TDX (or MKTME with integrity)
since TDX requires integrity protection and NVDIMMs don't have metadata
space available.

Also, if this were purely a CXL problem, I would have expected this to
have been dealt with in the CXL spec alone.  But, this series is
actually driven by an ACPI spec.  That tells me that we'll see these
mismatched encryption capabilities in many more places than just CXL
devices.


  parent reply	other threads:[~2022-05-06 15:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29 20:17 [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption Martin Fernandez
2022-04-29 20:17 ` [PATCH v8 1/8] mm/memblock: Tag memblocks with crypto capabilities Martin Fernandez
2022-04-29 20:17 ` [PATCH v8 2/8] mm/mmzone: Tag pg_data_t " Martin Fernandez
2022-04-29 20:17 ` [PATCH v8 3/8] x86/e820: Add infrastructure to refactor e820__range_{update,remove} Martin Fernandez
2022-04-29 20:17 ` [PATCH v8 4/8] x86/e820: Refactor __e820__range_update Martin Fernandez
2022-04-29 20:17 ` [PATCH v8 5/8] x86/e820: Refactor e820__range_remove Martin Fernandez
2022-04-29 20:17 ` [PATCH v8 6/8] x86/e820: Tag e820_entry with crypto capabilities Martin Fernandez
2022-04-29 20:17 ` [PATCH v8 7/8] x86/efi: Mark e820_entries as crypto capable from EFI memmap Martin Fernandez
2022-04-29 20:17 ` [PATCH v8 8/8] drivers/node: Show in sysfs node's crypto capabilities Martin Fernandez
2022-05-04 16:38 ` [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption Borislav Petkov
2022-05-04 17:18   ` Martin Fernandez
2022-05-06 12:44     ` Borislav Petkov
2022-05-06 14:18       ` Limonciello, Mario
2022-05-06 15:32       ` Dave Hansen [this message]
2022-05-06 16:00         ` Dan Williams
2022-05-06 17:55           ` Boris Petkov
2022-05-06 18:14             ` Dave Hansen
2022-05-06 18:25               ` Boris Petkov
2022-05-06 18:43                 ` Dave Hansen
2022-05-06 19:02                   ` Boris Petkov
2022-05-09 18:47                     ` Dave Hansen
2022-05-09 22:17                       ` Borislav Petkov
2022-05-09 22:56                         ` Dave Hansen
2022-05-16  8:39                     ` Richard Hughes
2022-05-18  7:52                       ` Borislav Petkov
2022-05-18 18:28                         ` Dan Williams
2022-05-18 20:23                           ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d90c832-af4a-7ed6-4f72-dae08bb69c37@intel.com \
    --to=dave.hansen@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.bazhaniuk@eclypsium.com \
    --cc=alison.schofield@intel.com \
    --cc=andy@infradead.org \
    --cc=ardb@kernel.org \
    --cc=ben.widawsky@intel.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=daniel.gutson@eclypsium.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=hughsient@gmail.com \
    --cc=kai.huang@intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=martin.fernandez@eclypsium.com \
    --cc=mingo@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rppt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.