Uniting the Linux random-number devices (2022)

[rdtsc]

The commit [1] was eventually reverted [2]

[1] https://github.com/torvalds/linux/commit/6f98a4bfee72c22f50a... [2] https://github.com/torvalds/linux/commit/0313bc278dac7cd9ce8...

> "This causes a large number of qemu boot test failures for various architectures (arm, m68k, microblaze, sparc32, xtensa are the ones I observed). Common denominator is that boot hangs at 'Saving random seed:'" This isn't hugely unexpected - we tried it, it failed, so now we'll revert it.

[Denvercoder9]

A bit later another commit [1] was merged that makes reads from /dev/urandom opportunistically initialize the RNG. In practice this has the same result as the reverted commit on non-obsolete architectures, which support the jitter entropy generation.

[1] https://github.com/torvalds/linux/commit/48bff1053c172e6c7f3...

[minedwiz]

`rdtsc`, you have a very appropriate username for the topic

[influx]

Thanks for this, I'd been going off the previous articles on this, and hadn't realized it had been reverted.

[davikr]

> The jitter entropy technique relies on differences in timing when running the same code, which requires both a high-resolution CPU cycle counter and a CPU that appears to be nondeterministic (due to caching, instruction reordering, speculation, and so on). There are some architectures that do not provide that, however, so no entropy can be gathered that way. Donenfeld noted that non-Amiga m68k systems, two MIPS models (R6000 and R6000A), and, possibly, RISC-V would be affected;

So, I understand not wanting to break RISC-V support, but _should_ people really care about breaking compatibility with early 1990s MIPS chips and a 1979 Motorola CPU?

[snvzz]

In reality, there's no reason there cannot be two implementations, with the correct one automatically selected on build according to architecture.

[jasonwatkinspdx]

m68k variants were quite popular in the embedded world until fairly recently.

[LanzVonL]

Why shouldn't people expect Linux to run on ancient computers? I guess this is why we have NetBSD.

[Palomides]

there are almost certainly new-ish low end ARM chips this would hit as well, it's not really about the specific examples

declaration of bias: I have a non-Amiga m68k that can run linux

[phone[phone]]

Clearly Linus and the maintainers of those architectures care enough not to break them (and those architecture maintainers have enough clout to be taken seriously).

How old does a CPU need to be in order to no longer be supported? The 32-bit x86 architecture is nearly 40 years old - should it be retired for being too old?

[dmitrygr]

> So, I understand not wanting to break RISC-V support, but _should_ people really care about breaking compatibility with early 1990s MIPS chips and a 1979 Motorola CPU?

Yes, we care a lot more than about the 2020 MIPS incarnation (you young kids call it RISCV, fooling nobody)

[davidw]

I'm imagining Kramer, Linux developer: "Jerry... what if we randomly used a different random device each time?!"

[bee_rider]

Picked at random? But who’s picking the picking algorithm?!?

[dataflow]

What did Windows and Mac do a decade or two ago? What do they do now? Why do I only ever see Linux struggling with random numbers and booting here?

[LtWorf]

They solve it by not supporting 99% of the hardware that linux supports.

[EdSchouten]

Even though not all architectures have an RTC or strong PRNG instructions, almost all of them have writable storage in the form of NVRAM/NAND/disk.

Why can’t they just patch up the kernel to persist PRNG state there and require that the boot loader recovers it upon reboot? The kernel would then have high quality random data available as soon as it gets launched.

[dist-epoch]

Windows does that, persists a seed in the registry, but it's not enough.

Imagine a virtual machine snapshot that you start multiple times. The separate runs would have the exact same persisted state.

[kurikuri]

The PRNG state is responsible for generating most of the users cryptographic material and is quite important to the system’s security. As such, the PRNG State is a security parameter that should never be exportable nor importable.

There are many new attacks that could surface if import/export were possible; off the top of my head: quiet preloading of an attacker-selected state while the machine is off.

[soundarana]

Does Linux use the RNG inside Intel/AMD CPUs?

[goalieca]

The RDRAND instruction usage is configurable https://github.com/torvalds/linux/blob/master/Documentation/...

edit: https://github.com/torvalds/linux/blob/55cb5f43689d7a9ea5bf3...

[binkHN]

This is from 2022.