Message-Id: <20201009201410.3209180-1-ira.weiny@intel.com>
Date:   Fri,  9 Oct 2020 13:14:08 -0700
From:   ira.weiny@...el.com
To:     Jonathan Corbet <corbet@....net>,
        David Howells <dhowells@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        James Bottomley <jejb@...ux.ibm.com>,
        Mike Rapoport <rppt@...nel.org>
Cc:     Ira Weiny <ira.weiny@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Fenghua Yu <fenghua.yu@...el.com>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-integrity@...r.kernel.org (open list:KEYS-TRUSTED),
        keyrings@...r.kernel.org (open list:KEYS-TRUSTED),
        linux-security-module@...r.kernel.org (open list:SECURITY SUBSYSTEM)
Subject: [PATCH RFC PKS/Trusted keys 0/2] trusted keys: Add PKS protection to trusted keys

From: Ira Weiny <ira.weiny@...el.com>

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
separately.

	Core PKS support:
	https://lore.kernel.org/lkml/20201009194258.3207172-1-ira.weiny@intel.com/

	PKS/PMEM support (includes global API change):
	https://lore.kernel.org/lkml/20201009195033.3208459-1-ira.weiny@intel.com/

And contained in the git tree here:

	https://github.com/weiny2/linux-kernel/tree/pks-rfc-v3


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(-)

-- 
2.28.0.rc0.12.gb6a658bd00c9

Powered by blists - more mailing lists