Re: [PATCH] Add TPM hardware enablement driver

[Jeff Garzik <jgarzik@pobox.com>]

Kylene Hall wrote:
> > what is the purpose of this pci_dev_get/put?  attempting to prevent hotplug or
> > something?
>
>
> Seems that since there is a refernce to the device in the chip structure 
> and I am making the file private data pointer point to that chip structure 
> this is another reference that must be accounted for. If you remove it 
> with it open and attempt read or write bad things will happen.  This isn't 
> really hotpluggable either as the TPM is on the motherboard.

My point was that there will always be a reference -anyway-, AFAICS. 
There is a pci_dev reference assigned to the pci_driver when the PCI 
driver is loaded, and all uses by the TPM generic code of this pointer 
are -inside- the pci_driver's pci_dev object lifetime.


> > > +
> > > +	/* cannot perform a write until the read has cleared
> > > +	   either via tpm_read or a user_read_timer timeout */
> > > +	while (atomic_read(&chip->data_pending) != 0) {
> > > +		set_current_state(TASK_UNINTERRUPTIBLE);
> > > +		schedule_timeout(TPM_TIMEOUT);
>
> > use msleep()
>
>
> addressed in another patch by Nish
>
>
> > > +	/* atomic tpm command send and result receive */
> > > +	out_size = tpm_transmit(chip, chip->data_buffer, TPM_BUFSIZE);
> >
> > major bug?  in_size may be smaller than TPM_BUFSIZE
>
>
> chip->data_buffer is allocated in open and is always this size.  The 
> operation needs to be atomic so the big buffer is to cover the size of a 
> potentially larger result.  Only reading in_size from the user with 
> copy_from_user

You output -more- data than you have input.

AFAICS that's a security bug (data leak), unless you memset the data 
area beforehand.

	Jeff


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