From: Dan Williams <dan.j.williams@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Richard Hughes <hughsient@gmail.com>,
Dave Hansen <dave.hansen@intel.com>,
Martin Fernandez <martin.fernandez@eclypsium.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-efi <linux-efi@vger.kernel.org>,
platform-driver-x86@vger.kernel.org,
Linux MM <linux-mm@kvack.org>, "H. Peter Anvin" <hpa@zytor.com>,
daniel.gutson@eclypsium.com, Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
Kees Cook <keescook@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ard Biesheuvel <ardb@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>, X86 ML <x86@kernel.org>,
"Schofield, Alison" <alison.schofield@intel.com>,
alex.bazhaniuk@eclypsium.com,
Greg KH <gregkh@linuxfoundation.org>,
Mike Rapoport <rppt@kernel.org>,
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: Wed, 18 May 2022 11:28:49 -0700 [thread overview]
Message-ID: <CAPcyv4jv52nv=Q=gm783ysU8D56iHzh9-UJrqqkgUve0f_kyZw@mail.gmail.com> (raw)
In-Reply-To: <YoSlzqSGLrQ+jdnD@zn.tnic>
On Wed, May 18, 2022 at 12:53 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Mon, May 16, 2022 at 09:39:06AM +0100, Richard Hughes wrote:
> > This is still something consumers need; at the moment users have no
> > idea if data is *actually* being encrypted.
>
> As it was already pointed out - that's in /proc/cpuinfo.
For TME you still need to compare it against the EFI memory map as
there are exclusion ranges for things like persistent memory. Given
that persistent memory can be forced into volatile "System RAM"
operation by various command line options and driver overrides, you
need to at least trim the assumptions of what is encrypted to the
default "conventional memory" conveyed by platform firmware / BIOS.
next prev parent reply other threads:[~2022-05-18 18:29 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
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 [this message]
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='CAPcyv4jv52nv=Q=gm783ysU8D56iHzh9-UJrqqkgUve0f_kyZw@mail.gmail.com' \
--to=dan.j.williams@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=daniel.gutson@eclypsium.com \
--cc=dave.hansen@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).