From: Kees Cook <keescook@chromium.org>
To: Borislav Petkov <bp@alien8.de>
Cc: "Limonciello, Mario" <mario.limonciello@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
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
Subject: Re: [PATCH v6 6/6] drivers/node: Show in sysfs node's crypto capabilities
Date: Sun, 6 Feb 2022 19:39:46 -0800 [thread overview]
Message-ID: <202202061924.6A2D278@keescook> (raw)
In-Reply-To: <Yf1UO6jF91o9k4jB@zn.tnic>
On Fri, Feb 04, 2022 at 05:28:43PM +0100, Borislav Petkov wrote:
> Then we should clear that "sme" flag if memory encryption is not
> enabled. Like we do for all other flags.
Oh, this seems weird to me, as I'd expect it to show up since the CPU is
_capable_ of it, even if it's not in use. (Am I really using avx512vl,
e.g.?)
But as you point out later, it does work that way for a lot of things
and boot params. If this is the way things are supposed to be done,
it looks like we should wire up "nx" vs "noexec=off" boot param to do
the same (separate from this series), though it would need special
care since that bit needs very very early handling both and boot
and resume. Maybe kernel/cpu/common.c should check for _PAGE_NX in
__supported_pte_mask? (And would that break KVM's NX, etc?)
Hmmm.
--
Kees Cook
next prev parent reply other threads:[~2022-02-07 3:39 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
[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 [this message]
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=202202061924.6A2D278@keescook \
--to=keescook@chromium.org \
--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=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mario.limonciello@amd.com \
--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