Linux 4.19 lets you declare your trust in AMD, IBM and Intel

Linux v4.19-rc1, release candidate code published on Sunday, allows those building their own kernel or Linux distribution to choose whether or not to trust the CPU hardware random number generator, a decision that has become complicated in the wake of the revelations about government surveillance over the past five years. When …

[MacroRodent]

This is actually useful

I have seen a problem where the start of a bunch of VMs got delayed too much because a program that was part of the VM startup wanted randomness, and it took too long to "collect" it.

[Tomato42]

Re: This is actually useful

VMs should trust the entropy from the hypervisor, and by the time the hypervisor can run, the host will definitely have enough enropy

so it looks like the VMs lacked virtio-rng (or equivalent)

[Ian Michael Gumby]

Re: This is actually useful

No, not really that useful.

At issue is that for most tasks the regular random number generator is random enough.

For tasks that require a better random number generator, they will use alternative that are already available.

So sure it moves the issue to vendor, (e.g. RH, SuSE, etc ...) but it really is attempting to solve a problem that is solved thru other means. I guess you could say it reduces the burden on the other apps to supply their own random number generator. Thats about it...

The alien because one of the best sources for entropy (randomness) comes from listening to background radiation/noise from space...

[Anonymous Coward]

Re: This is actually useful

@Ian Micheal Gumby

This feature is clearly offered as a quick fix until those components using security based upon dodgy RNG are made secure and to highlight that PC security is a joke.

It really is a question of who do you trust

[tony trolle]

Re: This is actually useful

and there's me thinking some distros were crap.lol.some are

[Richard 12]

Been bitten by this many times

Many embedded systems don't need crypto-grade entropy, because they only use it to create UUIDs.

Being able to flip a flag to say "I know it's probably untrustworthy but it's better to boot fast" is useful.

[David Roberts]

Request to disable the flag?

You have a Yes/No decision at kernel build time. Why would you want to disable it?

Unless this is envisaged as a user switch, and Daddy wants to say "slow and secure is the only option".

[Jon 37]

Re: Request to disable the flag?

> You have a Yes/No decision at kernel build time.

Only if you build your own kernel.

> Why would you want to disable it?

Because you are using a kernel provided by a Linux distro, not compiling your own. In this case, the distro may want to choose a default value for this flag, but the user may want to change the flag.

There are usually good reasons for using a distro rather than building your own Linux distro from scratch: it's a lot less hassle, it gives you software binaries that have been tested, and it makes it easy to get security patches. All those arguments apply to the kernel as much as the rest of the software in the distro. Of course, there are times when people have specific non-standard requirements, and have to compile a kernel themselves, but those are rare.

And yes, most of the people reading this thread are likely part of the rare group with non-standard requirements, but that's because this is a thread about a kernel patch on a tech news website...

[Doctor Syntax]

Re: Request to disable the flag?

I'd have thought the obvious solution would be a boot-time argument unless the entropy collection happens before the arguments are read.

[Creslin]

For a system that requires no encryption - why wait on boot

its akin to starting a service to disable it after.

yes encryption is good

no - not every system has a need for it - my media server as example.

[Charles 9]

Re: For a system that requires no encryption - why wait on boot

"no - not every system has a need for it - my media server as example."

What makes you think a malcontent can't usurp your media server and use it as a springboard to other parts of your network...or even as part of a botnet to attack the greater Internet (in which case it doesn't matter if it has secrets or not, just oomph and access).

[cosine]

Re: For a system that requires no encryption - why wait on boot

What if you want enterprise-grade shuffle-play?

[Def]

Linux 4.19?

The Nigerian Prince edition?

[Robert Carnegie]

Re: Linux 4.19?

Currently it's The Nigerian Candidate.

That is, Release Candidate.

After all, the wealthy Nigerian - usually based in Amsterdam for some reason, the last that I heard - is just a new version of "The Spanish Prisoner".

[JohnFen]

People trust that?

