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 9143CC43461 for ; Wed, 31 Mar 2021 23:32:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 49AF26108C for ; Wed, 31 Mar 2021 23:32:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232901AbhCaXcD (ORCPT ); Wed, 31 Mar 2021 19:32:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:33862 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232982AbhCaXbt (ORCPT ); Wed, 31 Mar 2021 19:31:49 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4F74260FDB; Wed, 31 Mar 2021 23:31:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617233508; bh=22Sf+C8CNMBp5xxIlZSGAARcmSEGXDH2/y17KA34uHY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QLAhGd5dF1Cfe5ThbKZsmV5wk9gLsS57U6plIuuvArE60HI08QwBFhauWE9sOvNIz 3PLR8A7R5B4VariiO6fUUcQkPJ4+V/GFZU17nbbyI1H9Fq5Uzo6OeW+YyZMvNsQe75 ijCs6yoa9ABtG8hA/k0KlAJ72zlPsJ5bo1fU0FH75alQOFLQMV7k2Vdntuh2+Z7A4S 7Fc5SgWybdXlwnky06ucIP+cQeKo1/q/zM7vUhlj+/kaLR7V3bsLDxB1jZyt3Uc5jP RxTMIQL6XGNWVQu0bFl4w85p6i7Xmzdxf6ignQIa+JBaHSc3gf0Lx5oCgFU7nsJ0+l IzyAqtQpF67Ig== Date: Thu, 1 Apr 2021 02:31:46 +0300 From: Jarkko Sakkinen To: Eric Biggers Cc: 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 , Herbert Xu , "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: <01e6e13d-2968-0aa5-c4c8-7458b7bde462@nxp.com> <45a9e159-2dcb-85bf-02bd-2993d50b5748@pengutronix.de> <63dd7d4b-4729-9e03-cd8f-956b94eab0d9@pengutronix.de> <557b92d2-f3b8-d136-7431-419429f0e059@pengutronix.de> <6F812C20-7585-4718-997E-0306C4118468@sigma-star.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: On Tue, Mar 30, 2021 at 02:47:18PM -0700, Eric Biggers wrote: > On Sun, Mar 28, 2021 at 11:37:23PM +0300, Jarkko Sakkinen wrote: > > > > Unfortunately, TPM trusted keys started this bad security practice, and > > obviously it cannot be fixed without breaking uapi backwards compatibility. > > > > The whole point of a randomness source is that it is random. So userspace can't > be depending on any particular output, and the randomness source can be changed > without breaking backwards compatibility. > > So IMO, trusted keys should simply be fixed to use get_random_bytes(). > > - Eric 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. /Jarkko