Linus Responds To RdRand Petition With Scorn

hypnosec writes "Linus Torvalds, in response to a petition on Change.org to remove RdRand from /dev/random, has lambasted the petitioner by called him ignorant for not understanding the code in the Linux Kernel. Kyle Condon from the UK raised a petition on Change.org to get Linus to remove RdRand from /dev/random in a bid 'to improve the overall security of the linux kernel.' In his response, Torvalds asked Condon and the supporters of the petition to gain an understanding of Linux drivers and cryptography, and then 'come back here and admit to the world that you were wrong.' Torvalds stressed that kernel maintainers knew what they were doing and the petitioner didn't. Torvalds, in a similar outburst just yesterday, hoped that 'ARM SoC hardware designers all die in some incredibly painful accident.' This came in response to a message from Kevin Hilman when he noted that there were quite a few conflicts in the ARM SoC pull request for Linux 3.12 which were a result of the platform changes conflicting with driver changes going in to the V4L tree."

Comments

you have the source

[AndroSyn]

You have the source code, remove rdrand from the kernel yourself.

Re:you have the source

[BitZtream]

Note: I'm not saying it should be changed, just that the "change it yourself" line is ridiculously impractical for even people capable of coding the change properly. And worse for those who can't. Maintaining your own kernel tree over time is most certainly non-trivial by most peoples standards.

Re:you have the source

[AndroSyn]

Then if you don't understand how to make this sort of change, then you aren't smart enough to understand why you should or should not be using RDRAND it in the first place.

Re:you have the source

[Anonymous Coward]

Not when it isn't a bug and the functionality desired is for yourself and not the planet. It's precisely the only response. Try getting Microsoft, IBM, Oracle or Apple to change their kernel to your tastes.

Re:you have the source

[Anonymous Coward]

It's not a "cop out" at all. The party that manages the code doesn't want to remove a feature that there's no logical reason to remove. The petition was one sentence, linked to no debate, made no points and didn't even attempt to negotiate. It could have said, "Do it, because we say so." and it would have been just as informative. I think you need to look up the definition of "cop out", because the petition creators could have actually done something useful, and didn't.

Re:you have the source

[realityimpaired]

Not true... I have no opinion either way, but it's entirely possible to have a very good understanding of how semi-random numbers affect cryptography, and also of how rdrand generates them, without having the programming background to be able to safely remove it from the kernel. Crypto is about math, not programming, and contrary to popular opinion (apparently), the two do not always go hand-in-hand.

