linux-kernel - Re: [PATCH 1/2] tpm, tpm_tis: Handle interrupt storm

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]

Date:   Tue, 23 May 2023 12:41:24 +0200
From:   Lino Sanfilippo <l.sanfilippo@...bus.com>
To:     Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
        Lukas Wunner <lukas@...ner.de>
Cc:     Lino Sanfilippo <LinoSanfilippo@....de>, peterhuewe@....de,
        jarkko@...nel.org, jgg@...pe.ca, jsnitsel@...hat.com,
        hdegoede@...hat.com, oe-lkp@...ts.linux.dev, lkp@...el.com,
        peterz@...radead.org, linux@...ewoehner.de,
        linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
        p.rosenberger@...bus.com
Subject: Re: [PATCH 1/2] tpm, tpm_tis: Handle interrupt storm

Hi,

On 23.05.23 11:14, Péter Ujfalusi wrote:

>>
>>>>     rc = tpm_tis_write32(priv, TPM_INT_STATUS(priv->locality), interrupt);
>>>>     tpm_tis_relinquish_locality(chip, 0);
>>>>     if (rc < 0)
>>>> -           return IRQ_NONE;
>>>> +           goto unhandled;
>>>
>>> This is more like an error than just unhandled IRQ. Yes, it was ignored,
>>> probably because it is common?
>>
>> The interrupt may be shared and then it's not an error.
> 
> but this is tpm_tis_write32() failing, no? If it is shared interrupt and
> we return IRQ_HANDLED unconditionally then I think the core will think
> that the interrupt was for this device and it was handled.
> 

At this point we already know the interrupt was for our device. Otherwise we would
have already bailed out at

	if (interrupt == 0)
	

Regards,
Lino



> --
> Péter