From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Jason Gunthorpe <jgg@ziepe.ca>, Peter Huewe <peterhuewe@gmx.de>,
Andrey Pronin <apronin@chromium.org>,
linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tpm: Add explicit chip->ops locking for sysfs attributes.
Date: Tue, 28 Nov 2017 22:24:42 +0200 [thread overview]
Message-ID: <20171128202442.wrbegoqub46lwntm@linux.intel.com> (raw)
In-Reply-To: <20171127160255.GA16884@roeck-us.net>
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
next prev parent reply other threads:[~2017-11-28 20:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 21:25 [PATCH] tpm: Add explicit chip->ops locking for sysfs attributes Guenter Roeck
2017-11-20 22:13 ` Jarkko Sakkinen
2017-11-20 22:45 ` Guenter Roeck
2017-11-20 23:17 ` Jason Gunthorpe
2017-11-20 23:49 ` Jarkko Sakkinen
2017-11-21 18:28 ` Guenter Roeck
2017-11-21 18:58 ` Jason Gunthorpe
2017-11-26 13:56 ` Jarkko Sakkinen
2017-11-27 16:02 ` Guenter Roeck
2017-11-28 20:24 ` Jarkko Sakkinen [this message]
2017-11-20 23:45 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171128202442.wrbegoqub46lwntm@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=apronin@chromium.org \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=peterhuewe@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).