It's not as simple as just commenting out a few lines of code. As likely as not, if you were to simply comment out a few lines you'd actually introduce another bug which could be worse for security. The Linux kernel is arcane, and even experienced/good programmers avoid making modifications they don't have to. What you're proposing is he fork it, and make a new release of the kernel *every time Linux releases one*, in order to comment out a feature that may not have enough entropy to be suitable for crypto. (I don't know one way or the other, but I'm guessing you don't either).

Re:you have the source

[AndroSyn]

It's not as simple as just commenting out a few lines of code.

No, it's easier than that. You can simply pass nordrand to the kernel. It was the first thing I saw when I opened up
arch/x86/kernel/cpu/rdrand.c
__setup("nordrand", x86_rdrand_setup);

So there...don't like rdrand, don't use it.

From Documentation/kernel-parameters.txt

                nordrand [X86] Disable the direct use of the RDRAND
                                                instruction even if it is supported by the
                                                processor. RDRAND is still available to user
                                                space applications.

Re:you have the source

[Anonymous Coward]

No, it is not. Being unwilling to do something for yourself, and then demanding that others do it for you, to the point of trying to pressure them with a mass petition, is the most obnoxious cop out.

Re:you have the source

[pipatron]

Are you suggesting that the kernel should kill of application in userspace using this instruction? Are there any other instructions you morally object to? Using XOR with a constant is also bad cryptography, perhaps it should be prevented by the kernel.

Re:you have the source

[DarkOx]

You don't need your own tree. Its mature area of the kernel. You just keep your patch and once in blue moon modify it slightly if some day it stops applying cleanly.

Re:you have the source

[interval1066]

...let Linus do what he does best.

Act like a raving lunatic? He's doing quite well enough, no one's getting in his way.

Re:you have the source

[michelcolman]

RDRAND is an instruction, just like "add these two registers" or "jump to this address". Of course it's still available to user space applications. The point is that you can specify that the OS itself should not use it for things like /dev/random. If a user space application wants to use it, there's not much the kernel can/should do about that. Apps can use pretty much any insecure random algorithm anyway.

Re:you have the source

[wisnoskij]

There is a huge difference between the skill set to maintain your own version of Linux, the skill set to program efficient code that does not break anything, and the skillset to understand encryption.

Re:you have the source

[realityimpaired]

If you'd bothered to read the comment thread in its entirety, you'd see that I posted, in quite plain English, that I have no opinion one way or the other about whether the instruction in question represents good crypto, because I don't know enough about the quality of numbers being generated.

The comment you're replying to was in response to somebody claiming that in order to disable the instruction entirely, you only have to pass an argument to the kernel. Clearly, that doesn't disable it entirely, as stated in the comment that he pasted into his own reply.

Of course, this being Slashdot, people don't give a shit about context, and reading is for the weak.

Re:you have the source

[Chrisq]

Are you suggesting that the kernel should kill of application in userspace using this instruction? Are there any other instructions you morally object to?

Op code 666

Re:you have the source

[fritsd]

But, if it's a CPU instruction, you'd have to write code for it yourself in assembler. How many people would go that far, to bypass "best practice" default Linux kernel randomness, in order to only use this one CPU maker's code? It would look very suspicious:

"Our security program runs only on that specific line of Intel CPUs, because.. well.. that's more secure than using anything else! just trust us!"

Re:you have the source

[Anonymous Coward]

Kyle Condon here, the reason I started the petition was not because I was too lazy to do it myself. I know C and could quite easily compile my own kernel with the functionality taken out. However, the petition was to have it removed from the MAINLINE linux kernel, this would remove it for everyone who ran the linux kernel and not just the select few who had enough knowledge to turn it off.

Re:you have the source

[Pirulo]

can we have score 6 for parent?

Re:you have the source

[TechyImmigrant]

> Is there even a way for the OS to prevent applications from using this instruction?

Yes. You use your OSly powers to be the hypervisor and put a VM trap on the instruction. Then rather than returning a random number you return an #undef or a non random number or a zero with the carry flag clear.

Don't trust a VM that traps RdRand. It is out to get you.

Re:you have the source

[erikkemperman]

No,no,no. Too obvious. How about,
667 - neighbor of the beast

Re:you have the source

[gweihir]

You have the source code, remove rdrand from the kernel yourself.

And that would be exceedingly stupid. The trick to good entropy gathering is to use all sources available, mix them into the entropy pool, while very conservatively estimate each ones contribution. Removing _any_ source that provides at least some entropy, even if only under some conditions, can only make the result worse. That means that even of RdRand is fully compromised (which is extremely unlikely, as that would be obvious), it would still be a bad idea to remove it. It may be sensible to estimate its contribution as very low or zero, but one source cannot compromise the entropy pool and that is the whole point of the design. If there is at least one good entropy source mixed in, then the /dev/random is secure. If enough so-so sources are mixed in, then /dev/random is secure. If in addition any bad or compromised sources are mixed in, /dev/random is not made any less secure.

And yes, Linus is right. The petitioner does not understand how entropy, entropy gathering and entropy pools work and what he petitioned for is exceedingly stupid. That Linus has an abrasive communication style may just be the result of him having been exposed to too much BS like this.

Re:you have the source

[TechyImmigrant]

Yes. But I'm not going to give a well researched answer because I'm about to get on a plane.

Primarily the problem is that the Linux kernel RNG exists in many contexts and trusts that its random sources are random across all those contexts. This has been found to be false. The factorable.net study showing re-used primes between certs created on low-entropy router devices is an example of what can go wrong.

There are other more detailed things. The pool entropy calculations are flat out wrong. They are less wrong after Peter Anvin submitted a patch to have it do a piecwise approximation to a shannon entropy sum rather than an arithmetic sum, but it's not doing anything like a normal min-entropy computation for an entropy extraction algorithm.

The kernel trusts userland programs to be honest about the entropy in the sources. E.G. RNGd. However RNGd and other entropy gather daemon's have no basis on which to know the source entropy and so they make it up. The kernel takes this number and uses it in the pool entropy calculation. And so the whole calculation is built on sand.

The behavior of the kernel results in boot time entropy starvation, right at the point where you need it most.

This is RdRand changes the picture somewhat. The entropy source is well modeled and its min entropy is know. The resulting entropy from the condition is therefore known. The entropy seeding the DRBG is therefore know. It is therefore known how to extract full entropy output from RdRand, and it is known what the cryptographic resistance to brute for attack is (which is not quite the same thing). Such a chain of reasoning is what a good RNG should have.

You are better off using RdRand because it's available from the first instruction executed. It has known properties and the resulting numbers are not subject to the timing, memory API attacks that the kernel RNG numbers are subject to on the long winding path from device to RNGd to kernel API to kernel RNG to /dev/random to userland library to userland application.
 

Re:you have the source

[pthisis]

Not true... I have no opinion either way, but it's entirely possible to have a very good understanding of how semi-random numbers affect cryptography, and also of how rdrand generates them, without having the programming background to be able to safely remove it from the kernel. Crypto is about math, not programming, and contrary to popular opinion (apparently), the two do not always go hand-in-hand.

RdRand could generate entirely non-random numbers and it still wouldn't make the output of /dev/random any less random. It's designed so that additional inputs can only increase the entropy, never decrease it. There's a danger if you over-estimate the amount of entropy that a particular input adds to the pool, but the bits mixed in from rdrand don't increase the entropy counter so that's not a problem in this case.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9

Re:you have the source

[ultranova]

The comment you're replying to was in response to somebody claiming that in order to disable the instruction entirely, you only have to pass an argument to the kernel. Clearly, that doesn't disable it entirely, as stated in the comment that he pasted into his own reply.

The petition, this thread and the comment you replied to were all talking about the kernel and the random numbers it provides through /dev/random. So, in the context of this discussion, passing an argument to the kernel does disable RDRAND completely. This is a bit too obvious to believe you're arguing in good faith here.

Of course, this being Slashdot, people don't give a shit about context, and reading is for the weak.

Indeed.

Re:you have the source

[tytso]

What I said is that /dev/urandom is much more important to get right than /dev/random. Realistically, far more programs use /dev/urandom than use /dev/random. GPG uses /dev/random for long-term key generatiom, but in terms of generating certs, creating session keys, etc., /dev/urandom is far more important.

If you trust Intel not to have gimmicked RDRAND, by all means, feel free to use it. Please do it in open source, though, so I can fix said program not to, though.....

Re:you have the source

[tytso]

The random driver has changed significantly since July 2012, which is we were given a heads up about the paper described at http://factorable.net/ which is also when I took back maintainership of the /dev/random driver. We gather entropy at every single interrupt, and mix it into the entropy pool. This is done unconditionally, you can't disable it, like what happened with the SA_SAMPLE_RANDOM flag.

The thing about entropy pools is that when you combine entropy sources, the result gets better, not worse. So the best thing would be if we had hardware random number generators sourced from China, Russia, and the USA. Since presumably the MSS, KGB, and the NSA mutually distrust each other, if we combine the entropy from those three soruces, the result will be stronger than any one alone.

This is why I don't recommend using RDRAND directly. Sure, an honest (emphasis on honest) hardware random number geneterator will always be able to source higher quality entropy than anything we can do by sampling OS events, such as interrupts. But the problem is it's hard to guarantee that a HWRNG is really honest. Especially given the Snowden revelations which seem to indicate the NSA has successfully leaned on at least one chip manufacturer. If you must use RDRAND, I'd recommend generating a random key via some other means, and then encrypting the output of RDRAND by that random key before use the resulting randomness for session keys, etc. Or better yet, do what we do in /dev/random, which is to mix RDRAND with other sources of entropy.

Re:you have the source

[kenshin33]

the whole thing was about using/not using it in /dev/random (the random number generator of the kernel ). http://en.wikipedia.org/wiki/RdRand rdrand is a cpu instruction to get some random number from a embedded hardware random number generator (a chip) as is mov, add, mul, or, XOR ..etc. the comment you quoted (from kernel doc) is simply stating that even though you disable it's use in /dev/random any user space code running (program) might use it ( as it can use any other cpu instruction)

Re:you have the source

[Lennie]

Interesting enough the Raspberry Pi has a hardware random number generator built in, did you know that ?

That might actually be one of the cheapest devices with a hardware random number generator I'm aware of.

Does anyone have any information about what type it is, how it works and how good it is ?

At Least He Doesn't Throw Chairs

[Anonymous Coward]

This douche bag just wishes painful death on people who disagree with him. That is so much better. The guy may be brilliant and he may have created a wonderful thing for the world. But he is every bit the douche bag that Jobs and Ballmer have ever been.

Re:At Least He Doesn't Throw Chairs

[iserlohn]

Linus is funny while Ballmer acts funny. Worlds apart if you ask me.

Re:At Least He Doesn't Throw Chairs

[Goaway]

No, the guy who made the petition was way out of line for calling Linux "an approved partner of the NSA", and way out of his depth because he had no idea what the hell he was talking about.

Linus was just responding to an asshat, and went pretty easy on him.

Re:At Least He Doesn't Throw Chairs

[MrDoh!]

Yeah, it's just Finnish humour that's being taken badly. I know he's been in the US for a long time, but he's not being mean, it's just a way of expression that it appears many don't get. !Still, the AC could always email Linus and ask him to change, I'm sure he'd appreciate the input.

Re:At Least He Doesn't Throw Chairs

[Sarten-X]

...where kindergarten teachers repeat the Golden Rule to him.

I've seen Linus get into an argument with someone of the same style. After a few rounds, it became obviously different that the debate was not like the typical Internet insult-hurling flame war. Rather, each side had points and counter-points and presented a persuasive case... just peppered with insults and offenses, as a separate layer of argument. It's sort of like real insult swordfighting.

Re:At Least He Doesn't Throw Chairs

[oztiks]

I'm with you on that. It seems like his sense of humour and his calling "a spade a spade" philosophy earns him a lot of criticism. I always argue that Linus is your typical purest. He's not there to please or appease. He's there to focus on getting things done right, in his own way, but as correct as he sees it.

I argue that because he's giving Linux freely to the world and with limited monetary gain that we can't chastise him too much about it either. What he's missing is something which I've learned through my own errors when dealing with people in the past. And that is, to deal with "the public" one must always do so with the softest possible touch. That's only if you're wanting to earn the minds of the masses mind you.

So I say. People who bag him with the whole "his attitude is appalling" type statements. Well, it sucks to be you because I think that you're just too much of a sook and you need to harden/lighten up a little. The people who condone the attitude I say "meh, you're probably a purest as well" because they wish to understand truth and wish to see what goes on in the Linus' mind just as I do.

As me for me. Truth be told. The day Linus actually starts acting like the rest of the PR sheep out there is the day I'd start to worry about crypto that NSA may of sneaked in to the Linux kernel. Until then. It's good to see him throwing out comments like "Deep throat Microsoft" and "You're ignorant". This kind of talk is indicative of when the internet wasn't populated by commercially driven cock suckers like Mark Zuckerberg abusing the word "hacker" and trying to pass himself off as "one of us".

So at the end of the day, who's really lost touch here?

Re:At Least He Doesn't Throw Chairs

[oztiks]

He didn't create anything. ANYTHING. Open source existed before Torvalds. UNIX existed before Torvalds. To use the infamous battle cry of the typical Slashdork... "Where's teh innovationz?!?!?111!!?"

I've been using Linux since 1993. I can't even begin to tell you how wrong you are :) Oh the memories ... 14.4 modems, 386 DX!! (yes, none of those pussy SX processors), Hercules monitors and MFM harddisks!

