Message-ID: <YtaW7YilEMLNfkmh@kroah.com>
Date:   Tue, 19 Jul 2022 13:35:09 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Oded Gabbay <ogabbay@...nel.org>
Cc:     "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        Dani Liberman <dliberman@...ana.ai>
Subject: Re: [PATCH 11/12] habanalabs/gaudi2: add tpm attestation info uapi

On Tue, Jul 19, 2022 at 11:27:53AM +0300, Oded Gabbay wrote:
> On Tue, Jun 28, 2022 at 12:22 PM Oded Gabbay <ogabbay@...nel.org> wrote:
> >
> > On Tue, Jun 28, 2022 at 12:12 PM Greg KH <gregkh@...uxfoundation.org> wrote:
> > >
> > > On Tue, Jun 28, 2022 at 11:51:48AM +0300, Oded Gabbay wrote:
> > > > On Tue, Jun 28, 2022 at 9:36 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> > > > >
> > > > > On Mon, Jun 27, 2022 at 11:26:19PM +0300, Oded Gabbay wrote:
> > > > > > From: Dani Liberman <dliberman@...ana.ai>
> > > > > >
> > > > > > User will provide a nonce via the ioctl, and will retrieve
> > > > > > attestation data of the boot from the tpm, generated using given
> > > > > > nonce.
> > > > >
> > > > > Why not use the normal TPM api instead of a new/custom one?  Or is this
> > > > > not a "normal" TPM device?  If not, you should say what it really is.
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > >
> > > > Honestly, I'm not that knowledgeable about it. It is hidden behind our
> > > > firmware code. We just provide a communication method between the
> > > > userspace and the firmware, as the userspace can't interact directly
> > > > with the f/w. i.e. The driver is a transparent tunnel, it doesn't
> > > > interact with registers of the TPM device itself. The "real" driver is
> > > > in our firmware.
> > > >
> > > > So basically we just got definitions from the f/w how to fetch the
> > > > data from them and how to expose it to the user and that's it.
> > > >
> > > > What to do in this case ? Is this considered a "real" TPM ? I imagine
> > > > I won't be able to connect to a standard tpm driver in the kernel as
> > > > the h/w is not exposed to me.
> > >
> > > How is this hardware designed?  Is the TPM in here supposed to be a
> > > real TPM for userspace to use?  Or is this just a random hardware thing
> > > that you use to validate your device somehow and is not supposed to be a
> > > normal TPM as per the specification?
> > We will go talk to our h/w people to find out and I'll get back to you
> > about that.
> > In the meantime, I will remove this patch from the series so it won't
> > hold up the entire
> > support.
> >
> Hi Greg,
> 
> I have talked with our H/W people and Security architect. What we have is
> an embedded TPM on-board, pre-provisioned with IAK, IDevID and their matching
> certificates.
> 
> We use the TPM chip to provide a signed measurement report and signed
> attestation report to the host. i.e. we just use it to validate our device. It
> doesn't behave as a normal TPM per the specifications.
> 
> Therefore, we don't expose it as a host TPM because we don't want the user to
> be able to interact with it. Instead, our driver exposes only the TPM
> measurement report and attestation report and the only component
> that directly communicates with the TPM is Gaudi2 Firmware.
> 
> If we were to expose the TPM directly to the host (as the TPM driver in the
> kernel requires), it would defeat the purpose as the host will be able to
> manipulate the reports of the TPM (reset and set values to the PCRs, etc.).
> 
> I hope this clarifies the real situation. I suggest I will rename the code
> in the driver that exposes this to the userspace so there won't be any
> confusion. i.e. no one will think we are exposing a TPM device to the host.
> 
> wdyt ?

Yes, that makes more sense now, and yes, renaming the code to be more
obvious that this is not a "normal" TPM would be great.

thanks,

greg k-h

Powered by blists - more mailing lists