From: Ira Weiny <ira.weiny@xxxxxxxxx> 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@xxxxxxxxx/ PKS/PMEM support (includes global API change): https://lore.kernel.org/lkml/20201009195033.3208459-1-ira.weiny@xxxxxxxxx/ 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