linux-kernel - Re: [PATCH v5 7/7] tpm: create TPM 2.0 devices using own device class

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:	Mon, 3 Nov 2014 14:38:26 -0700
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:	Peter Huewe <peterhuewe@....de>, Ashley Lai <ashley@...leylai.com>,
	Marcel Selhorst <tpmdd@...horst.net>,
	tpmdd-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	josh.triplett@...el.com, christophe.ricard@...il.com,
	jason.gunthorpe@...idianresearch.com
Subject: Re: [PATCH v5 7/7] tpm: create TPM 2.0 devices using own device class

On Mon, Nov 03, 2014 at 07:41:01AM +0200, Jarkko Sakkinen wrote:

> I used the class 'tpm' only for TPM 2.x because I didn't want to
> break the binary compatibility for TPM 1.x anyway. In ideal situtation
> both would be character devices inside the class 'tpm' and there would
> be sysfs attribute such as 'family' to mark the protocol to be used.

You can create the class without moving away from miscdev...

Not having the device creates way to much difference that has to be
supported, way too messy.

> > And considering the volume of changes it might be better to leave
> > 'dev' as a pointer to the tpm class rather than try and tackle that in
> > this giant patch..
> 
> Maybe, or maybe I could make the rename a separate patch?

Pointer then rename?

> It's fairly mechanical, just a matter of replacing string
> "chip->dev" with "chip->pdev".

Not everyone should be replaced :|

> > > +	chip->cdev.owner = chip->pdev->driver->owner;
> > 
> > Is that right? the cdev fops is in this module, not the driver's
> > module..
> 
> tpm.ko defines the interface but TPM device driver module owns the
> character device. I think this is right and similar logic is also
> for example rtc_device_register().

Hmm, yes, I see that in rtc_dev_prepare - but I don't have time to
figure out why that might be :)

On the surface, it doesn't seem to make sense: The cdev layer never
calls into a function that goes to the chip module - all functions go
to the fops in tpm.ko, and tmp.ko is (eventually) responsible for
ensuring that ops never points to an unloaded module.

So why should it care what the driver module is??

> I could understand in the context of a misc device but don't really
> when TPM 2.0 devices have their own device class. Using a 'tpm' class
> would in all cases break non-udev systems because major number is no
> longer 10 (misc).

I'm just saying it would be nice to force the major/minor to misc.tpm
for tmp0.

No idea if that is OK or not.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/