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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 3DE88C433ED for ; Thu, 1 Apr 2021 05:51:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 00F5861005 for ; Thu, 1 Apr 2021 05:51:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232994AbhDAFui (ORCPT ); Thu, 1 Apr 2021 01:50:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:51520 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229515AbhDAFuI (ORCPT ); Thu, 1 Apr 2021 01:50:08 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7ACDE60FEF; Thu, 1 Apr 2021 05:50:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617256208; bh=KIy5K4ZiwyDNq4I+K6ohLino9Gixd2dsgCQKQ07XJzg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BxMd1wiwtDhjVj5WEif7HEKwJNUeneUPwOmY+gqPMEgwcGvPRlwFU85/ow/6kVo4q P7G3hNm98MzdHjzXo7FstxQQCVsJM2QlJSTwBIfjqzNKZCm5LmuXgFvWdHi6xlfBwD IH5lY/nPvR+i9/ZHtTUosQtRh6Xa5oq128KURD18chrNcevRC8URIUdaazDDigDqw7 nbsXpkABMylEy29S1kWHKgQ40bPWH4/wD1UtFFE4gZJr5jtU2tmnq9vT7/yX6Vyp68 c8UNK0hdXIp98eERQK2kvGbSxCWOYJhygC1a41uYxijMw2BatkkCz/f6Ri/JmvVrfl YmPwvfdXH8msA== Date: Thu, 1 Apr 2021 08:50:05 +0300 From: Jarkko Sakkinen To: Herbert Xu Cc: Eric Biggers , David Gstir , Sumit Garg , Ahmad Fatoum , Mimi Zohar , Horia =?utf-8?Q?Geant=C4=83?= , Jonathan Corbet , David Howells , James Bottomley , "kernel@pengutronix.de" , James Morris , "Serge E. Hallyn" , Aymen Sghaier , "David S. Miller" , Udit Agarwal , Jan Luebbe , Franck Lenormand , "keyrings@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-integrity@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" Subject: Re: [PATCH v1 3/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Message-ID: References: <63dd7d4b-4729-9e03-cd8f-956b94eab0d9@pengutronix.de> <557b92d2-f3b8-d136-7431-419429f0e059@pengutronix.de> <6F812C20-7585-4718-997E-0306C4118468@sigma-star.at> <20210401011132.GB4349@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210401011132.GB4349@gondor.apana.org.au> Precedence: bulk List-ID: On Thu, Apr 01, 2021 at 12:11:32PM +1100, Herbert Xu wrote: > On Wed, Mar 31, 2021 at 04:34:29PM -0700, Eric Biggers wrote: > > On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote: > > > > > > It's a bummer but uapi is the god in the end. Since TPM does not do it > > > today, that behaviour must be supported forever. That's why a boot option > > > AND a warning would be the best compromise. > > > > It's not UAPI if there is no way for userspace to tell if it changed. > > Exactly. UAPI is only an issue if something *breaks*. If there's even one user that comes shouting that he has a user space configuration, where e.g. rng entropy is consumed constantly and the code assumes that trusted keys does not add to that, then something would break. It would be a crap user space yes, but I don't want to go on reverting because of that. I think there is small but still existing chance that something could break. Why not just add a boot parameter instead of making brutal enforcing changes, indirectly visible to the user space? /Jarkko