linux-kernel - Re: [tpmdd-devel] [PATCH] tpm: remove chip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 24 Oct 2017 11:04:44 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:     PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>,
        linux-integrity@...r.kernel.org,
        David Howells <dhowells@...hat.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "open list:INTEGRITY MEASUREMENT ARCHITECTURE IMA" 
        <linux-ima-user@...ts.sourceforge.net>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        open list <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org,
        "moderated list:TPM DEVICE DRIVER" 
        <tpmdd-devel@...ts.sourceforge.net>,
        "open list:KEYS-TRUSTED" <keyrings@...r.kernel.org>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@...r.kernel.org>,
        James Morris <james.l.morris@...cle.com>,
        Matt Mackall <mpm@...enic.com>,
        "open list:INTEGRITY MEASUREMENT ARCHITECTURE IMA" 
        <linux-ima-devel@...ts.sourceforge.net>,
        David Safford <safford@...ibm.com>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from
 in-kernel API

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