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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 E1B83C47404 for ; Fri, 4 Oct 2019 18:20:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C8AF2222C0 for ; Fri, 4 Oct 2019 18:20:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727264AbfJDSUQ (ORCPT ); Fri, 4 Oct 2019 14:20:16 -0400 Received: from mga07.intel.com ([134.134.136.100]:15752 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725730AbfJDSUP (ORCPT ); Fri, 4 Oct 2019 14:20:15 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2019 11:20:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,257,1566889200"; d="scan'208";a="205910170" Received: from nzaki1-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.4.57]) by fmsmga001.fm.intel.com with ESMTP; 04 Oct 2019 11:20:08 -0700 Date: Fri, 4 Oct 2019 21:20:07 +0300 From: Jarkko Sakkinen To: Mimi Zohar Cc: David Safford , linux-integrity@vger.kernel.org, stable@vger.kernel.org, David Howells , Herbert Xu , "David S. Miller" , "open list:ASYMMETRIC KEYS" , "open list:CRYPTO API" , open list Subject: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes() Message-ID: <20191004182007.GA6945@linux.intel.com> References: <20190926171601.30404-1-jarkko.sakkinen@linux.intel.com> <1570024819.4999.119.camel@linux.ibm.com> <20191003114119.GF8933@linux.intel.com> <1570107752.4421.183.camel@linux.ibm.com> <20191003175854.GB19679@linux.intel.com> <1570128827.5046.19.camel@linux.ibm.com> <20191003215125.GA30511@linux.intel.com> <20191003215743.GB30511@linux.intel.com> <1570140491.5046.33.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1570140491.5046.33.camel@linux.ibm.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Oct 03, 2019 at 06:08:11PM -0400, Mimi Zohar wrote: > > At the time when trusted keys was introduced I'd say that it was a wrong > > design decision and badly implemented code. But you are right in that as > > far that code is considered it would unfair to speak of a regression. > > > > asym-tpm.c on the other hand this is fresh new code. There has been > > *countless* of discussions over the years that random numbers should > > come from multiple sources of entropy. There is no other categorization > > than a bug for the tpm_get_random() there. > > This week's LWN article on "5.4 Merge window, part 2" discusses "boot- > time entropy".  This article couldn't have been more perfectly timed. Do not see any obvious relation to this dicussion. Are you saying that you should not use the defacto kernel API's but instead bake your own hacks because even defacto stuff bumps into issues from time to time? And BTW, at the time you call tpm_get_random(), TPM driver is already contributing to the entropy pool (registered as hwrng). /Jarkko