Messages in this thread | | | Date | Tue, 28 Jun 2022 11:12:03 +0200 | From | Greg KH <> | Subject | Re: [PATCH 11/12] habanalabs/gaudi2: add tpm attestation info uapi |
| |
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@linuxfoundation.org> wrote: > > > > On Mon, Jun 27, 2022 at 11:26:19PM +0300, Oded Gabbay wrote: > > > From: Dani Liberman <dliberman@habana.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?
thanks,
greg k-h
| |