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
| ||
|
Date: Tue, 28 Nov 2017 22:24:42 +0200 From: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com> To: Guenter Roeck <linux@...ck-us.net> Cc: Jason Gunthorpe <jgg@...pe.ca>, Peter Huewe <peterhuewe@....de>, Andrey Pronin <apronin@...omium.org>, linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] tpm: Add explicit chip->ops locking for sysfs attributes. On Mon, Nov 27, 2017 at 08:02:55AM -0800, Guenter Roeck wrote: > On Sun, Nov 26, 2017 at 03:56:41PM +0200, Jarkko Sakkinen wrote: > > On Tue, Nov 21, 2017 at 11:58:56AM -0700, Jason Gunthorpe wrote: > > > On Tue, Nov 21, 2017 at 10:28:58AM -0800, Guenter Roeck wrote: > > > > > > > I'll split the patch into two parts, and only add (hopefully) > > > > non-controversial tpm2 attributes for now (which I think is durations > > > > and timeouts). Or, in other words, I'll split the attributes into > > > > two groups - one generic and one for tpm1. > > > > > > Ok. Please look at new attributes you wish to add for tpm2 and see if > > > they meet the modern sysfs sensibility of one value per file, etc. > > > > > > Jason > > > > In general: if something can be retrieved through /dev/tpm0, there is no > > any sane reason to have a sysfs attribute for such. > > > > If I understand correctly, /dev/tpmX can be used to send any TPM command > to the chip. Given that, I translate your statement to mean that no sysfs > attribute will be accepted which sends a TPM command to the chip. This in > turn means that there is no neded to protect sysfs attributes with a lock > since any sysfs attribute requiring that lock will be rejected. > > Thanks for the clarification. Please consider this patch abandoned. > It might be worthwhile mentioning that restriction in the code though - > the comment stating that TPM2 sysfs accesses are disabled due to lack > of locking is obvioulsy incorrect. Your statement about comment is correct. I guess we should rename the file as tpm1_sysfs.c or tpm_legacy_sysfs.c. It is not to say that new sysfs attributes would never make sense (like in PPI case). > Guenter /Jarkko
Powered by blists - more mailing lists