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] [day] [month] [year] [list]

Message-ID: <Yw+L4JT1yuXnbIbI@zx2c4.com>
Date:   Wed, 31 Aug 2022 12:27:12 -0400
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     linux-kernel@...r.kernel.org, tglx@...utronix.de
Subject: Re: [PATCH] random: use raw spinlocks for use on RT

On Tue, Aug 30, 2022 at 08:57:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2022-08-30 11:24:33 [-0400], Jason A. Donenfeld wrote:
> > Hi Sebastian,
> Hi Jason,
> 
> > On Tue, Aug 30, 2022 at 12:13:44PM +0200, Sebastian Andrzej Siewior wrote:
> > > The first patch did so yes. The second simply retried in two secs and
> > > this shouldn't be problematic.
> > 
> > This seemed pretty bad too, because now you potentially miss up to 2
> > seconds of messages AND it adds more complexity.
> 
> It is early at boot and it could be reduced to one if it helps. I
> remember you had a suggestion where we would lose always the first print
> out on RT you said it is okay since you can't rely on that…

I mean, the mechanism now is simple and doesn't fail. What you're
suggesting is more complex and fails sometimes. So,

> > I'm fine with changing things up to accommodate RT, but not when the
> > result is so obviously worse than before.
> 
> I don't think it is worse. This is your opinion and I did not hear any
> other feedback so far.

so, I think it's beyond a matter of opinion and is actually objectively
worse.

And it's not like I even care particularly much about vnsprintf; as I
said before, none of this really matters _that_ much. But I *do* very
much object to dirtying up random bits of code and making things
actually worse in the name of RT, especially when there are other
solutions being considered. Namely:

> > In my tests I can't see any latency difference with using raw spinlocks
> > in random.c. Maybe I'm doing things wrong? But I'm not seeing anything
> > change...
> 
> You need to look at the maximum latency that may happen. Also the other
> thing is that there is no need to add raw_spinlock_t locking if it can
> be avoided.

I really am having trouble fashioning a test that shows a higher maximum
latency. All the RNG critical sections are really short in the end. So I
dunno... seems like not a big deal to me. If you're seeing different
numbers, can you post them and how you came up with them? If I can
reproduce it, maybe it's possible for me to do something about that
latency. But so far I'm not seeing any latency spike...

Jason