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: <CSTW066CTZ5M.2JR61D32CFSZL@suppilovahvero>
Date:   Tue, 23 May 2023 22:00:10 +0300
From:   "Jarkko Sakkinen" <jarkko@...nel.org>
To:     "Jarkko Sakkinen" <jarkko@...nel.org>,
        "Lino Sanfilippo" <LinoSanfilippo@....de>, <peterhuewe@....de>,
        <jgg@...pe.ca>
Cc:     <jsnitsel@...hat.com>, <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 Tue May 23, 2023 at 9:53 PM EEST, Jarkko Sakkinen wrote:
> On Mon May 22, 2023 at 5:31 PM EEST, Lino Sanfilippo wrote:
> > From: Lino Sanfilippo <l.sanfilippo@...bus.com>
> >
> > Commit e644b2f498d2 ("tpm, tpm_tis: Enable interrupt test") enabled
> > interrupts instead of polling on all capable TPMs. Unfortunately, on some
> > products the interrupt line is either never asserted or never deasserted.
> >
> > The former causes interrupt timeouts and is detected by
> > tpm_tis_core_init(). The latter results in interrupt storms.
> >
> > Recent reports concern the Lenovo ThinkStation P360 Tiny, Lenovo ThinkPad
> > L490 and Inspur NF5180M6:
> >
> > https://lore.kernel.org/linux-integrity/20230511005403.24689-1-jsnitsel@redhat.com/
> > https://lore.kernel.org/linux-integrity/d80b180a569a9f068d3a2614f062cfa3a78af5a6.camel@kernel.org/
> >
> > The current approach to avoid those storms is to disable interrupts by
> > adding a DMI quirk for the concerned device.
> >
> > However this is a maintenance burden in the long run, so use a generic
> > approach:
>
> I'm trying to comprehend how you evaluate, how big maintenance burden
> this would be. Adding even a few dozen table entries is not a
> maintenance burden.
>
> On the other hand any new functionality is objectively a maintanance
> burden of some measure (applies to any functionality). So how do we know
> that taking this change is less of a maintenance burden than just add
> new table entries, as they come up?

I feel also a bit resistant because leaf driver framework is really
a wrong location in the kernel tree for IRQ storm detection.

It would be better to have it signaled above the TPM driver, and the
driver would then just act on it.

BR, Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