[HN Gopher] Uniting the Linux random-number devices (2022)
___________________________________________________________________
Uniting the Linux random-number devices (2022)
Author : PaulHoule
Score : 71 points
Date : 2023-12-20 16:53 UTC (6 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| soundarana wrote:
| Does Linux use the RNG inside Intel/AMD CPUs?
| goalieca wrote:
| The RDRAND instruction usage is configurable
| https://github.com/torvalds/linux/blob/master/Documentation/...
|
| edit:
| https://github.com/torvalds/linux/blob/55cb5f43689d7a9ea5bf3...
| oittaa wrote:
| If I remember correctly, the TLDR is that RDRAND output is
| mixed with other "standard" entropy sources and basically
| making getrandom() non-blocking immediately.
| binkHN wrote:
| This is from 2022.
| davikr wrote:
| > 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?
| phone8675309 wrote:
| 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?
| dspillett wrote:
| _> The 32-bit x86 architecture is nearly 40 years old -
| should it be retired for being too old?_
|
| Parts of it already are, from a Linux point of view anyway.
| It looks like the mainline kernel will drop support for 486
| family chips after 6.x, and support for the 386 was dropped
| in 3.8 (back in 2012).
|
| Some distributions already don't release a version for
| 32-bit-only intel/amd architectures. It'll be a long time
| before x86 support is dropped in its entirety, but even today
| you already have less choice than if you run something not
| sporting an amd64 or arm compatible architecture.
| jorvi wrote:
| > The 32-bit x86 architecture is nearly 40 years old - should
| it be retired for being too old?
|
| I'm sure there is some way to gather architectural usage
| numbers + their likelihood of upgrading, roll it into a
| value, and if that value drops below X, that architecture
| gets left behind.
|
| The reason why I mention likelihood of upgrade is that there
| is a gigantic amount of MIPS routers running Linux, but
| virtually all of them are stuck on old kernels and very
| unlikely to be upgraded. I'm sure other architectures have
| similar snags.
| pavon wrote:
| Yeah, it doesn't make sense to talk about the m68k being a
| 1979 processor, when Motorola continued to develop it and
| release new chips all through the 80's, and it continued to
| be used in new Mac and Next computers up through the early
| 90's. The 80486 would be its peer as far as obsolescence
| goes, not the 8086. But like others mentioned even the i486
| is about to lose Linux support.
| LanzVonL wrote:
| Why shouldn't people expect Linux to run on ancient computers?
| I guess this is why we have NetBSD.
| rollcat wrote:
| Mac/PPC user here. The right thing to do is to support the
| 99% use case best you can, and leave dealing with the quirks
| of ancient garbage^W^W these wonderful machines of times past
| to the enthusiasts.
|
| If you want to e.g. make use of modern crypto, the slow CPU
| is a far bigger issue than sourcing the random numbers.
| Palomides wrote:
| 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
| rdtsc wrote:
| 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.
| influx wrote:
| Thanks for this, I'd been going off the previous articles on
| this, and hadn't realized it had been reverted.
| rdtsc wrote:
| No problem. Thanks for finding and posting the article! The
| change was a good idea but like things happen, corner cases
| intervened.
| Denvercoder9 wrote:
| 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...
| davidw wrote:
| I'm imagining Kramer, Linux developer: "Jerry... what if we
| randomly used a different random device each time?!"
| bee_rider wrote:
| Picked at random? But who's picking the picking algorithm?!?
| dataflow wrote:
| > Picked at random? But who's picking the picking
| algorithm?!?
|
| To give a serious response to this: you can combine the
| outputs of all of them to pick one of them.
| EdSchouten wrote:
| 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.
| kurikuri wrote:
| 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.
| 1000thVisitor wrote:
| > quiet preloading of an attacker-selected state while the
| machine is off.
|
| That attacker with physical access can chose from multiple
| other attacks, so why bother making this one more secure.
| They can sniff keyboard strokes, install malware into the
| UEFI, etc. pp.
| dataflow wrote:
| 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 booting here?
___________________________________________________________________
(page generated 2023-12-20 23:00 UTC)