From: Borislav Petkov <bp@alien8.de>
To: 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,
kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.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 v9 0/9] x86: Show in sysfs if a memory node is able to do encryption
Date: Thu, 27 Oct 2022 10:57:32 +0200 [thread overview]
Message-ID: <Y1pH/DuYJeo7Kyo5@zn.tnic> (raw)
In-Reply-To: <CAKgze5ajp-z0+F+8Qo2z=834=i=HNa5=s54MLyrk16wQVnxCzQ@mail.gmail.com>
On Thu, Oct 13, 2022 at 06:00:58PM -0300, Martin Fernandez wrote:
> That's bad, because it would be nice if that attribute only depended
> on the hardware and not on some setting.
Why would that be bad?
You want to be able to disable encryption for whatever reason sometimes.
> The plan of this patch was, as you mentioned just to report
> EFI_MEMORY_CPU_CRYPTO in a per node level.
>
> Now, I think I will need to check for tme/sme and only if those are
> active then show the file in sysfs, otherwise not show it at all,
> because it would be misleading. Any other idea?
Well, I still think this is not going to work in all cases. SME/TME can
be enabled but the kernel can go - and for whatever reason - map a bunch
of memory unencrypted.
So I don't know what the goal of this fwupd checking whether users have
configured memory encryption properly is. It might end up giving that
false sense of security...
> You mean that EFI_MEMORY_CPU_CRYPTO means nothing on an AMD system?
I mean, you still can disable memory encryption.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2022-10-27 8:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-04 13:58 [PATCH v9 0/9] x86: Show in sysfs if a memory node is able to do encryption Martin Fernandez
2022-07-04 13:58 ` [PATCH v9 1/9] mm/memblock: Tag memblocks with crypto capabilities Martin Fernandez
2022-07-04 13:58 ` [PATCH v9 2/9] mm/mmzone: Tag pg_data_t " Martin Fernandez
2022-10-07 15:53 ` Kirill A. Shutemov
2022-10-11 13:28 ` Martin Fernandez
2022-10-11 15:27 ` Kirill A. Shutemov
2022-07-04 13:58 ` [PATCH v9 3/9] x86/e820: Add infrastructure to refactor e820__range_{update,remove} Martin Fernandez
2022-07-04 13:58 ` [PATCH v9 4/9] x86/e820: Refactor __e820__range_update Martin Fernandez
2022-07-04 13:58 ` [PATCH v9 5/9] x86/e820: Refactor e820__range_remove Martin Fernandez
2022-07-04 13:58 ` [PATCH v9 6/9] x86/e820: Tag e820_entry with crypto capabilities Martin Fernandez
2022-07-04 13:58 ` [PATCH v9 7/9] x86/e820: Add unit tests for e820_range_* functions Martin Fernandez
2022-07-05 2:04 ` David Gow
2022-07-05 2:04 ` David Gow
2022-07-05 17:24 ` Martin Fernandez
2022-07-04 13:58 ` [PATCH v9 8/9] x86/efi: Mark e820_entries as crypto capable from EFI memmap Martin Fernandez
2022-07-04 13:58 ` [PATCH v9 9/9] drivers/node: Show in sysfs node's crypto capabilities Martin Fernandez
2022-07-04 14:34 ` Greg KH
2022-07-05 17:35 ` Martin Fernandez
2022-07-06 6:38 ` Greg KH
2022-10-13 19:48 ` [PATCH v9 0/9] x86: Show in sysfs if a memory node is able to do encryption Borislav Petkov
2022-10-13 21:00 ` Martin Fernandez
2022-10-27 8:57 ` Borislav Petkov [this message]
2022-10-27 15:21 ` Dave Hansen
2022-10-27 15:33 ` Borislav Petkov
2022-10-14 0: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=Y1pH/DuYJeo7Kyo5@zn.tnic \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--cc=alex.bazhaniuk@eclypsium.com \
--cc=alison.schofield@intel.com \
--cc=andy@infradead.org \
--cc=ardb@kernel.org \
--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=kunit-dev@googlegroups.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@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.