From: Martin Fernandez <martin.fernandez@eclypsium.com>
To: linux-coco@lists.linux.dev, linux-mm@kvack.org
Cc: rppt@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>,
Borislav Petkov <bp@alien8.de>,
hughsient@gmail.com, daniel.gutson@eclypsium.com,
Alex Bazhaniuk <alex.bazhaniuk@eclypsium.com>
Subject: [RFC] UABI to show system memory encryption
Date: Tue, 11 Oct 2022 10:59:45 -0300 [thread overview]
Message-ID: <CAKgze5bvqPLo7VZs8rCWc2rFsUekx_d0coKFzObi=J+_nPOacg@mail.gmail.com> (raw)
Hi guys,
I've been working on a patch [1] to show in sysfs the status of the
memory encryption.
One of the parts involved in reporting the status is that the platform
is capable of doing encryption. In this case I focused on x86 EFI
systems, where this is reported as a flag in the EFI memory map:
EFI_MEMORY_CPU_CRYPTO.
From the UEFI spec:
The memory region is capable of being protected with CPU's
capabilities if and only if the flag is set.
After some discussion we decided that it would be nice to show if this
flag is set per memory node, ie, add a new file in the nodeX directory
where it will have a 1 if all the memory in that node is able to do
encryption (has the flag for x86 EFI systems) or 0 otherwise.
The idea is to determine, in conjunction with checking that the CPU is
actually able to do encryption (checking that TME/MKTME is enabled for
example), that a system is actively encryption its memory. Currently
fwupd is looking for something like this, in order to do some security
checks at boot time (more details on the use case on [1]).
More discussion on [2].
Please provide feedback on how this could be improved or new use cases
that could come up.
Thank you.
Martin.
[1] https://lore.kernel.org/linux-efi/20220704135833.1496303-1-martin.fernandez@eclypsium.com/
[2] https://lore.kernel.org/all/20200618210215.23602-1-daniel.gutson@eclypsium.com/
reply other threads:[~2022-10-11 13:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='CAKgze5bvqPLo7VZs8rCWc2rFsUekx_d0coKFzObi=J+_nPOacg@mail.gmail.com' \
--to=martin.fernandez@eclypsium.com \
--cc=alex.bazhaniuk@eclypsium.com \
--cc=bp@alien8.de \
--cc=daniel.gutson@eclypsium.com \
--cc=dave.hansen@linux.intel.com \
--cc=hughsient@gmail.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-mm@kvack.org \
--cc=rppt@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 read-only IMAP folder(s) and NNTP newsgroup(s).