When people start treating it like a valid technology instead of a religious movement it'll get more momentum in the mainstream.

You're missing the point. It's not treated as a religious movement It's kind of more like being a 60s child in the modern day if that makes sense.

When people start worrying about advancing Linux over where it stands versus Microsoft or Apple it'll finally have the chance of taking great leaps forward.

Google wrapped a business model around Linux. It's called Android and it's doing just fine.

Re:At Least He Doesn't Throw Chairs

[oztiks]

Not to make it a dick measuring competition on Tovalds behalf but you look at the guy on the other side of the fence who made staggeringly more.

Besides, we wont mention that this person in question has since then retired and is still making literally 100x more per year than Tovalds. I get your point but relatively speaking, If Tovalds chose to sell out how much more could [of] he made/make?

Re:At Least He Doesn't Throw Chairs

[MysteriousPreacher]

All said by someone without the balls to post as themselves.

Yeah, not like us ex-military types who have the balls to post under our real pseudo identities.

Does AC even lift?

Re:At Least He Doesn't Throw Chairs

[Lumpy]

That is my real name you insensitive clod!

Re:At Least He Doesn't Throw Chairs

[Anonymous Coward]

I take it from your posts which contain slight spelling and grammar affectations (but are otherwise coherent) that English is not your native language.

You may wish to make note of the following:

"I have made over $10,000,000 this year."

"I of made over $10,000,000 this year."

These statements are not equivalent and one of them is actually nonsense.

"I could have made over $10,000,000 this year."

"I could of made over $10,000,000 this year."

Likewise with these statements.

"I could've made over $10,000,000 this year."

This is pronounced as "could uv", but I assure you that the 've is a contraction for "have". Many less educated native English speakers make this mistake, so you'll likely want to avoid it when possible.

Got your feelings hurt?

[Splab]

The TFA makes it look like Linus went on full rampage mode and tore a insightful request down by being mean.

Actually reading his responses, Linus is pretty level headed and just says no, you can't have this.

Guess submitter got his feelings hurt?

Re:Got your feelings hurt?

[greenfruitsalad]

that is exactly what i thought. guy creates a lame picture with NSA and LINUX in it, comes up with a fascinating heading and uses yesterday's info from slashdot discussion to create FUD. if i were Linus, i wouldn't have bothered with such a long response.

Re:Got your feelings hurt?

[Splab]

How about reading his responses?

Taken out of context, those are death threats, in context however, it's just (misguided?) ventilation. He just ventilates and says that it's a pile of poo and he really wish they would stop doing that, he then goes on, in an uncanny (for him) reasonable response on how, they should handle pull requests in the future.

Grepping our own source tree for fuck, crap, shit, die, stupid will return quite a lot of ventilation and quite often directed at the sales department. Veteran programmers are grumpy old bastards, live with it or get off our lawn.

Re:Got your feelings hurt?

[dkleinsc]

