[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BE0E16D6-DEC9-4640-89D3-6609A877B8CD@gmx.de>
Date: Tue, 24 Oct 2017 20:40:47 +0200
From: Peter Huewe <peterhuewe@....de>
To: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>
CC: Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
PrasannaKumar Muralidharan <prasannatsmkumar@...il.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
Am 24. Oktober 2017 20:15:12 MESZ schrieb Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>:
>On Tue, Oct 24, 2017 at 10:02:00AM -0700, Dmitry Torokhov wrote:
>> On Tue, Oct 24, 2017 at 9:11 AM, Jason Gunthorpe
>> <jgunthorpe@...idianresearch.com> wrote:
>> > On Tue, Oct 24, 2017 at 09:37:33PM +0530, PrasannaKumar
>Muralidharan wrote:
>> >> Hi Jason,
>> >>
>> >> On 24 October 2017 at 21:25, Jason Gunthorpe
>> >> <jgunthorpe@...idianresearch.com> wrote:
>> >> > On Tue, Oct 24, 2017 at 09:21:15PM +0530, PrasannaKumar
>Muralidharan wrote:
>> >> >
>> >> >> Please check the RFC [1]. It does use chip id. The rfc has
>issues and
>> >> >> has to be fixed but still there could be users of the API.
>> >> >>
>> >> >> 1. https://www.spinics.net/lists/linux-crypto/msg28282.html
>> >> >
>> >> > That patch isn't safe at all. You need to store a kref to th
>chip in
>> >> > the hwrng, not parse a string.
>> >>
>> >> The drivers/char/hw_random/tpm-rng.c module does not store the
>chip
>> >> reference so I guess the usage is safe.
>> >
>> > It is using the default TPM, it is always safe to use the default
>tpm.
>>
>> 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).
>>
>> TPM core should register HWRNGs when chips are ready.
>>
>> Thanks.
>>
>> --
>> Dmitry
>
>I'm fine to review a two patch set where:
>
>1. Patch 1 removes the existing TPM rng driver
>2. Patch 2 makes the TPM driver as rng producer
Yes, but tpm must be kept a hwrng source.
This is imho an important use case.
>
>Unrelate to patch that I'm proposing now but this sounds sensible.
>
>/Jarkko
--
Sent from my mobile
Powered by blists - more mailing lists