From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BCF07C4363D for ; Fri, 9 Oct 2020 20:14:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 53A4C2222F for ; Fri, 9 Oct 2020 20:14:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 53A4C2222F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 89F1F940007; Fri, 9 Oct 2020 16:14:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 82707900002; Fri, 9 Oct 2020 16:14:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6EE81940007; Fri, 9 Oct 2020 16:14:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 39147900002 for ; Fri, 9 Oct 2020 16:14:28 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D05E51EE6 for ; Fri, 9 Oct 2020 20:14:27 +0000 (UTC) X-FDA: 77353489374.18.arch90_150e23e271e3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id AF46A101D3D8B for ; Fri, 9 Oct 2020 20:14:27 +0000 (UTC) X-HE-Tag: arch90_150e23e271e3 X-Filterd-Recvd-Size: 4890 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Fri, 9 Oct 2020 20:14:26 +0000 (UTC) IronPort-SDR: yMRnQx5pUEV0SV34EAplL7rEMMbwBPtdp0Jss/lTE9Thr5nR+X3r7egNVZO2eNR8HT+5XW0PHM T1HRhbM0RGdQ== X-IronPort-AV: E=McAfee;i="6000,8403,9769"; a="162070296" X-IronPort-AV: E=Sophos;i="5.77,355,1596524400"; d="scan'208";a="162070296" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2020 13:14:24 -0700 IronPort-SDR: IXEGMVyDlvLok8NfI+TgUT2zaqZMMuibHZuc/fyZxHw/Tz+YeeNyn/uSHL8eXxwdNMNFzoQQ7K WzMGn3a/SXLg== X-IronPort-AV: E=Sophos;i="5.77,355,1596524400"; d="scan'208";a="529062329" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2020 13:14:24 -0700 From: ira.weiny@intel.com To: Jonathan Corbet , David Howells , Andrew Morton , James Bottomley , Mike Rapoport Cc: Ira Weiny , Dave Hansen , Dan Williams , Fenghua Yu , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-integrity@vger.kernel.org (open list:KEYS-TRUSTED), keyrings@vger.kernel.org (open list:KEYS-TRUSTED), linux-security-module@vger.kernel.org (open list:SECURITY SUBSYSTEM) 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 Message-Id: <20201009201410.3209180-1-ira.weiny@intel.com> X-Mailer: git-send-email 2.28.0.rc0.12.gb6a658bd00c9 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Ira Weiny Leaking a trusted key would be a critical security issue. PKS provides a= n additional mechanism to restrict access to the memory holding trusted key= s. 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.co= m/ PKS/PMEM support (includes global API change): https://lore.kernel.org/lkml/20201009195033.3208459-1-ira.weiny@intel.co= m/ 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 restrict= ed 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 mappin= g. The issue with this approach is that it fails to protect the direct mappi= ng. 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 t= his 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 n= ot 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 page= s, 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 protec= ted 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 do= ing 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(-) --=20 2.28.0.rc0.12.gb6a658bd00c9