Maybe I'm too old-school, but I have long been taught that if you're doing crypto, you shouldn't be using the CPU's RNG. You want (or need, depending on project requirements) an RNG that is certified for that use. Did that stop being considered best practice?

[Charles 9]

Re: People trust that?

Because if you can't trust the CPU's RNG, you can't trust ANY RNG. There's no telling where it's been, certification or no, plus the CPU or mobo can undo any effort you make by tampering with the communications channels. The main reason you want a hardware RNG is because you need a high-throughput TRNG, such as running a key-generating server.

As for trusting the CPU's RNG, this is usually mitigated by employing multiple entropy sources so that the worst case is that a bad source adds no entropy. AFAIK, there's no practical way for the CPU to know enough about any alternate sources to actually negate entropy.

There's one place where the CPU and ONLY the CPU can be used: bootstrap. At that point, no other buses are open, including those you'd need to access another RNG. How does one propose to secure the bootstrap procedure without access to any other RNG?

[JohnFen]

Re: People trust that?

"Because if you can't trust the CPU's RNG, you can't trust ANY RNG."

I don't follow that logic. Can you explain?

"The main reason you want a hardware RNG is because you need a high-throughput TRNG, such as running a key-generating server."

Absolutely. I wasn't arguing against hardware RNGs. I was talking about the RNGs that are included in some CPUs.

"How does one propose to secure the bootstrap procedure without access to any other RNG?"

There are a few ways to do this, depending on the CPU in question, but that's a discussion that can't be effectively had in a comment section. But I wasn't addressing securing the bootstrap procedure, I was really talking about using it for crypto in the more general case. If you're stuck with the CPU RNG for boot-time, then that's what you use. But that doesn't mean you should keep using it for crypto after the boot process completes.

[eldakka]

Re: People trust that?

"Because if you can't trust the CPU's RNG, you can't trust ANY RNG."

I don't follow that logic. Can you explain?

Because any other source of RNG would have to be accessed via a communications interface in the same computer that has a compromised CPU RNG. The PCIe, USB, thunderbolt, serial, parallel, PS/2, or any other communications interface is controlled by the same source as the CPU. Therefore if the manufacturer of the CPU is going to compromise the CPU's RNG, they are full capable of intercepting, and modifying, any other data traffic in in the computer.

That hardware RNG you plugged into the USB port? Pity the number being used in the encryption software running on the CPU isn't the one from that USB attached RNG, as the CPU substituted the RNG from the USB port with its own dodgy RNG.

[Tomato42]

Re: People trust that?

@aldakka: purely in theory, yes

but there are quite a few people that de-lid and de-cap Intel CPUs to look what they actually do on the silicon level, then there's the thing of CPU having very well defined outputs for given inputs, again, something that quite a few people verify before using the CPU in question

and then we have the RNG, circuit that *by design* produces inscrutable and unpredictable outputs for all inputs. Does it do that by encrypting a counter with AES and a key a TLA knows? or does it do that by getting the data from some quantum process? can't really tell (and believe me, people have looked at it, there are plenty of papers on the topic)

so while, yes, one single person can't be certain that the CPU doesn't switch completely predictable bytes in place where the USB provided random bytes should be, as a community we can be reasonably sure it doesn't do that; can't say the same of the built-in RNG

[Charles 9]

Re: People trust that?

"so while, yes, one single person can't be certain that the CPU doesn't switch completely predictable bytes in place where the USB provided random bytes should be, as a community we can be reasonably sure it doesn't do that; can't say the same of the built-in RNG"

HOW? Particularly against something of state-level resources like a TLA? If they can hide corrupt RNGs in a CPU beyond the ability to detect even via things like x-rays, can't the same technique be used to corrupt any other I/O stream? After all, things like heartbleed and shellshock got past "the community" for a long time, too. For all we know, something like this has been a black project since before it was even a concern to us.

[Tomato42]

Re: People trust that?

