linux-kernel - Re: 2.6.23-rc1-mm1 - seems OK on Dell Latitude D820, except for tpm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200707271643.14028.bjorn.helgaas@hp.com>
Date:	Fri, 27 Jul 2007 16:43:13 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Valdis.Kletnieks@...edu
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Kylene Hall <kjhall@...ibm.com>, tpm@...horst.net,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.23-rc1-mm1 - seems OK on Dell Latitude D820, except for tpm_tis

On Friday 27 July 2007 07:28:09 am Valdis.Kletnieks@...edu wrote:
> Looks like the problematic code is in tpm_tis.c tpm_tis_init() near here:
> 
>                 for (i = 3; i < 16 && chip->vendor.irq == 0; i++) {
>                         iowrite8(i, chip->vendor.iobase +
>                                     TPM_INT_VECTOR(chip->vendor.locality));
>                         if (request_irq
>                             (i, tis_int_probe, IRQF_SHARED,
>                              chip->vendor.miscdev.name, chip) != 0) {
>                                 dev_info(chip->dev,
>                                          "Unable to request irq: %d for probe\n"
> ,           
>                                          i);
>                                 continue;
>                         }
> 
> This seems to be misbehaving differently for the two different DEBUG_SHIRQ
> cases.
> 
> With DEBUG_SHIRQ=n, it starts at IRQ3, gets to at least 8 (where it complains
> it can't request it for probing), and possibly all the way to 15, without ever
> actually selecting and assigning an IRQ (to refresh memories, in that range
> /proc/interrupts only lists:
> 
>   8:          0          0   IO-APIC-edge      rtc
>   9:          3          0   IO-APIC-fasteoi   acpi
>  12:         94          0   IO-APIC-edge      i8042
>  14:     148166          0   IO-APIC-edge      libata
>  15:         94          0   IO-APIC-edge      libata
> 
> So there's certainly IRQ's available.  No idea why it doesn't choose one. But
> since it never chose one, it never gets into the "wait for the IRQ" protected
> by 'if (chip->vendor.irq)' at the end of tpm_tis_send.
> 
> With DEBUG_SHIRQ=y, It starts at IRQ3, and assigns it (which seems a good thing).
> Unfortunately, this then hits the timeouts in tpm_tis_send.
> 
> Anybody got an idea what *should* be happening here?

I don't know why tpm_tis_init() is messing around trying different
IRQs between 3 and 16.  That looks suspiciously x86-dependent.

Maybe if you don't have PNP (though I doubt TPMs exist on any
pre-PNPBIOS machines) the "check-IRQ" loop would be necessary.

But you're using the PNP probe, and PNP should just tell you what
IRQ the device is configured for (and whether the IRQ can be
shared -- see 8250_pnp.c for an example).

The BIOS should have configured the TPM IRQ, and if we go and
mess with that IRQ setting without going through the PNP interface,
e.g., the ACPI _SRS method, we're liable to mess something up.  The
TPM is often behind a few bridges, and if the bridge has any IRQ
routing configuration, only the BIOS knows how to keep that in
sync with the TPM IRQ configuration.

> Just for the record, I see this in /sys:
> 
> % cat /sys/bus/pnp/devices/00:0e/id
> BCM0102
> PNP0c31

What's in /sys/bus/pnp/devices/00:0e/resources?

Bjorn

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/