From: Borislav Petkov <bp@alien8.de>
To: Martin Fernandez <martin.fernandez@eclypsium.com>
Cc: Richard Hughes <hughsient@gmail.com>,
Dave Hansen <dave.hansen@intel.com>,
linux-efi@vger.kernel.org,
Platform Driver <platform-driver-x86@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, X86 ML <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
ardb@kernel.org, dvhart@infradead.org, andy@infradead.org,
Greg KH <gregkh@linuxfoundation.org>,
rafael@kernel.org, Daniel Gutson <daniel.gutson@eclypsium.com>
Subject: Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs
Date: Thu, 28 Oct 2021 20:10:27 +0200 [thread overview]
Message-ID: <YXrnkxgdjWbcPlJA@zn.tnic> (raw)
In-Reply-To: <CAKgze5av=duAc+inw6XnroT1WxHoP6pA2=Bb2tjK45yO6aDfOg@mail.gmail.com>
On Thu, Oct 28, 2021 at 02:39:52PM -0300, Martin Fernandez wrote:
> Because it's not convenient to parse dmesg. And about /proc/cpuinfo,
> it tells you about TME, as a feature of the cpu but it doesn't tell
> you if it is activated,
We can make "tme" or whatever string we decide upon, visible only when
the feature is activated - not a problem. Just like we do on AMD.
> and even if it is activated you will need to be sure that you are
> storing your data in a region flagged with this new attribute.
Can you have a system where some of the memory is crypto-capable and
some of it is not? I've never heard about such a system. At least, on
AMD SME, all your memory gets encrypted...
> Here we discussed about it some time ago:
> http://lkml.iu.edu/hypermail/linux/kernel/2006.2/06753.html . That
> comment is what triggered this patch.
... or maybe dhansen knows more.
So, you folks feeding us piecemeal all these "requirements" won't get
you very far. So please sit down and write a detailed use case about
which customers, when and what exactly they need extracted from the
system and why.
Because this is not all - there's TDX and SEV and SEV-ES and SEV-SNP and
all those partition and encrypt the system or part of it in a different
way. And I'm sure customers will wanna know about that too. Are they
running in an encrypted guest in a public cloud, what security they
have, blabla, everything you can imagine.
And so we won't be adding a different reporting method for each type of
encryption that happens.
But we don't know what we need to report unless we know the use case.
Which is not in the least clear to me.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-10-28 18:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 19:55 [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs Martin Fernandez
2021-10-27 19:55 ` [PATCH v2 1/5] Extend memblock to support memory encryption Martin Fernandez
2021-10-27 19:55 ` [PATCH v2 2/5] Extend pg_data_t to hold information about " Martin Fernandez
2021-10-27 19:55 ` [PATCH v2 3/5] Extend e820_table " Martin Fernandez
2021-10-27 19:55 ` [PATCH v2 4/5] Mark e820_entries as crypto capable from EFI memmap Martin Fernandez
2021-10-27 19:55 ` [PATCH v2 5/5] Show in sysfs if a memory node is able to do memory encryption Martin Fernandez
2021-10-28 18:09 ` Dave Hansen
2021-10-27 20:21 ` [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs Dave Hansen
2021-10-28 14:28 ` Martin Fernandez
2021-10-28 14:55 ` Borislav Petkov
2021-10-28 16:03 ` Richard Hughes
2021-10-28 16:35 ` Borislav Petkov
2021-10-28 17:39 ` Martin Fernandez
2021-10-28 18:10 ` Borislav Petkov [this message]
2021-10-28 18:17 ` Dave Hansen
2021-10-29 17:08 ` Dave Hansen
2021-11-01 18:12 ` Martin Fernandez
2021-11-01 20:10 ` Martin Fernandez
2021-10-29 13:14 ` Richard Hughes
2021-10-28 15:24 ` Dave Hansen
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=YXrnkxgdjWbcPlJA@zn.tnic \
--to=bp@alien8.de \
--cc=andy@infradead.org \
--cc=ardb@kernel.org \
--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=linux-efi@vger.kernel.org \
--cc=luto@kernel.org \
--cc=martin.fernandez@eclypsium.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@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).