There's been a whole series of "Waaa, Linus told me I was wrong and is a big meanie" articles over the last few years. I'm unclear exactly why, but it seems as though some feel like if they don't get their way on LKML, the next logical step is to complain to Slashdot.

Re:Got your feelings hurt?

[DeathToBill]

Here's what he wrote:

Where do I start a petition to raise the IQ and kernel knowledge of people? Guys, go read drivers/char/random.c. Then, learn about cryptography. Finally, come back here and admit to the world that you were wrong. Short answer: we actually know what we are doing. You don't. Long answer: we use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if rdrand were to be back-doored by the NSA, our use of rdrand actually improves the quality of the random numbers you get from /dev/random. Really short answer: you're ignorant.

Linus is not usually my cup of tea, and the sprinkling of personal attacks doesn't help his case. But it's a reasonable explanation of why /dev/random works the way it does and why it won't be changed.

Re:Got your feelings hurt?

[MrNemesis]

These days, almost every time a story is posted along the lines of "Linux says X" it's frequently framed in such a way as to paint Linus as a frothing madman hurling not just insults but entire furniture factories at his cringing subordinates. It's become such a regular occurence that I half expect them to be followed up with a story on how Steve Ballmer has converted to buddhism and will be using the armpit sweat from his meditations to irrigate the sahara.

Reading the article, of course, usually reveals a different picture, but that gets in the way of attention-grabbing headlines. I'm not really sure how the following post can be construed as "fury"; irritation, indignation, perhaps, but not fury.

Where do I start a petition to raise the IQ and kernel knowledge of people? Guys, go read drivers/char/random.c. Then, learn about cryptography. Finally, come back here and admit to the world that you were wrong. Short answer: we actually know what we are doing. You don't. Long answer: we use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if rdrand were to be back-doored by the NSA, our use of rdrand actually improves the quality of the random numbers you get from /dev/random. Really short answer: you're ignorant.

As far as I can tell, no-one's found any evidence for rdrand being backdoored, and even if it were, there's bigger issues at foot with things like microcode. Linus explains how the kernel implementation uses random data from several different sources to guard against this kind of stuff. Plus, as other people have pointed out, you can disable rdrand with a kernel parameter. Linus is primarily a pragmatist, so it doesn't really make much sense to excise the code from the kernel - throwing out the baby with the bathwater if you will. Surely if there were any hardware to worry about, it'd be the hardware providing AES-NI? Why isn't there a petition to have that removed...?

Re:Got your feelings hurt?

[Rockoon]

I'm not sure that it is a reasonable explanation given that RDRAND has access to everything in both memory and registers and can thus predict and/or coerce with perfect accuracy what the other randomization steps will actually do.

However, I think in the end its a matter of trust. If you cannot trust the CPU then no kernel change is going to improve the situation.

Re:Got your feelings hurt?

[Minwee]

Indeed. We tried to warn the world about this almost twenty years ago, but nobody listened.

RDRAND will re-write your hard drive. Not only that, but it will scramble any disks that are even close to your computer. It will recalibrate your refrigerator's coolness setting so all your ice cream goes melty. It will demagnetize the strips on all your credit cards, screw up the tracking on your television and use subspace field harmonics to scratch any CD's you try to play.

It will give your ex-girlfriend your new phone number. It will mix Kool-aid into your fishtank. It will drink all your beer and leave its socks out on the coffee table when there's company coming over. It will put a dead kitten in the back pocket of your good suit pants and hide your car keys when you are late for work.

RDRAND will make you fall in love with a penguin. It will give you nightmares about circus midgets. It will pour sugar in your gas tank and shave off both your eyebrows while dating your girlfriend behind your back and billing the dinner and hotel room to your Discover card.

It will seduce your grandmother. It does not matter if she is dead, such is the power of RDRAND, it reaches out beyond the grave to sully those things we hold most dear.

It moves your car randomly around parking lots so you can't find it. It will kick your dog. It will leave libidinous messages on your boss's voice mail in your voice! It is insidious and subtle. It is dangerous and terrifying to behold. It is also a rather interesting shade of mauve.

RDRAND will give you Dutch Elm disease. It will leave the toilet seat up. It will make a batch of Methanphedime in your bathtub and then leave bacon cooking on the stove while it goes out to chase gradeschoolers with your new snowblower.

Why all the whining in the first place?

[CajunArson]

Shouldn't we be welcoming RdRand with open arms? It's a mathematically proven high-quality random number generator that lets chips like Ivy Bridge & Haswell produce large amounts of true random data (not a simple PRNG data) at multi-gigabit speeds.

There are some excellent slides describing RdRand here: http://software.intel.com/en-us/tags/20757

I would strongly recommend using it wherever feasible as it is a great boon to security in Linux.

So is some AMD/ARM fanboy saying that it's not fair that AMD/ARM haven't bothered to implement RdRand yet so therefore nobody should be allowed to use it? How about we extend that logic to other pieces of hardware? Say, when AMD comes out with an improved GPU, let's say that Linux shouldn't support it because Intel doesn't have the same hardware.. fair is fair right?

Re:Why all the whining in the first place?

[pjt33]

It's a mathematically proven high-quality random number generator that lets chips like Ivy Bridge & Haswell produce large amounts of true random data (not a simple PRNG data) at multi-gigabit speeds.

Maybe. Or maybe it's deliberately weakened by Intel in response to a request from NSA in an effort to produce something akin to the Debian weak key problem. Can you audit your CPU to see whether the implementation is the one which the proof belongs to?

Re:Why all the whining in the first place?

[Spad]

It's getting increasingly difficult to label people tinfoil hatters given the way the NSA leaks are making even the most ardent paranoid conspiracy theorists look like they've vastly underestimated the problem.

Re:Why all the whining in the first place?

[Anonymous Coward]

It's pretty easy to go look at randomness and test it you know.... and Intel's RNG has stood up to testing and scrutiny by a whole bunch of real security researchers, not just paranoid basement dwellers who see the NSA around every corner.

I don't think you quite get what the issue is, so I'll give you a little thing to try on your own time that might enlighten you a bit.

Write a small program that increments a counter from 0, in steps of 1, so 0, 1, 2, 3, 4, and so on. Trivial.

Then include a strong symmetric cipher, like AES.

Devise your own, very secret, key.

Apply AES with said key on your counter.

Collect enough AES-encrypted output to perform statistical analysis.

