Re: [PATCH v4 3/8] tpm: validate event log access before tpm_bios_log_setup

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Wed, Oct 12, 2016 at 12:41:05AM +0530, Nayna wrote:

> Yeah, I actually tried this today.
> And on call of securityfs_remove(), release() gets called for the
> opened

Are you saying securityfs_remove somehow causes a synchronous call to
release? How does that come about?

> There are actually two private data:
> inode->private
> seq->private
> 
> I understand inode->private is where we pass sfs_data has both chip and
> seqops. This is the one being used in open(), release() and defined as NULL
> in teardown().

> But seq->private is used by seq_ops. And I am still not sure how passing
> seq->private as chip can help.

> I might be missing something basic, so can you please help me to understand
> that.

open does:

 struct tpm_chip *chip = inode->i_private
 get_device(&chip->dev);
 seq = file->private_data;
 seq->private = chip;

release does:

 struct seq_file *seq = file->private_data;
 struct tpm_chip *chip = seq->private;
 put_device(&chip->dev);

seqops like tpm_bios_measurements_start do:

 struct tpm_chip *chip = m->private;
 struct tpm_bios_log *log = &chip->log;

[locking, error handling, and other stuff elided]

open is the only thing that ever looks a inode->i_private.

open krefs's chip and stores it in seq->private

seqop accessors use seq->private->log to access the log, the memory of
which is guared by the kref.

release drops the kref on chip and does not use inode->i_private

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot