ACPI errors from TPM PPI

ACPI errors from TPM PPI

[Adam Langley]

All TPM PPI calls appear to result in ACPI errors for me:

# cat /sys/devices/pnp0/00:09/ppi/version
cat: version: Cannot allocate memory

(All the nodes in that directory have the same result for read and write.)

This appears to be coming from acpi_evaluate_object_typed in
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_ppi.c#n75,
so I added a printk to get the actual value of |status| when it fails
and it's 5 (aka AE_NOT_FOUND I believe).

My knowledge of ACPI is almost nil, but here's some disassembly from
the DSDT table (I don't know if that's the right one), where it
doesn't seem impossible that it could return the string "1.2".

Scope (_SB.PCI0.LPCB.TPM)
{
 OperationRegion (TSMI, SystemIO, SMIT, 0x02)
 Field (TSMI, ByteAcc, NoLock, Preserve)
 {
  INQ,    8,
  DAT,    8
 }

 Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
 {
  If (LEqual (Arg0, Buffer (0x10)
   {
       /* 0000 */   0xA6, 0xFA, 0xDD, 0x3D, 0x1B, 0x36, 0xB4, 0x4E,
       /* 0008 */   0xA4, 0x24, 0x8D, 0x10, 0x08, 0x9D, 0x16, 0x53
   }))
  {
   Name (_T_0, Zero)  // _T_x: Emitted by ASL Compiler
   Store (ToInteger (Arg2), _T_0)
   If (LEqual (_T_0, Zero))
   {
    Return (Buffer (0x02)
    {
     0xFF, 0x01
    })
   }
   Else
   {
    If (LEqual (_T_0, One))
    {
     Return ("1.2")
    }
    Else
    {
     If (LEqual (_T_0, 0x02))
     {
      ToInteger (DerefOf (Index (Arg3, Zero)), TMF2)
      Store (0x12, TMF1)
      Store (TMF1, DAT)
      Store (OFST, INQ)
      If (LEqual (DAT, 0xFF))
      {
       Return (0x02)
      }
...

# tpm_version
  TPM 1.2 Version Info:
  Chip Version:        1.2.3.69
  Spec Level:          2
  Errata Revision:     3
  TPM Vendor ID:       WEC
  TPM Version:         01010000
  Manufacturer Info:   57454300

The motherboard is an Intel DQ77KB.

Any hints would be very helpful because I'm stuck at this point.

Here's how I got here:

1) I want to store 32 bytes of data in a such a way that they can be
safely erased in the future. With log-structured filesystems and SSDs,
that seems quite hard these days.

2) Using NVRAM looks like it might be fruitful and the TPM has some
designed to be written to, as opposed to the RTC NVRAM, which seems
dangerous.

3) The TPM appears to want a physical presence signal before it'll let
me create a new NVRAM area:

# tpm_nvdefine -s 32 -i 0x10000002 -p WRITEALL
Tspi_NV_DefineSpace failed: 0x0000002d - layer=tpm, code=002d (45),
Bad physical presence value

# sudo tpm_setpresence -z
Physical Presence Status:
Command Enable: true
Hardware Enable: false
Lifetime Lock: true
Physical Presence: false
Lock: true

# sudo tpm_setpresence -z -a
Tspi_TPM_SetStatus failed: 0x00002006 - layer=tcs, code=0006 (6), Not
implemented

There's nothing that I can find in the BIOS to assert presence but I'm
led to understand the the PPI interface allows one to request that the
BIOS assert physical presence:

http://www.trustedcomputinggroup.org/resources/tcg_physical_presence_interface_specification

4) So I'm trying to get the ppi driver to do something.


Cheers

AGL

--
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

Re: ACPI errors from TPM PPI

[Rafael J. Wysocki]

[More CCs, LKML dropped]

On Thursday, July 04, 2013 08:41:00 PM Adam Langley wrote:
> All TPM PPI calls appear to result in ACPI errors for me:
> 
> # cat /sys/devices/pnp0/00:09/ppi/version
> cat: version: Cannot allocate memory
> 
> (All the nodes in that directory have the same result for read and write.)
> 
> This appears to be coming from acpi_evaluate_object_typed in
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_ppi.c#n75,
> so I added a printk to get the actual value of |status| when it fails
> and it's 5 (aka AE_NOT_FOUND I believe).
> 
> My knowledge of ACPI is almost nil, but here's some disassembly from
> the DSDT table (I don't know if that's the right one), where it
> doesn't seem impossible that it could return the string "1.2".
> 
> Scope (_SB.PCI0.LPCB.TPM)
> {
>  OperationRegion (TSMI, SystemIO, SMIT, 0x02)
>  Field (TSMI, ByteAcc, NoLock, Preserve)
>  {
>   INQ,    8,
>   DAT,    8
>  }
> 
>  Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
>  {
>   If (LEqual (Arg0, Buffer (0x10)
>    {
>        /* 0000 */   0xA6, 0xFA, 0xDD, 0x3D, 0x1B, 0x36, 0xB4, 0x4E,
>        /* 0008 */   0xA4, 0x24, 0x8D, 0x10, 0x08, 0x9D, 0x16, 0x53
>    }))
>   {
>    Name (_T_0, Zero)  // _T_x: Emitted by ASL Compiler
>    Store (ToInteger (Arg2), _T_0)
>    If (LEqual (_T_0, Zero))
>    {
>     Return (Buffer (0x02)
>     {
>      0xFF, 0x01
>     })
>    }
>    Else
>    {
>     If (LEqual (_T_0, One))
>     {
>      Return ("1.2")
>     }
>     Else
>     {
>      If (LEqual (_T_0, 0x02))
>      {
>       ToInteger (DerefOf (Index (Arg3, Zero)), TMF2)
>       Store (0x12, TMF1)
>       Store (TMF1, DAT)
>       Store (OFST, INQ)
>       If (LEqual (DAT, 0xFF))
>       {
>        Return (0x02)
>       }
> ...
> 
> # tpm_version
>   TPM 1.2 Version Info:
>   Chip Version:        1.2.3.69
>   Spec Level:          2
>   Errata Revision:     3
>   TPM Vendor ID:       WEC
>   TPM Version:         01010000
>   Manufacturer Info:   57454300
> 
> The motherboard is an Intel DQ77KB.
> 
> Any hints would be very helpful because I'm stuck at this point.
> 
> Here's how I got here:
> 
> 1) I want to store 32 bytes of data in a such a way that they can be
> safely erased in the future. With log-structured filesystems and SSDs,
> that seems quite hard these days.
> 
> 2) Using NVRAM looks like it might be fruitful and the TPM has some
> designed to be written to, as opposed to the RTC NVRAM, which seems
> dangerous.
> 
> 3) The TPM appears to want a physical presence signal before it'll let
> me create a new NVRAM area:
> 
> # tpm_nvdefine -s 32 -i 0x10000002 -p WRITEALL
> Tspi_NV_DefineSpace failed: 0x0000002d - layer=tpm, code=002d (45),
> Bad physical presence value
> 
> # sudo tpm_setpresence -z
> Physical Presence Status:
> Command Enable: true
> Hardware Enable: false
> Lifetime Lock: true
> Physical Presence: false
> Lock: true
> 
> # sudo tpm_setpresence -z -a
> Tspi_TPM_SetStatus failed: 0x00002006 - layer=tcs, code=0006 (6), Not
> implemented
> 
> There's nothing that I can find in the BIOS to assert presence but I'm
> led to understand the the PPI interface allows one to request that the
> BIOS assert physical presence:
> 
> http://www.trustedcomputinggroup.org/resources/tcg_physical_presence_interface_specification
> 
> 4) So I'm trying to get the ppi driver to do something.
> 
> 
> Cheers
> 
> AGL
> 
> --
> Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
> --
> 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/
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: ACPI errors from TPM PPI

[Adam Langley]

On Thu, Jul 4, 2013 at 9:07 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> This appears to be coming from acpi_evaluate_object_typed in
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_ppi.c#n75,
>> so I added a printk to get the actual value of |status| when it fails
>> and it's 5 (aka AE_NOT_FOUND I believe).

In hindsight, the error was somewhat obvious. The driver is locating
the TPM object in the ACPI tables by walking the tables with a
callback [1]. The callback is using strstr to look for the substring
"TPM" in the handle of the object and returns the first that it finds.
On my system, if I alter the callback to print each match and not
abort the walk I find three values:

\_SB_.PCI0.TPMX
\_SB_.PCI0.LPCB.TPM_
\_SB_.PCI0.ITPM

Of these, the second is the right one.

(I note that the callback also appears to have a memory leak in the
case that the string doesn't contain "TPM".)

I'm sure that the strstr() worked on the computer that it was
developed on, but it's rather fragile. I can get it working for me by
using "LPCB.TPM" as the argument to strstr(), but who's to say that
doesn't break someone else?

So I would submit a patch if I was more confident that I was actually
improving matters by doing so!

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_ppi.c#n27


Cheers

AGL

Re: ACPI errors from TPM PPI

[Mika Westerberg]

On Fri, Jul 05, 2013 at 10:03:10AM -0400, Adam Langley wrote:
> On Thu, Jul 4, 2013 at 9:07 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> This appears to be coming from acpi_evaluate_object_typed in
> >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_ppi.c#n75,
> >> so I added a printk to get the actual value of |status| when it fails
> >> and it's 5 (aka AE_NOT_FOUND I believe).
> 
> In hindsight, the error was somewhat obvious. The driver is locating
> the TPM object in the ACPI tables by walking the tables with a
> callback [1]. The callback is using strstr to look for the substring
> "TPM" in the handle of the object and returns the first that it finds.
> On my system, if I alter the callback to print each match and not
> abort the walk I find three values:
> 
> \_SB_.PCI0.TPMX
> \_SB_.PCI0.LPCB.TPM_
> \_SB_.PCI0.ITPM
> 
> Of these, the second is the right one.
> 
> (I note that the callback also appears to have a memory leak in the
> case that the string doesn't contain "TPM".)
> 
> I'm sure that the strstr() worked on the computer that it was
> developed on, but it's rather fragile. I can get it working for me by
> using "LPCB.TPM" as the argument to strstr(), but who's to say that
> doesn't break someone else?

I wonder whether there is a real PNP Id associated with that device?

I have one sample ASL code that looks like:

    Device (\_SB.PCI0.LPCB.TPM)
    {
        Name (_HID, EisaId ("PNP0C31"))
        Name (_CID, EisaId ("PNP0C31"))
        Name (_STR, Unicode ("TPM 1.2 Device"))
        Name (_CRS, ResourceTemplate ()
        {
            Memory32Fixed (ReadOnly,
                0xFED40000,         // Address Base
                0x00005000,         // Address Length
                )
        })

Does your TPM_ device look similar?

That PNP0C31 can be matched in the TPM driver instead of trusting some
random device names that might change from vendor to vendor.

Re: ACPI errors from TPM PPI

[Matthew Garrett]

On Sat, Jul 06, 2013 at 02:10:25PM +0300, Mika Westerberg wrote:

> I wonder whether there is a real PNP Id associated with that device?

You'd really hope so - it's certainly completely bogus to rely on the 
device name. On the other hand, this is basically re-probing for a 
device that the kernel already knows about. Just exporting the device 
from tpm_tis would make more sense.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ACPI errors from TPM PPI

[Mika Westerberg]

On Mon, Jul 08, 2013 at 05:13:01PM +0100, Matthew Garrett wrote:
> On Sat, Jul 06, 2013 at 02:10:25PM +0300, Mika Westerberg wrote:
> 
> > I wonder whether there is a real PNP Id associated with that device?
> 
> You'd really hope so - it's certainly completely bogus to rely on the 
> device name. On the other hand, this is basically re-probing for a 
> device that the kernel already knows about. Just exporting the device 
> from tpm_tis would make more sense.

Indeed, you are right. I didn't even check whether there already exists a
driver for that.