Note how it appears to be entirely random. Nice distribution of values. Compare the characteristics of your analysis to any strong PRNG. Observe the uncanny similarities.

Apply these findings to the *fact* that you cannot dissect the hardware PRNG in rdrand, and others.

Ponder the consequences.

Become slightly more enlightened.

You're welcome.

Re:Why all the whining in the first place?

[TechyImmigrant]

Well I think I would know about it if it was. I don't recollect the NSA leaning on me to put backdoors in there when I was designing it.

Re:Why all the whining in the first place?

[aaaaaaargh!]

Actually, you're both idiots, though you're the bigger one.

First, the halting problem concerns a program that can check of any input program whether it will halt or not. There is no problem with writing a program that checks whether some given input programs halt or not, conversely, this is done all the time e.g. in formal software verification. Second, there is no way to confirm that a random number generator is cryptographically secure by only looking at its output. In fact, it's completely trivial to write a program that produces pseudo-random numbers in a completely predictable way while passing all statistical tests (like the diehard suite). Every decent modern blockcipher can produce such output. That's what this debate is about, as long as RdRand is a blackbox and does not provide researchers with a way to inspect in the detail how it obtains true random data, it must be considered insecure from a cryptographic perspective. Third, the other guy is also a (lesser) idiot because there would be no need to check what some software does with the RNG. To make the hardware RNG exploitable it suffices to ensure that its actual random source is fairly low entropy and only looks random. The NSA was able to break alleged one time pads during Cold War by exploiting the fact that secretaries were told by the KGB to type letters randomly, a task at which humands are not very good. Or, so the story goes.

Re:Why all the whining in the first place?

[Xtifr]

The issue at hand is that RdRand cannot be trusted to produce random numbers. Both sides agree on this. One side argues that it should never be used, the other side argues that it can be used if mixed with other random number sources.

One side argues out of utter ignorance that it should never be used; the other side argues based on solid math that it can be used if handled properly. Both sides are properly paranoid, but only one has the facts on their side: the dev team.

As for the people who are complaining about Linus's tone here--I admit that he can be a bit harsh on his fellow developers at times, but this isn't such a case. This is him slapping down an ignorant fool who fully deserves the abuse he got, and perhaps more.

The simple fact is that not using RDRAND will not lock out the NSA--if they're hacking chips, there are thousands of ways they can subvert your system, and RDRAND is almost too obvious (and too easy to avert, as the kernel devs are doing). If your need for security is so high that you can't trust your chips, your only reasonable alternative is to build your own. Good luck with that. :)

Hmm....

[Andy Dodd]

There was an incident a few years ago (that led to at least one subsystem maintainer resigning) where RdRand was used as the EXCLUSIVE entropy source for some items if it were present. http://cryptome.org/2013/07/intel-bed-nsa.htm - Matt Mackall resigned over it.

This is BAD.

If it is now merely feeding the pool as one of multiple sources, then it's OK. If anything is directly exposed to raw rdrand output, something is very wrong.

Re:Hmm....

[tgd]

Yes, Matt did the right thing there and Linus' responses on the RdRand issue have seemed entirely out of character for him. So out of character I am sure I am not the only one wondering if he is being blackmailed somehow.

Yes, its a government conspiracy to keep people from changing a compile-time option for ... um ... secret ... um ... stuff.

Re:Hmm....

[Mashdar]

That stuff is TOP sercret to you. How dare they not break userspace because a single source of entropy is questionable?!?! I vote we just remove /dev/random entirely. Clearly everyone should write their own entropy algorithms so NSA can't coerce anyone. In fact, lets remove /dev.

Re:Marital/Money problems???

[IamTheRealMike]

I think it's more likely that the RDRAND thing has been an ongoing argument/flamewar for a long time. See this thread for an example.

BTW Linus is right. According to what we know about randomness, even if RDRAND is hacked then mixing it with other entropy can't hurt - at worst, it merely is a no-op and achieves nothing. However, even if RDRAND is backdoored, the NSA is not the worlds only adversary. Given that when mixed with other randomness it doesn't hurt, it's still better to use it against all the other adversaries out there than not.

Linus' point is, exclusive reliance on RDRAND would be bad, but the kernel doesn't/shouldn't do that.

Re:Linus an example of ...

[h4rr4r]

Its just a shame that morons like you value social graces over the ability to do real work. This is why companies fail, especially as they get better, playing well with morons is valued over the ability to get shit done.

Re:More Linus buying his own story.

[Anonymous Coward]

I didn't think God played dice.

Re:Marital/Money problems???

[h4rr4r]

Based on what?

He has always spoken this way to those who deserved it. Notice he does not go after noobs or people who do not ask for it. If you put up a petition to get something changed, you should at least know what you are talking about.

Re:Linus an example of ...

[pjk]

Someone who has no social skills but uses his persona to stay at the head of the ship.

Well, either that or his technical understanding, organisational skills and the respect of his peers for many a year.

it is just a shame such a social retard is allow to rant as he is.

Guess humour isn't your thing ?

One word: Transmeta

[gatkinso]

ARM SoC hardware designers world wide smile into their hand.

Re:Negotiation Skills

[Goaway]

There was no negotiation going on. There was a single obnoxious guy calling Linux "an approved partner of the NSA" and complaining about something he knew nothing about. He deserved what he got. In fact, Linus went pretty easy on him.

Randomness not so random

[schneidafunk]

I have to admit I didn't know much about the controversy so I went and found some articles.

Here is an article showing some weaknesses in Linux's random generation: Analysis of the Linux Random Number Generator

As reported by Bruce Schneier for this Wired article: http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115

A petition?

[macemoneta]

If you believe there's something broken in the kernel (or other open source project), you don't create a petition, you create and submit a patch. If you don't know enough or don't have the skills to create a patch, you're probably not qualified to criticize the implementation.

"Anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge." -- Isaac Asimov

Excuses, excuses, excuses !

[Taco Cowboy]

Maintaining your own kernel tree over time is most certainly non-trivial by most peoples standards

Some people just had to complain about every-single-thing, even if it's downright inane.

Open source is just that, you can read the source of the programs, and with the source, you have the options to do the following :

1. Determine if the program has any backdoor / malware embedded

2. Change/alter the source to your own liking

3. Learn from the code and perhaps in a latter day you might be able to apply what you have learned in your own program (and I am not talking about cut and paste)

