All of lore.kernel.org
 help / color / mirror / Atom feed
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, 13 Oct 2022 21:48:23 +0200	[thread overview]
Message-ID: <Y0hrhzprPFTK+VWV@zn.tnic> (raw)
In-Reply-To: <20220704135833.1496303-1-martin.fernandez@eclypsium.com>

On Mon, Jul 04, 2022 at 10:58:24AM -0300, Martin Fernandez wrote:
> If all nodes are capable of encryption and if the system have tme/sme
> on we can pretty confidently say that the device is actively
> encrypting all its memory.

Wait, what?

If all memory is crypto capable and I boot with mem_encrypt=off, then
the device is certainly not encrypting any memory.

dhansen says TME cannot be controlled this way and if you turn it off in
the BIOS, EFI_MEMORY_CPU_CRYPTO attr should not be set either. But that
marking won't work on AMD.

You really need to be able to check whether memory encryption is also
enabled.

And I believe I've said this before but even if encryption is on, it is
never "all its memory": the machine can decide to decrypt a page or a
bunch of them for whatever reason. And then they're plaintext.

> It's planned to make this check part of an specification that can be
> passed to people purchasing hardware

How is that supposed to work?

People would boot a Linux on that hardware and fwupd would tell them
whether it can encrypt memory or not?

But if that were the only use case, why can't EFI simply say that in its
fancy GUI?

Because all the kernel seems to be doing here is parrot further
EFI_MEMORY_CPU_CRYPTO.

And that attribute gets set by EFI so it goes and picks apart whether
the underlying hw can encrypt memory. So EFI could report it too.

Hmmm?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  parent reply	other threads:[~2022-10-13 19:48 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 ` Borislav Petkov [this message]
2022-10-13 21:00   ` [PATCH v9 0/9] x86: Show in sysfs if a memory node is able to do encryption Martin Fernandez
2022-10-27  8:57     ` Borislav Petkov
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=Y0hrhzprPFTK+VWV@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.