From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mimi Zohar Date: Wed, 20 Mar 2019 12:06:19 +0000 Subject: Re: [PATCH 2/6] security/keys/encrypted: Clean up request_trusted_key() Message-Id: <1553083579.4899.239.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit List-Id: References: <155297557534.2276575.16264199708584900090.stgit@dwillia2-desk3.amr.corp.intel.com> <155297558570.2276575.11731393787282486177.stgit@dwillia2-desk3.amr.corp.intel.com> <1553040398.4899.149.camel@linux.ibm.com> <1553049331.4899.177.camel@linux.ibm.com> In-Reply-To: To: Dan Williams Cc: linux-nvdimm , James Bottomley , Linux Kernel Mailing List , David Howells , keyrings@vger.kernel.org On Tue, 2019-03-19 at 22:48 -0700, Dan Williams wrote: > On Tue, Mar 19, 2019 at 7:36 PM Mimi Zohar wrote: > > > > On Tue, 2019-03-19 at 17:20 -0700, Dan Williams wrote: > > > On Tue, Mar 19, 2019 at 5:07 PM Mimi Zohar wrote: > > > > > > > > On Mon, 2019-03-18 at 23:06 -0700, Dan Williams wrote: > > > > > > > > < snip > > > > > > > > > > +/* > > > > > + * request_trusted_key - request the trusted key > > > > > + * > > > > > + * Trusted keys are sealed to PCRs and other metadata. Although userspace > > > > > + * manages both trusted/encrypted key-types, like the encrypted key type > > > > > + * data, trusted key type data is not visible decrypted from userspace. > > > > > + */ > > > > > +static struct key *request_trusted_key(const char *trusted_desc, > > > > > + const u8 **master_key, size_t *master_keylen) > > > > > +{ > > > > > + struct trusted_key_payload *tpayload; > > > > > + struct key_type *type; > > > > > + struct key *tkey; > > > > > + > > > > > + type = key_type_lookup("trusted"); > > > > > > > > The associated key_type_put() will need to be called. > > > > > > Yes. > > > > I don't know if defining a key_type_lookup() wrapper, perhaps named > > is_key_type_available(), would help. Both key_type_lookup() and > > key_type_put() would be called. The existing code could then remain > > the same. > > > > Maybe, but something still needs to pin the hosting module. I think > this means that the first call to key_type->instantiate() pins the > hosting module, and the ->destroy() of the last key for the key_type > unpins the module. It does mean that the ->destroy() method is no > longer optional. This sounds like it isn't a new problem.  Both issues need to be addressed, but I think we should differentiate between them and address them separately. In terms of the original nvdimm encrypted/trusted key problem, the above suggestion requires the least amount of change.  For v5.2, I would replace it with the full updated patch set. Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1B9892194EB70 for ; Wed, 20 Mar 2019 05:06:38 -0700 (PDT) Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2KC0m9F081440 for ; Wed, 20 Mar 2019 08:06:37 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0b-001b2d01.pphosted.com with ESMTP id 2rbkx4v5np-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 20 Mar 2019 08:06:37 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Mar 2019 12:06:34 -0000 Subject: Re: [PATCH 2/6] security/keys/encrypted: Clean up request_trusted_key() From: Mimi Zohar Date: Wed, 20 Mar 2019 08:06:19 -0400 In-Reply-To: References: <155297557534.2276575.16264199708584900090.stgit@dwillia2-desk3.amr.corp.intel.com> <155297558570.2276575.11731393787282486177.stgit@dwillia2-desk3.amr.corp.intel.com> <1553040398.4899.149.camel@linux.ibm.com> <1553049331.4899.177.camel@linux.ibm.com> Mime-Version: 1.0 Message-Id: <1553083579.4899.239.camel@linux.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: linux-nvdimm , James Bottomley , Linux Kernel Mailing List , David Howells , keyrings@vger.kernel.org List-ID: T24gVHVlLCAyMDE5LTAzLTE5IGF0IDIyOjQ4IC0wNzAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6Cj4g T24gVHVlLCBNYXIgMTksIDIwMTkgYXQgNzozNiBQTSBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC5p Ym0uY29tPiB3cm90ZToKPiA+Cj4gPiBPbiBUdWUsIDIwMTktMDMtMTkgYXQgMTc6MjAgLTA3MDAs IERhbiBXaWxsaWFtcyB3cm90ZToKPiA+ID4gT24gVHVlLCBNYXIgMTksIDIwMTkgYXQgNTowNyBQ TSBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC5pYm0uY29tPiB3cm90ZToKPiA+ID4gPgo+ID4gPiA+ IE9uIE1vbiwgMjAxOS0wMy0xOCBhdCAyMzowNiAtMDcwMCwgRGFuIFdpbGxpYW1zIHdyb3RlOgo+ ID4gPiA+Cj4gPiA+ID4gPCBzbmlwID4KPiA+ID4gPgo+ID4gPiA+ID4gKy8qCj4gPiA+ID4gPiAr ICogcmVxdWVzdF90cnVzdGVkX2tleSAtIHJlcXVlc3QgdGhlIHRydXN0ZWQga2V5Cj4gPiA+ID4g PiArICoKPiA+ID4gPiA+ICsgKiBUcnVzdGVkIGtleXMgYXJlIHNlYWxlZCB0byBQQ1JzIGFuZCBv dGhlciBtZXRhZGF0YS4gQWx0aG91Z2ggdXNlcnNwYWNlCj4gPiA+ID4gPiArICogbWFuYWdlcyBi b3RoIHRydXN0ZWQvZW5jcnlwdGVkIGtleS10eXBlcywgbGlrZSB0aGUgZW5jcnlwdGVkIGtleSB0 eXBlCj4gPiA+ID4gPiArICogZGF0YSwgdHJ1c3RlZCBrZXkgdHlwZSBkYXRhIGlzIG5vdCB2aXNp YmxlIGRlY3J5cHRlZCBmcm9tIHVzZXJzcGFjZS4KPiA+ID4gPiA+ICsgKi8KPiA+ID4gPiA+ICtz dGF0aWMgc3RydWN0IGtleSAqcmVxdWVzdF90cnVzdGVkX2tleShjb25zdCBjaGFyICp0cnVzdGVk X2Rlc2MsCj4gPiA+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB1OCAq Km1hc3Rlcl9rZXksIHNpemVfdCAqbWFzdGVyX2tleWxlbikKPiA+ID4gPiA+ICt7Cj4gPiA+ID4g PiArICAgICBzdHJ1Y3QgdHJ1c3RlZF9rZXlfcGF5bG9hZCAqdHBheWxvYWQ7Cj4gPiA+ID4gPiAr ICAgICBzdHJ1Y3Qga2V5X3R5cGUgKnR5cGU7Cj4gPiA+ID4gPiArICAgICBzdHJ1Y3Qga2V5ICp0 a2V5Owo+ID4gPiA+ID4gKwo+ID4gPiA+ID4gKyAgICAgdHlwZSA9IGtleV90eXBlX2xvb2t1cCgi dHJ1c3RlZCIpOwo+ID4gPiA+Cj4gPiA+ID4gVGhlIGFzc29jaWF0ZWQga2V5X3R5cGVfcHV0KCkg d2lsbCBuZWVkIHRvIGJlIGNhbGxlZC4KPiA+ID4KPiA+ID4gWWVzLgo+ID4KPiA+IEkgZG9uJ3Qg a25vdyBpZiBkZWZpbmluZyBhIGtleV90eXBlX2xvb2t1cCgpIHdyYXBwZXIsIHBlcmhhcHMgbmFt ZWQKPiA+IGlzX2tleV90eXBlX2F2YWlsYWJsZSgpLCB3b3VsZCBoZWxwLiAgQm90aCBrZXlfdHlw ZV9sb29rdXAoKSBhbmQKPiA+IGtleV90eXBlX3B1dCgpIHdvdWxkIGJlIGNhbGxlZC4gIFRoZSBl eGlzdGluZyBjb2RlIGNvdWxkIHRoZW4gcmVtYWluCj4gPiB0aGUgc2FtZS4KPiA+Cj4gCj4gTWF5 YmUsIGJ1dCBzb21ldGhpbmcgc3RpbGwgbmVlZHMgdG8gcGluIHRoZSBob3N0aW5nIG1vZHVsZS4g SSB0aGluawo+IHRoaXMgbWVhbnMgdGhhdCB0aGUgZmlyc3QgY2FsbCB0byBrZXlfdHlwZS0+aW5z dGFudGlhdGUoKSBwaW5zIHRoZQo+IGhvc3RpbmcgbW9kdWxlLCBhbmQgdGhlIC0+ZGVzdHJveSgp IG9mIHRoZSBsYXN0IGtleSBmb3IgdGhlIGtleV90eXBlCj4gdW5waW5zIHRoZSBtb2R1bGUuIEl0 IGRvZXMgbWVhbiB0aGF0IHRoZSAtPmRlc3Ryb3koKSBtZXRob2QgaXMgbm8KPiBsb25nZXIgb3B0 aW9uYWwuCgpUaGlzIHNvdW5kcyBsaWtlIGl0IGlzbid0IGEgbmV3IHByb2JsZW0uIMKgQm90aCBp c3N1ZXMgbmVlZCB0byBiZQphZGRyZXNzZWQsIGJ1dCBJIHRoaW5rIHdlIHNob3VsZCBkaWZmZXJl bnRpYXRlIGJldHdlZW4gdGhlbSBhbmQKYWRkcmVzcyB0aGVtIHNlcGFyYXRlbHkuCgpJbiB0ZXJt cyBvZiB0aGUgb3JpZ2luYWwgbnZkaW1tIGVuY3J5cHRlZC90cnVzdGVkIGtleSBwcm9ibGVtLCB0 aGUKYWJvdmUgc3VnZ2VzdGlvbiByZXF1aXJlcyB0aGUgbGVhc3QgYW1vdW50IG9mIGNoYW5nZS4g wqBGb3IgdjUuMiwgSQp3b3VsZCByZXBsYWNlIGl0IHdpdGggdGhlIGZ1bGwgdXBkYXRlZCBwYXRj aCBzZXQuCgpNaW1pCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpMaW51eC1udmRpbW0gbWFpbGluZyBsaXN0CkxpbnV4LW52ZGltbUBsaXN0cy4wMS5vcmcK aHR0cHM6Ly9saXN0cy4wMS5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1udmRpbW0K 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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 71E97C43381 for ; Wed, 20 Mar 2019 12:06:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 49FA42175B for ; Wed, 20 Mar 2019 12:06:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727365AbfCTMGk (ORCPT ); Wed, 20 Mar 2019 08:06:40 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:56130 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726417AbfCTMGj (ORCPT ); Wed, 20 Mar 2019 08:06:39 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2KBxnIM022674 for ; Wed, 20 Mar 2019 08:06:38 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2rbkrsn7t4-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 20 Mar 2019 08:06:37 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Mar 2019 12:06:34 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 20 Mar 2019 12:06:31 -0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x2KC6UQf33619984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Mar 2019 12:06:30 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D8E96AE055; Wed, 20 Mar 2019 12:06:30 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ED020AE04D; Wed, 20 Mar 2019 12:06:29 +0000 (GMT) Received: from localhost.localdomain (unknown [9.80.93.235]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 20 Mar 2019 12:06:29 +0000 (GMT) Subject: Re: [PATCH 2/6] security/keys/encrypted: Clean up request_trusted_key() From: Mimi Zohar To: Dan Williams Cc: keyrings@vger.kernel.org, James Bottomley , David Howells , Vishal L Verma , linux-nvdimm , Linux Kernel Mailing List Date: Wed, 20 Mar 2019 08:06:19 -0400 In-Reply-To: References: <155297557534.2276575.16264199708584900090.stgit@dwillia2-desk3.amr.corp.intel.com> <155297558570.2276575.11731393787282486177.stgit@dwillia2-desk3.amr.corp.intel.com> <1553040398.4899.149.camel@linux.ibm.com> <1553049331.4899.177.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 19032012-0028-0000-0000-000003564121 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19032012-0029-0000-0000-00002414E274 Message-Id: <1553083579.4899.239.camel@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-20_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903200095 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2019-03-19 at 22:48 -0700, Dan Williams wrote: > On Tue, Mar 19, 2019 at 7:36 PM Mimi Zohar wrote: > > > > On Tue, 2019-03-19 at 17:20 -0700, Dan Williams wrote: > > > On Tue, Mar 19, 2019 at 5:07 PM Mimi Zohar wrote: > > > > > > > > On Mon, 2019-03-18 at 23:06 -0700, Dan Williams wrote: > > > > > > > > < snip > > > > > > > > > > +/* > > > > > + * request_trusted_key - request the trusted key > > > > > + * > > > > > + * Trusted keys are sealed to PCRs and other metadata. Although userspace > > > > > + * manages both trusted/encrypted key-types, like the encrypted key type > > > > > + * data, trusted key type data is not visible decrypted from userspace. > > > > > + */ > > > > > +static struct key *request_trusted_key(const char *trusted_desc, > > > > > + const u8 **master_key, size_t *master_keylen) > > > > > +{ > > > > > + struct trusted_key_payload *tpayload; > > > > > + struct key_type *type; > > > > > + struct key *tkey; > > > > > + > > > > > + type = key_type_lookup("trusted"); > > > > > > > > The associated key_type_put() will need to be called. > > > > > > Yes. > > > > I don't know if defining a key_type_lookup() wrapper, perhaps named > > is_key_type_available(), would help. Both key_type_lookup() and > > key_type_put() would be called. The existing code could then remain > > the same. > > > > Maybe, but something still needs to pin the hosting module. I think > this means that the first call to key_type->instantiate() pins the > hosting module, and the ->destroy() of the last key for the key_type > unpins the module. It does mean that the ->destroy() method is no > longer optional. This sounds like it isn't a new problem.  Both issues need to be addressed, but I think we should differentiate between them and address them separately. In terms of the original nvdimm encrypted/trusted key problem, the above suggestion requires the least amount of change.  For v5.2, I would replace it with the full updated patch set. Mimi