If all the above are STILL not good enough for you, the offerings from Apple and Microsoft are always available.

Re:Excuses, excuses, excuses !

[fritsd]

Hey, you forgot an important one:

• 4. PAY ME to make a kernel package for you that has this RDRAND thingy turned off.

Re:Excuses, excuses, excuses !

[vux984]

Open source is just that, you can read the source of the programs

I believe the suspicion is the RDRAND cpu instruction itself is a black box from intel that may have been subverted by the NSA.

As such, no, it can't be audited, and it's source cannot be inspected.

Re:Excuses, excuses, excuses !

[tqk]

I believe the suspicion is the RDRAND cpu instruction itself is a black box from intel that may have been subverted by the NSA.

Based on recent news, anyone would be perfectly justified in believing that, and may even be correct. Linus: 1. rdrand: 0.

Re:Linus an example of ...

[SirGarlon]

There comes a time in every professional's career when he cannot do everything himself, and needs the assistance or support of others. When you reach that point, you will find you'll need those "social graces" you hold in such contempt, or else your career will stall or end abruptly.

Re:Marital/Money problems???

[Austerity Empowers]

He has always spoken this way to those who deserved it.

From his perspective. I would assert he has as little business talking about ARM SoC hardware designers about their design decisions as they have of telling him how to design an OS.

Anyone who has worked between chip and software teams knows the fights here are epic and unending.

I admire Linus, but...

[wjcofkc]

I would first like to point out that if you really read this particular response, he was not as flaming as is being reported. Sounds like someone is exaggerating over a grudge. However...

Of all modern figures, Linus Torvalds is close to the top of my list of people who I respect and admire the most. His work has truly changed the world for the better. Can you imagine what things would be like if Linux had never happened? I shudder at the very notion. Regardless of this, Linus has in fact shown over the years that he can have an unreasonably short fuse. He is not RMS, but he's not far and when he does take a hard-line bad attitude stance, I sometimes fear that it is at the detriment of potential progress. Important, high profile maintainers have quit over the years due to his attitude, and it would be nice if he could be more diplomatic in those situations where he unnecessarily goes off like a stick of dynamite. I think there is a degree where his power has gone to his head. But as long as Linux keeps marching forward, I am happy enough with that.

Re:That's uncalled for, really.

[Anonymous Coward]

If you ever have to deal with Linux on ARM without a ready-made distribution for just your system, you will understand the sentiment. Non-discoverable buses are indeed shit. Having to manually tell the OS where everything is was tolerable in the 90s, you know, before something as initially broken as plug-and-play was cause for joy because you no longer had to use dip switches to set conflict-free addresses that you then had to copy into the BIOS setup and every application, and hope that someone hadn't hardcoded the port number for the Soundblaster card.

Re:Linus an example of ...

[h4rr4r]

Which is why Linux is a millionaire and head of the worlds most used operating system?

Social graces are fine for when they are needed. I do not hold them in contempt at all. There is a time and a place for them and everything else, this was not the time to suffer fools.

Re:Linus an example of ...

[allcoolnameswheretak]

If you can't communicate without being an abusive asshole, I don't want to work with you, no matter how "real" your work is.
This kind of talk, even if out of context, is infantile and damages the reputation Linux and open source in general.

Re:Negotiation Skills

[Lumpy]

It's not only an obnoxious guy, but an uneducated one. You can easily disable it with a compile time option already.

asked the Condon and the supports of the petition

[Mr Z]

"... Torvalds asked the Condon and the supports of the petition ..."

That's some mighty fine editing there, Lou. FWIW, if that was copy/pasted from the original article, they've fixed it over there. Otherwise... wow.

The ARM problem is a security problem

[Error27]

ARM chip designers view hardware as disposable. Why worry about software security updates when you are just going to replace the phone every 18 months?

Cursing about it on LKML is useless though. Linus should start a change.org petition to address this issue.

Careless statements

[Reliable Windmill]

I'm wondering how clever it is for Linus to make statements like "So if you see any, send them my love, and possibly puncture the brake-lines on their car and put a little surprise in their coffee, ok?"

With stories of kids getting arrested and sent to jail for saying things like "I'm going to kill someone. Nah just kidding." he may be setting himself up for this. I can imagine U.S gov wanting to take that opportunity, with him being so prominent and open source operating systems possibly proving to be the only guaranteed escape from NSA eavesdropping.

If I wanted TMZ style sensationalist stories...

[Rinikusu]

I'd read TMZ.

Man, I can't wait until the /. submitters discover Theo de Raadt.

Re:Marital/Money problems???

[gnasher719]

BTW Linus is right. According to what we know about randomness, even if RDRAND is hacked then mixing it with other entropy can't hurt - at worst, it merely is a no-op and achieves nothing.

That's actually not correct. RDRAND is an instruction in an Intel processor. You know what it is _supposed_ to do according to the documentation, but you don't know what it actually does.

It could install a trap that fires on the next XOR instruction, and if the destination is XOR'd with the result of RDRAND, replay the instruction sequence, but returning a different result for the RDRAND itself, so that the destination is changed to what the NSA wants.

Re:Linus Torvalds is an NSA asset

[Anonymous Coward]

The Truth Will Out!

Oh, come now. It'll only out if you accidentally the whole thing.

Time for an entropy server?

[Okian Warrior]

The NSA has apparently compromised random number hardware and software packages throughout the industry.

Could this be fixed by using an entropy server?

Suppose some group hosted a random number server. A verified source of true randomness which can be trusted by the reputation of the people involved, in the same way that we trust the people who make Tor, Mozilla, and linux.

It would be a single point of failure, but also a single point of defense. We could put all the best practices and best ideas of security into one place, by means of technology, software and legalities. It could be hosted in a privacy-friendly country, it could be monitored and defended by the EFF using legal means, it could use the best technology for generating randomness and have open and easily-inspected software and procedures.

To use the system, a client would:

• Generate a public/private key using whatever entropy is on hand
• Encrypt the private key using the server's public key and send it to the server
• The server returns a packet of random numbers, encrypted using the client's key
• The client generates a new key pair using the returned entropy
• The client uses that key pair from then on

This is slightly weak because the NSA could record the conversation and "simulate" the client computer to recover the generated keys, but doing this is much harder than cracking weak keys. In the server model the weak key is used once, instead of being used all the time. Also, simulating a computer (including nuances of software version and hardware quirks) is much harder than finding weak keys.

