Re: [PATCH 11/12] habanalabs/gaudi2: add tpm attestation info uapi

[Oded Gabbay]

On Tue, Jun 28, 2022 at 12:22 PM Oded Gabbay <ogabbay@xxxxxxxxxx> wrote:
>
> On Tue, Jun 28, 2022 at 12:12 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Mon, Jun 27, 2022 at 11:26:19PM +0300, Oded Gabbay wrote:
> > > > > From: Dani Liberman <dliberman@xxxxxxxxx>
> > > > >
> > > > > 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 ?

Thanks,
Oded


> Thanks,
> Oded
> >
> > thanks,
> >
> > greg k-h