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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 24 May 2023 04:21:01 +0300
From:   "Jarkko Sakkinen" <jarkko@...nel.org>
To:     "Jerry Snitselaar" <jsnitsel@...hat.com>
Cc:     "Lino Sanfilippo" <LinoSanfilippo@....de>, <peterhuewe@....de>,
        <jgg@...pe.ca>, <hdegoede@...hat.com>, <oe-lkp@...ts.linux.dev>,
        <lkp@...el.com>, <peter.ujfalusi@...ux.intel.com>,
        <peterz@...radead.org>, <linux@...ewoehner.de>,
        <linux-integrity@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <l.sanfilippo@...bus.com>, <lukas@...ner.de>,
        <p.rosenberger@...bus.com>
Subject: Re: [PATCH 1/2] tpm, tpm_tis: Handle interrupt storm

On Wed May 24, 2023 at 1:32 AM EEST, Jerry Snitselaar wrote:
> I do worry about how many cases will be reported once 6.4 is released,
> and this eventually makes its way into distributions. In either case
> the dmi table will need to be maintained. The UPX-11i case is a
> different issue, and IIRC the L490 it needed a DMI entry, because
> trying to catch the irq storm wasn't solving the issue there. I
> imagine other odd cases will be popping up as well.
>
> So far we have 2 irq storm reports with peterz's P360 Tiny, and I
> guess that Inspur system reported by the kernel test robot. Then there
> is whatever is going on with Peter Ujfalusi's UPX-11i.

Yeah, I agree that we need both in order to reach stability.

> > Out of top of my head you could e.g. window average the duration between
> > IRQs. When the average goes beyond threshold, then you shutdown
> > interrupts.
>
> Just to make sure I have it clear in my head, you mean when the
> average is shorter than the threshold duration between interrupts,
> yes? My brain wants to read 'When the average goes beyond threshold'
> as 'threshold < average'.
>
> Does the check need to be a rolling window like 1/2 currently has? I
> expect that if the problem exists it will be noticed in the first
> window checked. I think what I originally tried was to check over some
> interval from when the handler first ran, disable interrupts if
> needed, and then skip the check from then on when the handler ran.

How about just: average' = (average / (then - now)) /2

And if average' > thershold, disable interrupts.

BR, Jarkko