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