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.3 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 25264ECE58E for ; Mon, 14 Oct 2019 19:12:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F3DE421A49 for ; Mon, 14 Oct 2019 19:12:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387866AbfJNTL5 (ORCPT ); Mon, 14 Oct 2019 15:11:57 -0400 Received: from mga05.intel.com ([192.55.52.43]:46355 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732490AbfJNTL4 (ORCPT ); Mon, 14 Oct 2019 15:11:56 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2019 12:11:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,296,1566889200"; d="scan'208";a="395289832" Received: from kridax-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.7.178]) by fmsmga005.fm.intel.com with ESMTP; 14 Oct 2019 12:11:52 -0700 Date: Mon, 14 Oct 2019 22:11:50 +0300 From: Jarkko Sakkinen To: Pascal Van Leeuwen Cc: Ken Goldman , "Safford, David (GE Global Research, US)" , Mimi Zohar , "linux-integrity@vger.kernel.org" , "stable@vger.kernel.org" , "open list:ASYMMETRIC KEYS" , "open list:CRYPTO API" , open list Subject: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes() Message-ID: <20191014191150.GB15552@linux.intel.com> References: <20191004182711.GC6945@linux.intel.com> <20191007000520.GA17116@linux.intel.com> <59b88042-9c56-c891-f75e-7c0719eb5ff9@linux.ibm.com> <20191008234935.GA13926@linux.intel.com> <20191008235339.GB13926@linux.intel.com> <20191009073315.GA5884@linux.intel.com> <20191009074133.GA6202@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On Wed, Oct 09, 2019 at 08:09:29AM +0000, Pascal Van Leeuwen wrote: > There's certification and certification. Not all certificates are > created equally. But if it matches your specific requirements, why not. > There's a _lot_ of HW out there that's not x86 though ... > > And: is RDRAND certified for _all_ x86 processors? Or just Intel? > Or perhaps even only _specific (server) models_ of CPU's? > I also know for a fact that some older AMD processors had a broken > RDRAND implementation ... > > So the choice really should be up to the application or user. I'm not seriously suggesting to move rdrand here. I'm trying find the logic how to move forward with trusted keys with multiple backends (not only TPM). AKA we have a kernel rng in existence but no clear policy when it should be used and when not. This leads to throwing a dice with the design choices. Even it TPM RNG is the right choice in tpm_asym.c, the choice was not based on anything (otherwise it would have been documented). /Jarkko