"If they can hide corrupt RNGs in a CPU beyond the ability to detect even via things like x-rays, can't the same technique be used to corrupt any other I/O stream?"

because to turn an RNG to a biased one requires changing the amount of doping in a single transistor (oh, and that counter mode for AES? that's what the Intel design document says how its RNG works; which means there is very little that needs to change to make the counter or the key predictable (and thus RNG's output) to certain people and still completely unpredictable to me and you)

detecting when the USB dongle connected is a custom RNG or just a RS232 bridge or a LHC muon detector requires likely hundreds of transistors or hundreds of cycles

and sure, it's technically possible for a TLA to create such a CPU and plant it in your computer, but if they are interested in you to this degree, the RNG of Intel CPU would be the last thing on my mind

I don't know why you bring shellshock – it was a documented feature with unintended consequences. Regarding heartbleed – because we know that the RNG is the important part, we know that Intel sometimes screws up implementation (fdiv bug for most well known example) and people are specifically looking for problems in it. Nobody was looking for bugs in heartbeat implementation before heartbleed.

[Anonymous Coward]

Re: People trust that?

You could always map the RNG within RAM during bootstrap, there are in reality no limitations if you actually want a secure RNG but until recently people just trusted their CPU manufacturer and now they are a bit wiser.

[Anonymous Coward]

Re: People trust that?

Memory mapping, like any external mapping, can be usurped. Goes to the old saying that if you want something done right, you can only do it yourself.

[Kev99]

Pardon my ignorance, but why is there even a random number generator in a cpu's microcode? It would make more sense to me for OS or better yet the security software to have an RNG. This could tend to make it more difficult for unwanteds to gain access to the device.

[JohnFen]

"why is there even a random number generator in a cpu's microcode?"

Convenience. It's cheaper and easier to have it there than to have to include RNG hardware externally.

"It would make more sense to me for OS or better yet the security software to have an RNG."

Software cannot produce random numbers, only pseudorandom numbers. In practice, with the proper pRNG algorithm, that can be good enough -- but you still want at least one actual random number to seed the pRNG.

"This could tend to make it more difficult for unwanteds to gain access to the device."

That would make it easier, really.

[Glen Turner 666]

Why CPU rng

A few reasons:

1) The CPU's random number generator can be random, based upon provably random phenomena rather than a pseudo-random number based upon mathematical manipulation.

2) There are some sources of actually-random data in a computer, although they are usually not the same strength as "provably random". An example is the jitter from disk drive events. But these sources are rapidly disappearing as physical devices towards silicon. This is the operational problem with not enough 'entropy' (aka real randomness) being available as a machine starts.

3) It's "too easy" for these actually-random sources of data in a computer to be influenced from outside the computer. Since they are not built as cryptographic devices. Whereas the random instructions within the CPU can include tamper detectors (such as for high EM fields).

4) Timing and other covert channel attacks are simpler against software than against hardware. Those attacks are also simpler against hardware not intended to be cryptographic devices than against hardware designed with covert channels in mind. It is easier in hardware to build a black box where all instances of the instruction take the same time to complete, use the same power, and so on. (As an aside the current issue with CPUs is that the care of design needed to defeat covert channels done for the RDRAND instruction needs to be repeated throughout the CPU design for other instructions.)

These reasons explain the last line of Ted's LKML e-mail: "Note: I trust [Intel's hardware instruction] RDRAND more than I do Jitter Entropy [from the computer's hardware devices]".

[Charles 9]

Re: Why CPU rng

"(As an aside the current issue with CPUs is that the care of design needed to defeat covert channels done for the RDRAND instruction needs to be repeated throughout the CPU design for other instructions.)"

Well, one problem with that approach is that these CPUs are more often being put into portable applications where power isn't a given. In which case efficiency trumps security unless you can achieve both (which last I checked, you can't; efficiency inevitably leaves tells).

[John Doe 6]

I remember seeing a sign in a bar...

"In God we trust, everyone else pays cash!"