(To find weak keys, gather all the keys you can find and calculate GCD on pairs of keys. In practice, about 1 percent of all keys on the net have common factors. Most of these come from systems with low entropy - headless systems (routers, firewalls, servers) with no user interaction for randomness.)

In one action we could fix the security of much of the software used in the internet.

Any volunteers?

(I'd love to, but it has to be outside the US. I'll donate $1000 towards costs if the idea is viable.)

Re:Time for an entropy server?

[bill_mcgonigle]

Generate a public/private key using whatever entropy is on hand

I happened to read a discussion of this on Ted Tso's Google+ last night (stayed up way too late...) and the short answer is that there's not enough entropy on the newly booted system to make the strong keys required to bootstrap the equation.

To paraphrase, Ted called ISC retarded for creating a DNSSEC where the validation of a key required a strong entropy source on the client. He likened it to needing a private key to validate a GPG signature, which one does not.

So, the TODO list is to create a replacement for DNSSEC that does not require an entropy source to validate the transaction. I don't think this needs to replace DNSSEC - it can be narrow enough for only this usage. Bootstrapping protocols are often both stunted and useful.

Since I haven't had time to think about it myself, allow me to invite comments: does an encoded GPG-signed TXT record in plain-old DNS suffice here?

Re:Time for an entropy server?

[TeknoHog]

A bunch of ring oscillators in an FPGA is pretty good for RNG. Then you just have to trust the FPGA build software...

Re:Time for an entropy server?

[steveha]

It's an unreasonable idea. First, it requires a reliable Internet connection. Second, the NSA could monitor the traffic, plant back doors in the server, or otherwise compromise an in-the-cloud solution.

Much better would be a hardware source of randomness, connected to your server, and under your direct control.

Why not get a cheap webcam and set up your own LavaRnd? There, true random data available to your computer even at boot time.

http://www.lavarnd.org/what/how-good.html

LavaRnd has Linux kernel drivers, and it will drop right in and Just Work.

I'll donate $1000 towards costs if the idea is viable.

You could buy a lot of cheap webcams for $1000.

Re:"I hope that ARM SoC hardware designers all die

[TechyImmigrant]

Just the ones who put in non discoverable busses. So he got that one about right,

Re:Wow, he's so mature.

[MysteriousPreacher]

Then he wonders why Linux adoption rate on the desktop is nearly zero.

Any soccer mom reading this will think Linux is an OS developed by some 12-year-old dumbass, and will obviously refuse to use it..

Yeah, definitely. I'd be surprised if this doesn't shift at least 30% of soccer moms over to FreeBSD or Haiku. Sure they might keep Linux on some of their servers, but their desktops are almost certainly going to be switched away from Linux. Well done, Linus!

Re:Marital/Money problems???

[Austerity Empowers]

The SW guys have a job to do in ensuring the the HW guys have proper requirements, it's not all just coding and committing.

I work at one of these ARM SOC companies, and the software guys complain an awful lot after the fact, but take almost no involvement in design reviews and architectural work for the hardware, and treat design reviews as optional. One guy is known for the mantra "We don't have time for reviews, do what you think is right and suffer the consequences". That may serve him well in software, but for hardware, particularly SoC's, it's far too expensive to change once manufactured.

I don't expect Linus, the Linux kernel maintainer, should be expected to worry about ARM issues, but he should make it clear to the SW developers who are, that shit stinks and he will hunt and kill firstborns until the problem is resolved. They at least are listening to his rant. Hardware guys are off trying to squeeze 10% more performance out of a memory bus or something, this is way too far out of their ivory tower to concern themselves with unless someone makes it an issue.

Here's your debate

[Okian Warrior]

It's not a "cop out" at all. The party that manages the code doesn't want to remove a feature that there's no logical reason to remove. The petition was one sentence, linked to no debate, made no points and didn't even attempt to negotiate. It could have said, "Do it, because we say so." and it would have been just as informative. I think you need to look up the definition of "cop out", because the petition creators could have actually done something useful, and didn't.

Okay then, lets fix this.

The NSA has compromised products and devices in the design phase - both software and hardware. We don't know which products are compromised or how, but we do know that some are.

Random number generators cannot be verified - it's a computationally infeasible problem. If the NSA has subtly tampered with a product, there's no way to tell from the outside looking in. You *might* be able to tell by looking at the generator source. (Note that the linux random number generator has at least one undocumented source of entropy.)

There is no reasonable way to look at the source code/microcode of the rdrand instruction.

Additionally, there is no way to verify the underlying source of randomness of the rdrand instruction. There could be vulnerabilities on the silicon die.

The whole point of open source is that people can peek at the software and see what's going on.

Since there is no way to inspect the random number generator and no way to verify it's operation, it should not be used by default.

It's a security risk, plain and simple, and risk management should be up to the user. However small the risk is, forcing everyone to take it multiplies the chance that someone will get burned by it.

Here's your logical argument. If Linus wants to debate this, let him address these issues. Linus needs to show the premises wrong, or that the conclusion doesn't follow from the premises.

If he can't, then he should abide by the recommendation.

Re:Here's your debate

[phayes]

Linus needs to show the premises wrong

Says who? You? Linux is Linus's ball. The global consensus is that Linus is doing a good job slamming the people with self entitlement issues that want him to do stuff for irrational reasons. If you want you can fork & make your own distrib. Submit a story to /. in 6 months telling us how that went, we could all use a laugh.

Re:Here's your debate

[Chemisor]

Random number generators cannot be verified - it's a computationally infeasible problem.

Then how do you know the software RNG in the kernel is random? By using randomness tests, that's how, like the diehard suite. Diehard has been run on RdRand; try it yourself if you want.

Re:Here's your debate

[Anonymous Coward]

No, black-box RNGs and PRNGs cannot feasibly be verified, beyond ruling out particularly bad cases. Passing Diehard is a good start, but designing a stream that can pass Diehard while being 100% predictable is cake -- applying any strong block encryption to the values (1,2,3,...) in sequence ought to work. If you want people to trust your RNG or PRNG, you need to open up the design and let the appropriate experts (cryptographers, scientists, whatever) take a crack at it. A system that is mass produced isn't secure unless it's secure even when the whole system is understood (except for the secret key, for systems whose security is meant to depend on that).

