Resubmitting integrity-tpm-internal-kernel-interface.patch, which

    was previously Signed-off-by Kylene Hall.

    Updated per feedback.
    Adds the following support:

    - make internal kernel interface to transmit TPM commands global

    - adds reading a pcr value

    - adds extending a pcr value

    - adds lookup the tpm_chip for given chip number and type
    Signed-off-by: Debora Velarde <debora@linux.vnet.ibm.com>
    Reviewed-by: James Morris <jmorris@namei.org>
Index: security-testing-2.6/drivers/char/tpm/tpm.c

===================================================================

--- security-testing-2.6.orig/drivers/char/tpm/tpm.c

+++ security-testing-2.6/drivers/char/tpm/tpm.c

@@ -1,11 +1,12 @@

 /*

- * Copyright (C) 2004 IBM Corporation

+ * Copyright (C) 2004,2007,2008 IBM Corporation

  *

  * Authors:

  * Leendert van Doorn <leendert@watson.ibm.com>

  * Dave Safford <safford@watson.ibm.com>

  * Reiner Sailer <sailer@watson.ibm.com>

  * Kylene Hall <kjhall@us.ibm.com>

+ * Debora Velarde <dvelarde@us.ibm.com>

  *

  * Maintained by: <tpmdd-devel@lists.sourceforge.net>

  *

@@ -28,6 +29,13 @@

 #include <linux/spinlock.h>

 #include <linux/smp_lock.h>
+#include <linux/mm.h>

+#include <linux/slab.h>

+#include <linux/string.h>

+#include <linux/crypto.h>

+#include <linux/fs.h>

+#include <linux/scatterlist.h>

+#include <asm/unaligned.h>

 #include "tpm.h"
 enum tpm_const {

@@ -50,6 +58,8 @@ enum tpm_duration {

 static LIST_HEAD(tpm_chip_list);

 static DEFINE_SPINLOCK(driver_lock);

 static DECLARE_BITMAP(dev_mask, TPM_NUM_DEVICES);

+#define TPM_CHIP_NUM_MASK       0x0000ffff

+#define TPM_CHIP_TYPE_SHIFT     16
 /*

  * Array with one entry per ordinal defining the maximum amount

@@ -366,8 +376,7 @@ EXPORT_SYMBOL_GPL(tpm_calc_ordinal_durat

 /*

  * Internal kernel interface to transmit TPM commands

  */

