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=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=unavailable 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 2F02DC00454 for ; Mon, 9 Dec 2019 20:32:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0AD4520692 for ; Mon, 9 Dec 2019 20:32:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726816AbfLIUcL (ORCPT ); Mon, 9 Dec 2019 15:32:11 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:63454 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726787AbfLIUcK (ORCPT ); Mon, 9 Dec 2019 15:32:10 -0500 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB9KMkoV092333; Mon, 9 Dec 2019 15:31:56 -0500 Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0b-001b2d01.pphosted.com with ESMTP id 2wrt59sytm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Dec 2019 15:31:56 -0500 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id xB9KVcoR031171; Mon, 9 Dec 2019 20:31:55 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma05wdc.us.ibm.com with ESMTP id 2wr3q65nwh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Dec 2019 20:31:55 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id xB9KVtJ642861030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Dec 2019 20:31:55 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 29667B206B; Mon, 9 Dec 2019 20:31:55 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C37FCB205F; Mon, 9 Dec 2019 20:31:53 +0000 (GMT) Received: from jarvis.ext.hansenpartnership.com (unknown [9.85.200.101]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 9 Dec 2019 20:31:53 +0000 (GMT) Message-ID: <1575923513.31378.22.camel@linux.ibm.com> Subject: Re: One question about trusted key of keyring in Linux kernel. From: James Bottomley To: Jarkko Sakkinen Cc: "Zhao, Shirley" , Mimi Zohar , Jonathan Corbet , "linux-integrity@vger.kernel.org" , "keyrings@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "'Mauro Carvalho Chehab'" , "Zhu, Bing" , "Chen, Luhai" Date: Mon, 09 Dec 2019 12:31:53 -0800 In-Reply-To: <20191209194715.GD19243@linux.intel.com> References: <1575057916.6220.7.camel@linux.ibm.com> <1575260220.4080.17.camel@linux.ibm.com> <1575267453.4080.26.camel@linux.ibm.com> <1575269075.4080.31.camel@linux.ibm.com> <1575312932.24227.13.camel@linux.ibm.com> <20191209194715.GD19243@linux.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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-09_04:2019-12-09,2019-12-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 impostorscore=0 bulkscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 mlxlogscore=987 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912090160 Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Mon, 2019-12-09 at 21:47 +0200, Jarkko Sakkinen wrote: > On Mon, Dec 02, 2019 at 10:55:32AM -0800, James Bottomley wrote: > > blob but it looks like we need to fix the API. I suppose the good > > news is given this failure that we have the opportunity to rewrite > > the API since no-one else can have used it for anything because of > > this. The > > I did successfully run this test when I wrote it 5 years ago: > > https://github.com/jsakkine-intel/tpm2-scripts/blob/master/keyctl-smo > ke.sh > > Given that there is API a way must be found that backwards > compatibility > is not broken. New format is fine but it must co-exist. The old API is unsupportable in the combination of policy + auth as I already explained. The kernel doesn't have access to the nonces to generate the HMAC because the session was created by the user and the API has no way to pass them in (plus passing them in would be a huge security failure if we tried). Given that Shirley appears to be the first person ever to try this, I don't think the old API has grown any policy users so its safe to remove it. If we get a complaint, we can discuss adding it back. James