However, the grandparent comment saying RdRand should be discarded is also off-base, as a commenter on the site already pointed out. RdRand is only a liability if it interacts negatively with the other sources it is XORed with, and that would be difficult to pull off -- it almost implies that the RdRand implementation understands its role in the larger program and knows how to subvert that. Not impossible, but unlikely.

Re:Here's your debate

[phayes]

We have a winner! Someone who complains that /. is fucked up but then adds his little heap of dung to the pile...

You're not just ignorant of the subject, you're also too self involved to learn by analogy & too lazy to learn by reading through the comments here. Even if RdRand is NSA compromised, it is at worst a no-op for the NSA & AS IT IS NOT USED ALONE, SECURITY IS NOT COMPROMISED. Also, the NSA isn't the only reason people use RdRand & until someone figures out precisely if/how it is compromised it is still valuable for all these uses.

you might want to reread the part in uppercase above a few times so that it can get trough all the screens you have setup to avoid learning...

Re:Marital/Money problems???

[Grishnakh]

That wouldn't be so bad if there actually were a datasheet, but instead everything's closed and proprietary, leading to pointlessly closed drivers as h4rr4r complained about.

Re:That's uncalled for, really.

[I'm New Around Here]

'"ARM SoC hardware designers all die in some incredibly painful accident."

I mean, maybe Linus hasn't had the experience of losing someone in an incredibly painful accident.

Well, how is he supposed to hope people die? Being batted by soft pillows while sitting in the comfy chair?

Re:Negotiation Skills

[gweihir]

And by disabling RdRand, you can only decrease security, so it would be pretty stupid to do so. But that requires actually understanding how an entropy pool works, something the petitioner does not. Basically, the only sane reason to disable it is for tests.

In fact of the sheer stupidity of the request, Linus was pretty friendly in its answer. He is also 100% right.

If you look at what Intel apparently wanted, namely drop the entropy pool and only use RdRandom (https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J), _that_ would have been highly problematic. But Theodore Ts'o actually understands how these things work and refused. I thought it was a pretty good call back then (and I seem to remember that Linus called this one wrong but learned better), and now it looks like it prevented a world of trouble. On the other hand, we now have strong indication that some Intel engineers have been compromised by the NSA.

Re:Negotiation Skills

[UnknowingFool]

There are parts of the kernel that were written by Google, IBM, Oracle, etc. Guess Linus is in a conspiracy with everyone! Here's the point you missed: All the NSA parts are open source and were reviewed before acceptance. It's not like they snuck in code when no one was looking. Many people have reviewed the code and found that it improved security. If you have evidence otherwise, submit. Otherwise, it is just paranoia on your part.

Evil Things RDRAND Could Do

[billstewart]

Yes, RDRAND could do evil things. It could go play Towers of Hanoi when you execute it. It could Halt and Catch Fire. It could email your MAC address to the KGB. So could any other instruction, if Intel wanted to be malicious, just when you thought it was safe to go back in the register pool.

If the NSA has convinced Intel to do evil things with RDRAND, the most likely one would be to hand out low-quality entropy when claiming that it's high-quality. It's still useful, and like any entropy source, it shouldn't be the only entropy source you use, and you shouldn't use it without hashing it together with a bunch of other hopefully-not-broken entropy. But it's still useful, and as somebody said, the NSA isn't your only enemy.

Especially when you're starting up a machine (physical or virtual), you really need good entropy and you don't have a lot of sources available yet. If you don't trust RDRAND, or even if you do, hash it together with some secret password and the clock and whatever else you've got.

Re:right, "cut their car brake lines" = level-head

[Anonymous Coward]

Let me spell this out for you. I'll use small words.

There is a style of humor where one says ridiculous things, with the understanding that these things are so patently ridiculous that the audience can understand that the things are not meant literally. Often, practitioners of this style of humor will go really over-the-top, mostly because this makes the joke funnier but also to make it crystal-clear that it's a joke.

This is one such example. If I genuinely thought Linus was setting up a murder on the ARM SOC designers, I would be concerned and upset. If I even thought there was a culture of fear and bullying, causing the ARM SOC designers to be unhappy, I'd be concerned. As it is, I was amused.

I suppose you were also upset over his trash-talking of CVS and Subversion in his Git lecture? "The problem with 'CVS done right' is that it leaves you nowhere to go... it's impossible to do CVS right." I think I laughed out loud at that one, but Nervous Nellies on /. were wringing their hands over this horrible hatefulness.

Let me predict your response. "Oh sure, the brake-cutting thing is a joke, but it's a mean, hurtful, hateful joke that will make people feel bad." I have to disagree. It's so wildly disproportionate that it's impossible for anyone to take it seriously, and I can't believe the ARM SOC designers are going to really worry about it.

Also, even with over-the-top dark humor, there are lines one doesn't cross; and Linus hasn't crossed those. It is not funny to joke about murdering or raping someone's family, for example; it's not funny to make jokes that remind people of horrible real-world atrocities; it's not funny to use offensive epithets related to race, etc. Linus didn't go there.

Also, if one or more of the ARM SOC designers were to trash-talk Linus back, he wouldn't get all bent out of shape about it; he'd be amused. (The Linux kernel is nontrivial, therefore it has some dark corners that are ugly. Someone could poke fun at Linus over those.)

Now if you will pardon me, I need to get back to work. Some of these bugs are so bad I'm going to hunt down the coders and remove their livers with a rusty spoon.

Were you ever bullied as a kid in school? Do you have a child in school being bullied? Remember how it made you feel? Yeah.

I was bullied sometimes. Mostly it was words but it got physical at times. Not a fond memory.

This is not remotely similar.

Re:Duct tape - it stops tinfoil from slipping!

[gweihir]

Well, in that case these Intel people would be completely incompetent with regard to security. You are right, possible they had that thought and are completely unaware of the consequences or they are so in love with their product they have gone blind to the real world. That would be even more dangerous.

Re:The price of godhood

[HiThere]

Troll or astroturfer?

The first couple of times this post appeared, I was willing to give the poster the benefit of the doubt. (Disagreeing with me isn't proof of anything, except, occasionally, common sense.) But essentially the same post has now repeated several times.

I'm beginning to tilt towards astroturfer.

Re:"I hope that ARM SoC hardware designers all die

[TechyImmigrant]

But this means it needs a custom kernel so adds complexity to an open source kernel like Linux when it has to work on a million different ARM based chips with undiscoverable busses.