linux-kernel - Re: Enabling interrupts in QEMU TPM TIS

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: <5b3267b7-57d5-badf-6664-9d47bc9909e7@linux.ibm.com>
Date:   Thu, 25 Jun 2020 18:48:09 -0400
From:   Stefan Berger <stefanb@...ux.ibm.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     Jerry Snitselaar <jsnitsel@...hat.com>,
        linux-integrity <linux-integrity@...r.kernel.org>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Enabling interrupts in QEMU TPM TIS

On 6/25/20 5:26 PM, Stefan Berger wrote:
> On 6/25/20 1:28 PM, Jason Gunthorpe wrote:
>> On Thu, Jun 25, 2020 at 10:56:43AM -0400, Stefan Berger wrote:
>>> Hello!
>>>
>>>   I want to enable IRQs now in QEMU's TPM TIS device model and I 
>>> need to work
>>> with the following patch to Linux TIS. I am wondering whether the 
>>> changes
>>> there look reasonable to you? Windows works with the QEMU modifications
>>> as-is, so maybe it's a bug in the TIS code (which I had not run into
>>> before).
>>>
>>>
>>> The point of the loop I need to introduce in the interrupt handler 
>>> is that
>>> while the interrupt handler is running another interrupt may 
>>> occur/be posted
>>> that then does NOT cause the interrupt handler to be invoked again but
>>> causes a stall, unless the loop is there.
>> That seems like a qemu bug, TPM interrupts are supposed to be level
>> interrupts, not edge.
>
>
> Following this document here the hardware may choose to support 
> different types of interrutps:
>
> https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p04_r0p37_pub-1.pdf 
>
>
> Table 23. Edge falling or rising, level low or level high.
>
> So with different steps in the driver causing different types of 
> interrupts, we may get into such situations where we process some 
> interrupt 'reasons' but then another one gets posted, I guess due to 
> parallel processing.


Another data point: I had the TIS driver working on IRQ 5 (festeoi) 
without the introduction of this loop. There are additional bits being 
set while the interrupt handler is running, but the handler deals with 
them in the next invocation. On IRQ 13 (edge), it does need the loop 
since the next interrupt handler invocation is not happening. That IRQ 
13 is an edge interrupt, is this a hard-configured PC 'thing'? Windows 
drove this to IRQ 13, which seemed to be the only one accepted by it and 
iirc it wouldn't even touch the TIS (found via tracing) if another IRQ 
than 13 was declared in the ACPI table.


>
>   Stefan
>
>