From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [PATCH] security/keys/trusted: Allow operation without hardware TPM Date: Mon, 18 Mar 2019 17:24:40 -0700 Message-ID: <1552955080.2785.26.camel@linux.ibm.com> References: <155295271345.1945351.6465460744078693578.stgit@dwillia2-desk3.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <155295271345.1945351.6465460744078693578.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Dan Williams , jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org Cc: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, Roberto Sassu , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mimi Zohar , David Howells , keyrings-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-nvdimm@lists.01.org On Mon, 2019-03-18 at 16:45 -0700, Dan Williams wrote: > Rather than fail initialization of the trusted.ko module, arrange for > the module to load, but rely on trusted_instantiate() to fail > trusted-key operations. What actual problem is this fixing? To me it would seem like an enhancement to make the trusted module fail at load time if there's no TPM rather than waiting until first use to find out it can never work. Is there some piece of user code that depends on the successful insertion of trusted.ko? James From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Date: Tue, 19 Mar 2019 00:24:40 +0000 Subject: Re: [PATCH] security/keys/trusted: Allow operation without hardware TPM Message-Id: <1552955080.2785.26.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: References: <155295271345.1945351.6465460744078693578.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: <155295271345.1945351.6465460744078693578.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org> To: Dan Williams , jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org Cc: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, Roberto Sassu , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mimi Zohar , David Howells , keyrings-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On Mon, 2019-03-18 at 16:45 -0700, Dan Williams wrote: > Rather than fail initialization of the trusted.ko module, arrange for > the module to load, but rely on trusted_instantiate() to fail > trusted-key operations. What actual problem is this fixing? To me it would seem like an enhancement to make the trusted module fail at load time if there's no TPM rather than waiting until first use to find out it can never work. Is there some piece of user code that depends on the successful insertion of trusted.ko? James 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 C72BFC43381 for ; Tue, 19 Mar 2019 00:24:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8FD72213F2 for ; Tue, 19 Mar 2019 00:24:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726832AbfCSAYu (ORCPT ); Mon, 18 Mar 2019 20:24:50 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:42706 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726438AbfCSAYu (ORCPT ); Mon, 18 Mar 2019 20:24:50 -0400 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2J0Igb3123705 for ; Mon, 18 Mar 2019 20:24:49 -0400 Received: from e15.ny.us.ibm.com (e15.ny.us.ibm.com [129.33.205.205]) by mx0a-001b2d01.pphosted.com with ESMTP id 2rahx381wa-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 18 Mar 2019 20:24:48 -0400 Received: from localhost by e15.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 19 Mar 2019 00:24:46 -0000 Received: from b01cxnp22035.gho.pok.ibm.com (9.57.198.25) by e15.ny.us.ibm.com (146.89.104.202) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 19 Mar 2019 00:24:41 -0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x2J0OfvD11469030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Mar 2019 00:24:42 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D66FC124053; Tue, 19 Mar 2019 00:24:41 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B3BAA12405E; Tue, 19 Mar 2019 00:24:40 +0000 (GMT) Received: from jarvis.ext.hansenpartnership.com (unknown [9.85.131.215]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 19 Mar 2019 00:24:40 +0000 (GMT) Subject: Re: [PATCH] security/keys/trusted: Allow operation without hardware TPM From: James Bottomley To: Dan Williams , jarkko.sakkinen@linux.intel.com Cc: Roberto Sassu , Mimi Zohar , David Howells , keyrings@vger.kernel.org, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org Date: Mon, 18 Mar 2019 17:24:40 -0700 In-Reply-To: <155295271345.1945351.6465460744078693578.stgit@dwillia2-desk3.amr.corp.intel.com> References: <155295271345.1945351.6465460744078693578.stgit@dwillia2-desk3.amr.corp.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 19031900-0068-0000-0000-000003A7AAC1 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00010782; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000281; SDB=6.01176356; UDB=6.00615286; IPR=6.00957041; MB=3.00026041; MTD=3.00000008; XFM=3.00000015; UTC=2019-03-19 00:24:44 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19031900-0069-0000-0000-000047DD126C Message-Id: <1552955080.2785.26.camel@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-18_14:,, 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=792 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903190000 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2019-03-18 at 16:45 -0700, Dan Williams wrote: > Rather than fail initialization of the trusted.ko module, arrange for > the module to load, but rely on trusted_instantiate() to fail > trusted-key operations. What actual problem is this fixing? To me it would seem like an enhancement to make the trusted module fail at load time if there's no TPM rather than waiting until first use to find out it can never work. Is there some piece of user code that depends on the successful insertion of trusted.ko? James