linux-kernel - Re: [PATCH] random: make try_to_generate

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Oct 2019 22:25:32 -0400
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jörn Engel <joern@...estorage.com>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] random: make try_to_generate_entropy() more robust

On Fri, Oct 18, 2019 at 4:42 PM Jörn Engel <joern@...estorage.com> wrote:
>
> We can generate entropy on almost any CPU, even if it doesn't provide a
> high-resolution timer for random_get_entropy().  As long as the CPU is
> not idle, it changed the register file every few cycles.  As long as the
> ALU isn't fully synchronized with the timer, the drift between the
> register file and the timer is enough to generate entropy from.

>  static void entropy_timer(struct timer_list *t)
>  {
> +     struct pt_regs *regs = get_irq_regs();
> +
> +     /*
> +      * Even if we don't have a high-resolution timer in our system,
> +      * the register file itself is a high-resolution timer.  It
> +      * isn't monotonic or particularly useful to read the current
> +      * time.  But it changes with every retired instruction, which
> +      * is enough to generate entropy from.
> +      */
> +     mix_pool_bytes(&input_pool, regs, sizeof(*regs));

Ok, so I still like this conceptually, but I'm not entirely sure that
get_irq_regs() works reliably in a timer. It's done from softirq
TIMER_SOFTIRQ context, so not necessarily _in_ an interrupt.

Now, admittedly this code doesn't really need "reliably". The odd
occasional hickup would arguably just add more noise. And I think the
code works fine. get_irq_regs() will return a pointer to the last
interrupt or exception frame on the current CPU, and I guess it's all
fine. But let's bring in Thomas, who was not only active in the
randomness discussion, but might also have stronger opinions on this
get_irq_regs() usage.

Thomas, opinions? Using the register state (while we're doing the
whole entropy load with scheduling etc) looks like a good source of
high-entropy data outside of just the TSC, so it does seem like a very
valid model. But I want to run it past more people first, and Thomas
is the obvious victim^Wchoice.

              Linus