[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9rieCnqNp=n2jOp2z+pS8qo59B0ULWBhRjCHM8awRWMPA@mail.gmail.com>
Date: Thu, 10 Feb 2022 18:10:53 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Dominik Brodowski <linux@...inikbrodowski.net>
Cc: LKML <linux-kernel@...r.kernel.org>,
"Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH 2/2] random: deobfuscate irq u32/u64 contributions
On Thu, Feb 10, 2022 at 5:57 PM Dominik Brodowski
<linux@...inikbrodowski.net> wrote:
>
> Am Thu, Feb 10, 2022 at 05:09:25PM +0100 schrieb Jason A. Donenfeld:
> > In the irq handler, we fill out 16 bytes differently on 32-bit and
> > 64-bit platforms. Whether or not you like that, it is a matter of fact.
> > But it might not be a fact you well realized until now, because the code
> > that loaded the irq info into 4 32-bit words was quite confusing.
> > Instead, this commit makes everything explicit by having separate
> > (compile-time) branches for 32-bit and 64-bit machines. In the process,
> > it exposed a shortcoming in in mix_interrupt_randomness() which we
>
> "in in" -> "in"
>
> > rectify.
>
> Maybe explain the shortcoming in one sentence? I think I spotted it, but...
Will do. v2 incoming.
Powered by blists - more mailing lists