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 <[email protected]>
Reviewed-by: James Morris <[email protected]>
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 <[email protected]>
* Dave Safford <[email protected]>
* Reiner Sailer <[email protected]>
* Kylene Hall <[email protected]>
+ * Debora Velarde <[email protected]>
*
* Maintained by: <[email protected]>
*
@@ -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(struct tpm_chip *chip, const char *buf,
- size_t bufsiz)
+ssize_t tpm_transmit(struct tpm_chip *chip, char *buf, size_t bufsiz)
{
ssize_t rc;
u32 count, ordinal;
@@ -425,6 +434,7 @@ out:
mutex_unlock(&chip->tpm_mutex);
return rc;
}
+EXPORT_SYMBOL_GPL(tpm_transmit);
#define TPM_DIGEST_SIZE 20
#define TPM_ERROR_SIZE 10
@@ -710,6 +720,7 @@ ssize_t tpm_show_temp_deactivated(struct
}
EXPORT_SYMBOL_GPL(tpm_show_temp_deactivated);
+#define READ_PCR_RESULT_SIZE 30
static const u8 pcrread[] = {
0, 193, /* TPM_TAG_RQU_COMMAND */
0, 0, 0, 14, /* length */
@@ -765,6 +776,102 @@ out:
}
EXPORT_SYMBOL_GPL(tpm_show_pcrs);
+/*
+ * tpm_chip_lookup - return tpm_chip for given chip number and type
+ */
+static struct tpm_chip *tpm_chip_lookup(int chip_num, int chip_typ)
+{
+ struct tpm_chip *pos;
+
+ spin_lock(&driver_lock);
+ list_for_each_entry(pos, &tpm_chip_list, list) {
+ if ((chip_num == TPM_ANY_NUM || pos->dev_num == chip_num)
+ && (chip_typ == TPM_ANY_TYPE)) {
+ spin_unlock(&driver_lock);
+ return pos;
+ }
+ }
+
+ spin_unlock(&driver_lock);
+ return NULL;
+}
+
+/**
+ * tpm_pcr_read - read a pcr value
+ * @chip_id: tpm chip identifier
+ * Upper 2 bytes: ANY, HW_ONLY or SW_ONLY
+ * Lower 2 bytes: tpm idx # or AN&
+ * @pcr_idx: pcr idx to retrieve
+ * @res_buf: TPM_PCR value
+ * size of res_buf is 20 bytes (or NULL if you don't care)
+ */
+int tpm_pcr_read(u32 chip_id, int pcr_idx, u8 *res_buf)
+{
+ u8 data[READ_PCR_RESULT_SIZE];
+ int rc;
+ __be32 index;
+ int chip_num = chip_id & TPM_CHIP_NUM_MASK;
+ struct tpm_chip *chip;
+
+ chip = tpm_chip_lookup(chip_num, chip_id >> TPM_CHIP_TYPE_SHIFT);
+ if (chip == NULL)
+ return -ENODEV;
+ BUILD_BUG_ON(sizeof(pcrread) > READ_PCR_RESULT_SIZE);
+ memcpy(data, pcrread, sizeof(pcrread));
+ index = cpu_to_be32(pcr_idx);
+ memcpy(data + 10, &index, 4);
+ rc = tpm_transmit(chip, data, sizeof(data));
+ if (rc > 0)
+ rc = get_unaligned_be32((__be32 *) (data + 6));
+
+ if (rc == 0 && res_buf)
+ memcpy(res_buf, data + 10, TPM_DIGEST_SIZE);
+
+ return rc;
+
+}
+EXPORT_SYMBOL_GPL(tpm_pcr_read);
+
+#define EXTEND_PCR_SIZE 34
+static const u8 pcrextend[] = {
+ 0, 193, /* TPM_TAG_RQU_COMMAND */
+ 0, 0, 0, 34, /* length */
+ 0, 0, 0, 20, /* TPM_ORD_Extend */
+ 0, 0, 0, 0 /* PCR index */
+};
+
+/**
+ * tpm_pcr_extend - extend pcr value with hash
+ * @chip_id: tpm chip identifier
+ * Upper 2 bytes: ANY, HW_ONLY or SW_ONLY
+ * Lower 2 bytes: tpm idx # or AN&
+ * @pcr_idx: pcr idx to extend
+ * @hash: hash value used to extend pcr value
+ */
+int tpm_pcr_extend(u32 chip_id, int pcr_idx, const u8 *hash)
+{
+ u8 data[EXTEND_PCR_SIZE];
+ int rc;
+ __be32 index;
+ int chip_num = chip_id & TPM_CHIP_NUM_MASK;
+ struct tpm_chip *chip;
+
+ chip = tpm_chip_lookup(chip_num, chip_id >> TPM_CHIP_TYPE_SHIFT);
+ if (chip == NULL)
+ return -ENODEV;
+
+ BUILD_BUG_ON(sizeof(pcrextend) > EXTEND_PCR_SIZE);
+ memcpy(data, pcrextend, sizeof(pcrextend));
+ index = cpu_to_be32(pcr_idx);
+ memcpy(data + 10, &index, 4);
+ memcpy(data + 14, hash, TPM_DIGEST_SIZE);
+ rc = tpm_transmit(chip, data, sizeof(data));
+ if (rc > 0)
+ rc = get_unaligned_be32((__be32 *) (data + 6));
+ return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_pcr_extend);
+
#define READ_PUBEK_RESULT_SIZE 314
static const u8 readpubek[] = {
0, 193, /* TPM_TAG_RQU_COMMAND */
Index: security-testing-2.6/drivers/char/tpm/tpm.h
===================================================================
--- security-testing-2.6.orig/drivers/char/tpm/tpm.h
+++ security-testing-2.6/drivers/char/tpm/tpm.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004 IBM Corporation
+ * Copyright (C) 2004, 2007 IBM Corporation
*
* Authors:
* Leendert van Doorn <[email protected]>
@@ -26,6 +26,7 @@
#include <linux/miscdevice.h>
#include <linux/platform_device.h>
#include <linux/io.h>
+#include <linux/tpm.h>
enum tpm_timeout {
TPM_TIMEOUT = 5, /* msecs */
@@ -128,6 +129,7 @@ extern void tpm_get_timeouts(struct tpm_
extern void tpm_gen_interrupt(struct tpm_chip *);
extern void tpm_continue_selftest(struct tpm_chip *);
extern unsigned long tpm_calc_ordinal_duration(struct tpm_chip *, u32);
+ssize_t tpm_transmit(struct tpm_chip *chip, char *buf, size_t bufsiz);
extern struct tpm_chip* tpm_register_hardware(struct device *,
const struct tpm_vendor_specific *);
extern int tpm_open(struct inode *, struct file *);
Index: security-testing-2.6/include/linux/tpm.h
===================================================================
--- /dev/null
+++ security-testing-2.6/include/linux/tpm.h
@@ -0,0 +1,49 @@
+/*
+ * Copyright (C) 2004,2007 IBM Corporation
+ *
+ * Authors:
+ * Leendert van Doorn <[email protected]>
+ * Dave Safford <[email protected]>
+ * Reiner Sailer <[email protected]>
+ * Kylene Hall <[email protected]>
+ * Debora Velarde <[email protected]>
+ *
+ * Maintained by: <[email protected]>
+ *
+ * Device driver for TCG/TCPA TPM (trusted platform module).
+ * Specifications at http://www.trustedcomputinggroup.org
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ */
+#ifndef __LINUX_TPM_H__
+#define __LINUX_TPM_H__
+
+#define PCI_DEVICE_ID_AMD_8111_LPC 0x7468
+
+/*
+ * Chip type is one of these values in the upper two bytes of chip_id
+ */
+enum tpm_chip_type {
+ TPM_HW_TYPE = 0x0,
+ TPM_SW_TYPE = 0x1,
+ TPM_ANY_TYPE = 0xFFFF,
+};
+
+/*
+ * Chip num is this value or a valid tpm idx in lower two bytes of chip_id
+ */
+enum tpm_chip_num {
+ TPM_ANY_NUM = 0xFFFF,
+};
+
+
+#if defined(CONFIG_TCG_TPM) || defined(CONFIG_TCG_TPM_MODULE)
+
+extern int tpm_pcr_read(u32 chip_id, int pcr_idx, u8 *res_buf);
+extern int tpm_pcr_extend(u32 chip_id, int pcr_idx, const u8 *hash);
+#endif
+#endif
--
> +{
> + struct tpm_chip *pos;
> +
> + spin_lock(&driver_lock);
> + list_for_each_entry(pos, &tpm_chip_list, list) {
> + if ((chip_num == TPM_ANY_NUM || pos->dev_num == chip_num)
> + && (chip_typ == TPM_ANY_TYPE)) {
> + spin_unlock(&driver_lock);
> + return pos;
> + }
> + }
> +
> + spin_unlock(&driver_lock);
besides the usual coding style issues, what protects the chip from going
away afer you dropped the lock?
Christoph Hellwig <[email protected]> wrote on 08/09/2008 02:46:22 PM:
> > +{
> > + struct tpm_chip *pos;
> > +
> > + spin_lock(&driver_lock);
> > + list_for_each_entry(pos, &tpm_chip_list, list) {
> > + if ((chip_num == TPM_ANY_NUM || pos->dev_num == chip_num)
> > + && (chip_typ == TPM_ANY_TYPE)) {
> > + spin_unlock(&driver_lock);
> > + return pos;
> > + }
> > + }
> > +
> > + spin_unlock(&driver_lock);
>
> 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
On Mon, Aug 11, 2008 at 05:13:51PM -0400, Mimi Zohar wrote:
>
> 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.
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?
Christoph Hellwig <[email protected]> wrote on 08/12/2008 03:30:31 PM:
> On Mon, Aug 11, 2008 at 05:13:51PM -0400, Mimi Zohar wrote:
> >
> > 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.
>
> 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.
> 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.
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
On Tue, Aug 12, 2008 at 04:57:31PM -0400, Kenneth Goldman wrote:
> Christoph Hellwig <[email protected]> wrote on 08/12/2008 03:30:31 PM:
>
> > On Mon, Aug 11, 2008 at 05:13:51PM -0400, Mimi Zohar wrote:
> > >
> > > 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.
> >
> > 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.
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
Alan Cox <[email protected]> wrote on 08/12/2008 05:36:36 PM:
> > 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.
>
> 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 ?
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.)
Greg KH <[email protected]> wrote on 08/12/2008 07:16:02 PM:
> On Tue, Aug 12, 2008 at 04:57:31PM -0400, Kenneth Goldman wrote:
> > Christoph Hellwig <[email protected]> wrote on 08/12/2008 03:30:31 PM:
> >
> > > 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.
>
> 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?
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.)
> "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.
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]
On Wed, Aug 13, 2008 at 02:40:40PM +0100, Alan Cox wrote:
> > "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.
>
> Surely if I can replace your TPM with alternative hardware then I can
> also replace it with virtualised software traps.
Yes, which in fact is what most people working on TPM support use
because the real hardware is just too slow :)
> [If there is a good document on this btw please just point me there
> instead and I'll go read further]
I recommend this one:
http://www.few.vu.nl/~srijith/publications/confs/sws07-final.pdf :)
Alan Cox <[email protected]> wrote on 08/13/2008 09:40:40 AM:
> > "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.
>
> Surely if I can replace your TPM with alternative hardware then I can
> also replace it with virtualised software traps.
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
whether to trust them.
> [If there is a good document on this btw please just point me there
> instead and I'll go read further]
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.)
[email protected] wrote on 08/12/2008 07:16:02
PM:
> On Tue, Aug 12, 2008 at 04:57:31PM -0400, Kenneth Goldman wrote:
> > Christoph Hellwig <[email protected]> wrote on 08/12/2008 03:30:31 PM:
> >
> > > On Mon, Aug 11, 2008 at 05:13:51PM -0400, Mimi Zohar wrote:
> > > >
> > > > 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.
> > >
> > > 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.
>
> 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?
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
Hi!
> > 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
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
On Thu, Aug 14, 2008 at 9:12 PM, Pavel Machek <[email protected]> wrote:
> Hi!
>
>> > 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
>
> 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
Remember even soldered on stuff can fail. How linux handles the
death of the TPM module needs to be covered.
Peter Dolding
"Peter Dolding" <[email protected]> wrote on 08/15/2008 06:37:27 AM:
> Remember even soldered on stuff can fail. How linux handles the
> death of the TPM module needs to be covered.
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 EDT, Kenneth Goldman said:
> "Peter Dolding" <[email protected]> wrote on 08/15/2008 06:37:27 AM:
>
> > Remember even soldered on stuff can fail. How linux handles the
> > death of the TPM module needs to be covered.
>
> 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?
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....
On Fri, 15 Aug 2008 14:50:01 -0400
Kenneth Goldman <[email protected]> wrote:
> "Peter Dolding" <[email protected]> wrote on 08/15/2008 06:37:27 AM:
>
> > Remember even soldered on stuff can fail. How linux handles the
> > death of the TPM module needs to be covered.
>
> 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?
We try very very hard to not crash on failure.
> For example, does kernel software have to gracefully handle
> failures in the disk controller, processor, memory controller, BIOS
> flash memory, etc?
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
to go further)
> I'd think it would be quite hard to code around motherboard
> failures in a commodity platform not designed for fault tolerance.
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
Pavel Machek <[email protected]> wrote on 08/14/2008 07:12:10 AM:
> 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).
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.