[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26206.1218828172@turing-police.cc.vt.edu>
Date: Fri, 15 Aug 2008 15:22:52 -0400
From: Valdis.Kletnieks@...edu
To: Kenneth Goldman <kgoldman@...ibm.com>
Cc: Peter Dolding <oiaohm@...il.com>, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org
Subject: Re: [PATCH 1/4] integrity: TPM internel kernel interface
On Fri, 15 Aug 2008 14:50:01 EDT, Kenneth Goldman said:
> "Peter Dolding" <oiaohm@...il.com> 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....
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists