From: "Limonciello, Mario" <mario.limonciello@amd.com>
To: Tom Lendacky <thomas.lendacky@amd.com>, Borislav Petkov <bp@alien8.de>
Cc: Martin Fernandez <martin.fernandez@eclypsium.com>,
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
Subject: Re: [PATCH v6 6/6] drivers/node: Show in sysfs node's crypto capabilities
Date: Fri, 4 Feb 2022 11:49:21 -0600 [thread overview]
Message-ID: <a77c4ede-5285-f354-6944-8fab7503d218@amd.com> (raw)
In-Reply-To: <5ee34cad-8daf-6282-f2ed-cbc92a89d013@amd.com>
On 2/4/2022 11:12, Tom Lendacky wrote:
> On 2/4/22 10:28, Borislav Petkov wrote:
>> On Fri, Feb 04, 2022 at 10:23:22AM -0600, Limonciello, Mario wrote:
>>>>>> As there is interest in seeing these capabilities from userspace, it
>>
>> This needs to be explained in a lot more detail: why, what is going to
>> use it, how, etc.
>>
>> We don't do user-visible APIs just because.
The fwupd daemon has a feature that measures various security aspects of
the system hardware, software and firmware and reflects it out to
consumers (fwupd clients) in an easily consumable format, in some cases
with actionable notes.
In this case the information would be used to make a check about memory
encryption support and enablement. If a sysfs file was made then it
could be something like this:
1) fwupd checks /sys/security/memory_encryption
1: You're encrypted, here's a gold star.
0: keep checking
2) fwupd checks does /proc/cpuinfo have sme, sev_es, or mktme?
No: Your hardware doesn't support encryption, tell the user.
Yes: keep going.
3)AMD?
Check /proc/cmdline, Did user set mem_encrypt=off on explicitly?
That's why. Tell user they can enable it with mem_encrypt=on or
CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
mem_encrypt=on/CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT?
We've got a kernel or hardware problem.
4) Intel?
Document Intel's path to turn it on.
>>
>>> As Tom agreed in previous post, Boris is mistaken here. I just double
>>> checked on my side on a workstation that supports SME and comparing
>>> /proc/cpuinfo before and after SME is enabled via mem_encrypt=on. I
>>> confirmed that nothing changed.
>>
>> Then we should clear that "sme" flag if memory encryption is not
>> enabled. Like we do for all other flags.
>
> If we do that, then this will have to be re-worked:
>
> https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/process.c#L761
>
I guess if sme/sev/sev_es "are" torn out of cpuinfo when encryption is
turned off then that "could" instead do the MSR read perhaps?
>
> Thanks,
> Tom
>
>>
next prev parent reply other threads:[~2022-02-04 17:49 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-03 16:43 [PATCH v6 0/6] x86: Show in sysfs if a memory node is able to do encryption Martin Fernandez
2022-02-03 16:43 ` [PATCH v6 1/6] mm/memblock: Tag memblocks with crypto capabilities Martin Fernandez
2022-02-03 18:07 ` Mike Rapoport
2022-02-03 18:24 ` Martin Fernandez
2022-02-07 21:18 ` Kees Cook
2022-02-08 14:39 ` Martin Fernandez
2022-02-03 16:43 ` [PATCH v6 2/6] mm/mmzone: Tag pg_data_t " Martin Fernandez
2022-02-07 21:19 ` Kees Cook
2022-02-03 16:43 ` [PATCH v6 3/6] x86/e820: Refactor range_update and range_remove Martin Fernandez
2022-02-07 21:45 ` Kees Cook
2022-02-08 8:40 ` Mike Rapoport
2022-02-08 21:01 ` Martin Fernandez
2022-02-15 7:10 ` Mike Rapoport
2022-02-15 14:14 ` Martin Fernandez
2022-02-08 21:09 ` Martin Fernandez
2022-03-04 20:32 ` Martin Fernandez
2022-02-08 21:04 ` Daniel Gutson
2022-02-03 16:43 ` [PATCH v6 4/6] x86/e820: Tag e820_entry with crypto capabilities Martin Fernandez
2022-02-07 21:56 ` Kees Cook
2022-02-08 14:46 ` Martin Fernandez
2022-02-03 16:43 ` [PATCH v6 5/6] x86/efi: Tag e820_entries as crypto capable from EFI memmap Martin Fernandez
2022-02-03 16:43 ` [PATCH v6 6/6] drivers/node: Show in sysfs node's crypto capabilities Martin Fernandez
2022-02-04 3:47 ` Limonciello, Mario
2022-02-04 13:21 ` Martin Fernandez
2022-02-04 15:59 ` Tom Lendacky
2022-02-04 16:23 ` Limonciello, Mario
[not found] ` <Yf1UO6jF91o9k4jB@zn.tnic>
2022-02-04 17:12 ` Tom Lendacky
2022-02-04 17:49 ` Limonciello, Mario [this message]
[not found] ` <Yf1p0ZjPf9Qaqwtg@zn.tnic>
2022-02-04 18:49 ` Tom Lendacky
2022-02-04 21:49 ` Borislav Petkov
2022-02-07 3:39 ` Kees Cook
2022-02-04 4:56 ` Mike Rapoport
2022-02-04 12:27 ` Martin Fernandez
2022-02-04 13:37 ` Mike Rapoport
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=a77c4ede-5285-f354-6944-8fab7503d218@amd.com \
--to=mario.limonciello@amd.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=bp@alien8.de \
--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=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=thomas.lendacky@amd.com \
--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