-static ssize_t tpm_transmit(st...
[ message continues ]

besides the usual coding style issues, what protects the chip from going

away afer you dropped the lock?
--

I assume the concern here is that between looking up the chip and actually 
using the chip, the TPM chip is disabled/deactivated.  Based on

discussions

with Kenneth Goldman, the TCG main specification part2: structures,

require

that even if the TPM is disabled/deactivated, the command to extend the

PCR

will succeed, but the command to read the PCR will fail with an

appropriate

error code.
Mimi

--

And what happens when the chip simply goes away due to a hotplug action?

Or not even the actual chip goes away but just the chip driver and you

now dereference freed memory?
--

Being a TCG/TPM person, I can only address the first question.  The

intent is that the TPM is soldered to the planar/motherboard (the TCG

uses the phrase "bound to the platform").  I can't imagine

any manufacturer designing a pluggable TPM.  It would subvert PCR

measurements and thus attestation, data sealing, etc.
--

Only 2 TPMs I've seen were on pluggable modules... which was fortunate

because they slowed down boot by 5+ minutes, and broke it completely

in other cases. Nickname 'kurvitko' (aka useless trash that breaks

stuff). They are currently lying under my table, disconnected.
(OTOH they were not on PCI, but on some low-count pin header).

							Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

1 - The pluggable modules use a standard LPC bus header.  In my>

experience, all the TPM vendors supply them in low quantities for

evaluation and test, but no one expects them to be used in

production because of the security issues.
2 - I'd be interested to know whether the slowdown was in

the BIOS, in the OS boot, or on bringup of an application?

Was this Linux or some other OS?
Both the TCG and the platform vendors are very sensitive to

the BIOS part of the boot time.  For example, the TPM self test

is broken into a fast part for features that are required

before boot and a slower part that can be done later. There

are recommendations to break up hashing to remove the TPM

from the critical path.
Even then, the slowest TPM operation is keypair creation,

on the order of 1-5 seconds, which should not be required

during boot.  I wonder if the problem was actually a code

bug or unsupported operation causing timeouts?
It would be great if you could debug a bit and report your

findings to us.
--

Remember even soldered on stuff can fail.   How linux handles the

death of the TPM module needs to be covered.
Peter Dolding

--

Is fault tolerance a requirement just for the TPM, or is it a general>

Linux requirement?  Has it always been there, or is it new?
For example, does kernel software have to gracefully handle

failures in the disk controller, processor, memory controller, BIOS

flash memory, etc?
I'd think it would be quite hard to code around motherboard

failures in a commodity platform not designed for fault tolerance.
--

On Fri, 15 Aug 2008 14:50:01 -0400
Our disk layer will retry, reset, change cable speeds and if that fails

and you are running raid with multipaths or sufficient mirrors continue.

We capture processor exceptions and when possible log and continue

although most CPU failures report with the context corrupt. We log and

the EDAC layer handles as much as it possible can for memory errors

(actually we could be a bit more selective here and there are proposals
The Linux userbase ranges from fault tolerant systems like Stratus to

dodgy cheapo boards from iffy cheap and cheerful computer merchants so it

makes sense to try and be robust.
In your TPM case being robust against the TPM ceasing to respond

certainly is worthwhile so that at least you return an error on failure

rather than the box dying. You may well not be able to get the chip back

in order without a hardware change/reboot.
Alan

--

Well, on a dual/quad core/socket/whatever system, a failing processor

can be downed and the system keep going.  On a NUMA box, you can yank a

node with a bad memory controller after you take it down.  Similarly for

a disk controller if you have more than one, and the failed one isn't

critical for system operation.
And the TPM chip is more like a USB controller, in that there's a *high*

degree of probability that the system will still be able to run even if it

fails or goes insane (consider that on my laptop, the TPM driver was broken

for a while, and I was still ableto work).  So you need to write code to

do things like detect TPM downage or insanity, decide what to do on the

kernel level, what to reflect up to any security modules running in

userspace, etc....

Load up the fake-php hotplug pci driver and "soft" disconnect it from

the system :)
That was easy...
Note, just because you think your device is always going to be soldered

to the motherboard, doesn't mean it can't be disconnected at any point

in time with the kernel running.
Or the module could just be unloaded, that's also a very common thing to

have happen, right?
thanks,
greg k-h

--

linux-security-module-owner@vger.kernel.org wrote on 08/12/2008 07:16:02 
This problem only affects the TPM internal kernel interface, if the TPM

driver is not built-in. For IMA, this is not an issue as the TPM driver

must be built-in in order to start collecting measurements as soon as

possible, which is at late_initcall().  I will resolve this problem for

the general internal kernel interface usage case.
Thanks!
Mimi

--

As I said, I'm a TCG/TPM person, so I can't address "the module could just

be unloaded" or "hotplug pci driver".  I'll leave that issue to the

Linux driver experts.
I was using the common meaning of hotplug, removing and replacing a

hardware component while power is on.  By that common definition, the

TPM would not be a hotpluggable component.
(As an aside, the TPM is commonly connected to the LPC bus on

the planar, not the PCI bus.)
--

So the security limit of your TPM is a soldering iron .. whoo. I'm not

sure this is actually the case however as the secret of interest is in

the TPM so even if I replaced the TPM the goodies already set up are in

the TPM I just unsoldered surely ?
Alan

--

I suppose it depends on the precise interpretation of your technical

term "goodies".  :-)
One of the two primary uses of the TCG technology is protection

against an attack on the software.  The TCG uses the terms

attestation, integrity, platform measurements, etc.  For this class of>

"goodies", the TCG technology does not protect against hardware

attacks such as replacing the TPM with a bogus device, replacing the

CRTM hardware, flashing the CRTM using a JTAG cable, lifting a TPM pin>

and asserting reset, using a JTAG cable to set breakpoints and alter

memory, etc.
For this use case, the attack model is a remote, software attack.  The>

user is not considered the attacker.
(In the other primary use case, the user is the attacker, but it's an

entirely different discussion.)
(It's also important to note that the TPM itself does not completely

secure the platform.  There's an entire system design around it, which>

it why I try to say "TCG technology" rather than TPM.)
--

Surely if I can replace your TPM with alternative hardware then I can

also replace it with virtualised software traps.
[If there is a good document on this btw please just point me there

instead and I'll go read further]

--

Replacing with alternative hardware is outside the attack model.  For this

use case, the TCG assumes the user will not be attacking himself.
Replacing with software is a valid remote attack.  It will be detected

through the TCG platform measurement process.  The local defense is

"sealing" data to trusted measurements.  The remote defense is

"attestation" or "quote", getting signed measurements and deciding
The TPM main specification (design principles) discusses measurements,>

reporting, attestation, and so on.
The "TCG PC Client Specific Implementation Specification For Conventional

BIOS" is specific to the PC platform (there are specifications for mobile

devices, printers, storage, etc.) but section 1.2 has a good discussion

of the concepts.
https://www.trustedcomputinggroup.org/home
(Feel free to email me privately if this is becoming off topic for the

mailing list.)
--

Yes, which in fact is what most people working on TPM support use
I recommend this one:

http://www.few.vu.nl/~srijith/publications/confs/sws07-final.pdf  :)
--