linux-kernel - Re: [PATCH v3] tpm: disable hwrng for fTPM on some AMD designs

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:   Sun, 12 Mar 2023 11:35:57 +0100
From:   "Linux regression tracking (Thorsten Leemhuis)" 
        <regressions@...mhuis.info>
To:     Jarkko Sakkinen <jarkko@...nel.org>,
        Linux regressions mailing list <regressions@...ts.linux.dev>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Huewe <peterhuewe@....de>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        stable@...r.kernel.org,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        reach622@...lcuk.com, Bell <1138267643@...com>,
        "Jason A . Donenfeld" <Jason@...c4.com>,
        linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH v3] tpm: disable hwrng for fTPM on some AMD designs

On 12.03.23 02:35, Jarkko Sakkinen wrote:
> On Fri, Mar 10, 2023 at 06:43:47PM +0100, Thorsten Leemhuis wrote:
>> [adding Linux to the list of recipients]
>>
>> On 08.03.23 10:42, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
>>> for once, to make this easily accessible to everyone.
>>>
>>> Jarkko, thx for reviewing and picking below fix up. Are you planning to
>>> send this to Linus anytime soon, now that the patch was a few days in
>>> next? It would be good to get this 6.1 regression finally fixed, it
>>> already took way longer then the time frame
>>> Documentation/process/handling-regressions.rst outlines for a case like
>>> this. But well, that's how it is sometimes...
>>
>> Linus, would you consider picking this fix up directly from here or from
>> linux-next (8699d5244e37)? It's been in the latter for 9 days now
>> afaics. And the issue seems to bug more than just one or two users, so
>> it IMHO would be good to get this finally resolved.
>>
>> Jarkko didn't reply to my inquiry, guess something else keeps him busy.
> 
> That's a bit arrogant. You emailed only 4 days ago.

My deepest apologies if that "guess something else keeps him busy"
triggered your response, what I wanted to say is "I don't consider the
lack of a response a problem, that's how it is for all of us sometimes".
Sorry, that might not have been the best way to express that.

If my prodding itself was the cause: well, I think that's what I should
do in this case. That stance developed quickly when I started doing
regression tracking, as I noticed one thing:

Image a regression caused by a commit merged for 5.11-rc1 is reported a
day or two after 5.11-rc7 is released. Imagine further a fix is posted
for review two or three days after 5.11-rc8 is out. From what I noticed
quite a few of those fixes (not all of course) make it to mainline in
time for the release of 5.11. But the picture looked totally different
when the fix was posted for review shortly *after* 5.11 was out, as I
noticed quite a few of those were only mainlined 9 or 10 weeks later for
5.13-rc1 (and only then can be backported to 5.11.y and 5.12.y).

[above was just a hypothetical example with the worst timing to
illustrate the core problem, the timelines are different in case of the
fTPM issue]

>From my understanding of things that's not how it should be (unless
there are strong reasons in the individual case). That's why I'm working
against that. Still working on optimizing when/how I ask, as I'm not yet
happy with how I do that.

Don't worry, I use my best judgment in that process; if the fix is
complex and the next merge window is near, I might let it slip – OTOH if
it's something that apparently bugs quite a few people, I prod
developers and maintainers more quickly & often, like I did in this case.

In the end situations like the one outlined above lead me to writing the
section "Prioritize work on fixing regressions" in
Documentation/process/handling-regressions.rst (
https://docs.kernel.org/process/handling-regressions.html ). Greg acked
it; Linus never commented on it, not sure if he looked at it when he
merged that. But I have no idea how developers actually have seen it
and/or take it seriously. But from what I saw it already helped somewhat.

> I'm open to do PR for rc3 with the fix, if it cannot wait to v6.4 pr.

>From later in this thread I see that you plan to do that now, thus:

many thx!

Ciao, Thorsten