[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9486573.CV9Qe9s7RZ@positron.chronox.de>
Date: Sun, 17 Nov 2019 11:30:13 +0100
From: Stephan Müller <smueller@...onox.de>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-crypto@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
linux-api@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Alexander E. Patrakov" <patrakov@...il.com>,
"Ahmed S. Darwish" <darwish.07@...il.com>,
"Theodore Y. Ts'o" <tytso@....edu>, Willy Tarreau <w@....eu>,
Matthew Garrett <mjg59@...f.ucam.org>,
Vito Caputo <vcaputo@...garu.com>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
William Jon McCann <mccann@....edu>,
zhangjs <zachary@...shancloud.com>,
Andy Lutomirski <luto@...nel.org>,
Florian Weimer <fweimer@...hat.com>,
Lennart Poettering <mzxreary@...inter.de>,
Nicolai Stange <nstange@...e.de>,
"Peter, Matthias" <matthias.peter@....bund.de>,
Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
Roman Drahtmueller <draht@...altsekun.de>,
Neil Horman <nhorman@...hat.com>
Subject: Re: [PATCH v25 01/12] Linux Random Number Generator
Am Samstag, 16. November 2019, 12:25:21 CET schrieb Thomas Gleixner:
Hi Thomas,
> On Sat, 16 Nov 2019, Stephan Müller wrote:
> > +/**
> > + * Hot code path - Callback for interrupt handler
> > + */
> > +void add_interrupt_randomness(int irq, int irq_flags)
> > +{
> > + lrng_time_process();
> > +
> > + if (!lrng_pool_highres_timer()) {
> > + struct pt_regs *regs = get_irq_regs();
> > + static atomic_t reg_idx = ATOMIC_INIT(0);
> > + u64 ip;
> > +
> > + lrng_pool_lfsr_u32(jiffies);
> > + lrng_pool_lfsr_u32(irq);
> > + lrng_pool_lfsr_u32(irq_flags);
> > +
> > + if (regs) {
> > + u32 *ptr = (u32 *)regs;
> > + int reg_ptr = atomic_add_return_relaxed(1, ®_idx);
> > + size_t n = (sizeof(struct pt_regs) / sizeof(u32));
> > +
> > + ip = instruction_pointer(regs);
> > + lrng_pool_lfsr_u32(*(ptr + (reg_ptr % n)));
> > + } else
> > + ip = _RET_IP_;
> > +
> > + lrng_pool_lfsr_u32(ip >> 32);
> > + lrng_pool_lfsr_u32(ip);
> > + }
>
> Is there a way to avoid all that processing right in the interrupt hot
> path and just store the raw data for later processing?
The main code path is lrng_time_process(). This code is streamlined as you
already suggested: it is very lightweight to the interrupt handler. Compared
to the existing /dev/random implementation it is about 50% faster.
When measuring the lrng_time_process, it takes on one particular test system
on average about 65 cycles where on that very same system the
add_interrupt_randomness code path from the existing /dev/random takes on
average about 97 cycles.
The additional code you see in the add_interrupt_randomness is only executed
if lrng_pool_highres_timer is not set. This is not set if the LRNG does not
find a high-resolution time stamp, i.e. random_get_entropy() returns 0. As on
most architectures this is now set, this code path is not executed.
This additional code path serves as an emergency code to collect some data
that smells random and having entropy but not having really much.
It may be a bit more stremlined but since it is hardly used, I left it as it
is so far. Do you see the need to streamline it more at this time?
Thanks a lot.
Ciao
Stephan
Powered by blists - more mailing lists