From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: [PATCH] tpm: remove chip_num parameter from in-kernel API Date: Tue, 24 Oct 2017 11:04:44 -0700 Message-ID: <20171024180444.aewqwgglfmb46h22@dtor-ws> References: <20171023123817.18559-1-jarkko.sakkinen@linux.intel.com> <20171023163139.GA17394@obsidianresearch.com> <20171024154440.3jeupmus43jcgbbz@linux.intel.com> <20171024155526.GA32250@obsidianresearch.com> <20171024161118.GA348@obsidianresearch.com> <20171024173757.GA1806@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20171024173757.GA1806-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jason Gunthorpe Cc: Herbert Xu , "open list:INTEGRITY MEASUREMENT ARCHITECTURE IMA" , PrasannaKumar Muralidharan , Matt Mackall , David Safford , open list , Jarkko Sakkinen , David Howells , linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "moderated list:TPM DEVICE DRIVER" , "open list:KEYS-TRUSTED" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , James Morris , Dmitry Kasatkin , "open list:INTEGRITY MEASUREMENT ARCHITECTURE IMA" , linux-integrity-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mimi Zohar List-Id: tpmdd-devel@lists.sourceforge.net On Tue, Oct 24, 2017 at 11:37:57AM -0600, Jason Gunthorpe wrote: > On Tue, Oct 24, 2017 at 10:02:00AM -0700, Dmitry Torokhov wrote: > > tpm-rng is abomination that should be kicked out as soon as possible. > > It wrecks havoc with the power management (TPM chip drivers may go > > into suspend state, but tpm_rng does not do any power management and > > happily forwards requests to suspended hardware) and may be available > > when there is no TPM at all yet (the drivers have not been probed yet, > > or have gotten a deferral, etc). > > Makes sense > > > TPM core should register HWRNGs when chips are ready. > > The main thing I've wanted from the TPM RNG is > 'add_early_randomness'.. I see... However you can't add any randomness if hardware is not quite there yet. > > We can certainly provide a TPM interface to hwrng, it seems > reasonable. > > Excep that we already have a user api in /dev/tpm to access the > tpm RNG, is the duplication a problem? If we already have userspace API we have to maintain this, even if it is duplicate, there is no way around it. I'd expect most of the users will use unified random API, while some TPM-oriented users may still go via /dev/tpm to use the same API as all other their requests. Thanks. -- Dmitry ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot