linux-kernel - Re: [PATCH] random: use raw spinlocks for use on RT

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:   Thu, 11 Aug 2022 02:17:31 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] random: use raw spinlocks for use on RT

Hey Sebastian,

On Mon, Aug 01, 2022 at 04:34:13PM +0200, Sebastian Andrzej Siewior wrote:
> On 2022-08-01 16:25:31 [+0200], Jason A. Donenfeld wrote:
> > After handling several bug reports using various creative solutions,
> > it's becoming clear that random bytes are actually a useful thing to
> > happen from any ordinary context, including when interruptsare off.
> > Actually, that's been long recognized, which is why the RNG uses
> > spinlocks rather than mutexes. But on RT, those spinlocks are getting
> > converted back into sleeping locks.
> > 
> > This clearly is causing more problems than it might hypothetically
> > solve. Additionally, the locks in random.c are generally for fixed
> > durations doing CPU-bound operations -- no waiting for hardware or I/O
> > or the like. So this shouldn't result in a real harm to latency.
> > 
> > Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> > Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
> > ---
> > Sebastian - I won't move forward with this without your Ack, obviously.
> > What do you think of this general approach? -Jason
> 
> I would need to do worst-case measurements and I've been looking at this
> just before writting the other email and there was a local_lock_t
> somewhere which needs also change…

Did you ever come up some measurements here? It sure would be nice if I
could apply this, but obviously that's contingent on you saying it's
okay latency-wise on RT.

Jason