archive mirror
 help / color / mirror / Atom feed
To: Jonathan Corbet <>,
	David Howells <>,
	Andrew Morton <>,
	James Bottomley <>,
	Mike Rapoport <>
Cc: Ira Weiny <>,
	Dave Hansen <>,
	Dan Williams <>,
	Fenghua Yu <>,,,, (open list:KEYS-TRUSTED), (open list:KEYS-TRUSTED), (open list:SECURITY
Subject: [PATCH RFC PKS/Trusted keys 0/2] trusted keys: Add PKS protection to trusted keys
Date: Fri,  9 Oct 2020 13:14:08 -0700	[thread overview]
Message-ID: <> (raw)

From: Ira Weiny <>

Leaking a trusted key would be a critical security issue.  PKS provides an
additional mechanism to restrict access to the memory holding trusted keys.

This series depends on the core patches and PMEM PKS API change submitted

	Core PKS support:

	PKS/PMEM support (includes global API change):

And contained in the git tree here:

Provide a skeleton of a new allocation call which provides a PKS restricted
mapping of the trusted key memory.  Allocate a PKS domain (pkey), create a
mapping with that key, and enable/disable access as needed to that mapping.

The issue with this approach is that it fails to protect the direct mapping.
The current ideas to protect the direct mapping are:

	1) Do nothing.
	2) Allow the direct map to be fragmented through a set_memory_pks() like call.
	3) Piggy back on secretmem's solution to map out some direct map memory
	   then overlay that with PKS.
	4) Integrate PKS into secretmem and use this enhanced secretmem for
	   trusted keys.

Doing nothing is not really providing the level of security we need for this
use case.

Allowing the direct map to fragment may be ok as trusted keys don't use a lot
of pages and are usually allocated early in the system boot but that is not
always the case.  In addition the current code could be made
to not allocating an entire page for each key to limit the number of pages, and
therfore the fragmentation, needed.

The use of secretmem is complicated by its newness but whatever solution is
used there should be used here.  And probalby through some nice interface.

The final thought is to determine if a 'general allocator' for PKS protected
memory should be developed at all.  The current implementation is limited in
key space and so a higher bar to entry may be a good thing.  On the other hand,
dealing with mappings for the average driver writer is complicated and doing
this wrong could result in a false sense of 'security'.

Elena Reshetova (1):
  keys/trusted: protect trusted keys using PKS

Ira Weiny (1):
  vmalloc: Add vmalloc_pks() call

 Documentation/core-api/protection-keys.rst |  4 +
 include/keys/trusted-type.h                |  2 +-
 include/keys/trusted_tpm.h                 | 15 ++++
 include/linux/vmalloc.h                    |  1 +
 mm/vmalloc.c                               | 28 +++++++
 security/keys/encrypted-keys/encrypted.c   | 38 ++++++---
 security/keys/trusted-keys/trusted_tpm1.c  | 90 +++++++++++++++++++---
 security/keys/trusted-keys/trusted_tpm2.c  |  9 +++
 8 files changed, 164 insertions(+), 23 deletions(-)


             reply	other threads:[~2020-10-09 20:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 20:14 ira.weiny [this message]
2020-10-09 20:14 ` [PATCH RFC PKS/Trusted keys 1/2] vmalloc: Add vmalloc_pks() call ira.weiny
2020-10-09 20:14 ` [PATCH RFC PKS/Trusted keys 2/2] keys/trusted: protect trusted keys using PKS ira.weiny

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 NNTP newsgroup(s).