Slashdot Mirror
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."
You have the source code, remove rdrand from the kernel yourself.
try We The People website.
The Truth Will Out!
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.
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?
World domination.. duh
~^\-/^|-|^\-/^~ May the force be with me!
"I hope that ARM SoC hardware designers all die in some incredibly painful accident"
Did Linus Torvalds just put out a hit on ARM SoC hardware designers? We report, you decide.
'"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. Of course it's hyperbole I know that but - these events actually really take place everywere, every day.
Someone who has no social skills but uses his persona to stay at the head of the ship.
In any other company, even if the owner, he would have been taken out to the parking lot and given a good hiding by every other employee.
Linux is a fantastic OS and has spawned a generation of users, programmers and eco system based on open source mentallity, it is just a shame such a social retard is allow to rant as he is.
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?
AntiFA: An abbreviation for Anti First Amendment.
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.
retrorocket.o not found, launch anyway?
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.
I didn't think God played dice.
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.
ARM SoC hardware designers world wide smile into their hand.
I am very small, utmostly microscopic.
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.
He complains about discoverable buses, and proceeds to say no. Then, he goes a tells the guy asking for change that he believes linux kernel maintainers/coders knows better (because according to him RdRandom is one of the many inputs to random pool) in his usual tone. Nothing new, and certainly not worth a headline IMO.
I don't care if I'm wrong. I only care about everyone obtaining something from the discussion.
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
Some people die at 25 and aren't buried until 75. -Benjamin Franklin
Linus has NEVER been courteous, it's why he can effectively manage one of the largest projects on the planet.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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
Can You Say Linux? I Knew That You Could.
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.
Muchas Gracias, Señor Edward Snowden !
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 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.
Brought to you by Carl's Junior.
It's not only an obnoxious guy, but an uneducated one. You can easily disable it with a compile time option already.
Do not look at laser with remaining good eye.
I took it more to mean he was complaining about their conflicting pull requests. Not breaking other users use of the kernel is job 1. Getting your shit in is job 2.
ARM SoCs present lots of problems to everyone who is not their designers I suppose. From the pointlessly closed drivers, oh wow an accelerometer, to the lack of any sort of way to probe hardware on boot. They seem to specialize in being a royal PITA.
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.
Program Intellivision!
Sure, why don't you get started on that?
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.
I get it, this is just a sexist comment to make us believe that soccer moms don't have any inclination to study C and Linux kernel programming.
It's probably likely that only a small percentage of the soccer moms have any interest in system-level programming, however you're being terribly stigmatizing to that small percentage.
I'm a man, so I can't comment, but I'd ask any soccer mom Slashdot reading programmers to give their input here on whether they think Linus acts like a 12-year-old dumbass or whatever.
To be, or not to be: isn't that quite logical, Slashdot Beta?
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.
Signature intentionally left blank.
Because a fucking soccer mom gives two flying fucks about who developed her operating system...while she is texting away on her android smartphone...
I agreed until you mentioned Android. Not that I feel that Android is bad but you should have said "while she is texting away on her smartphone..."
While I respect your technical prowess and make great use of your work, every time you go off like this, you move a little further down the "crackpot" scale. You know, the one anchored firmly by RMS...
Instead of blowing a gasket, why not nicely suggest that a read of the source code will show that rdrand is just one of the entropy sources used, and it is used in such a way that it cannot compromise the end result. Vitriol is no way to go through life, son.
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..
And believing stupid shit like this might have the slightest impact on why Linux adoption on the desktop is nearly zero and ignoring the real reasons why its nearly zero is why its nearly zero.
By my reckoning, I think next year will be the 20th year I've heard someone declare to be the year of the Linux Desktop, though, so lets just wait a few months and see!
Conveniently you could read either the kernel or the actual comment and get your answer. RDRAND is XOR's with the random data and does not contribute to the entropy pool.
Well hardware designers do not have this problem and don't feel the pain. HW guys care a lot about performance, power and cost. How the thing is made to work by SW is not their problem.
Linus should be bitching at the SW guys involved to fix this problem. Threatening the HW guys with death, while in keeping with his idiom, will have no effect. They're not reading this.
I'd read TMZ.
Man, I can't wait until the /. submitters discover Theo de Raadt.
If you were me, you'd be good lookin'. - six string samurai
Well the summary was apparently written with the authors testicles. It hurts my brain.
Because they will not give anyone those sheets.
Many of them go into phones where single microamps don't matter and at $600 each another $1 won't matter.
Hell, just burn the parts list into some silicon and let a single command retrieve it all. Then you don't need to be able to probe the separate devices at all.
The software guys really can't do much about it. If the hardware guys don't plan well. Unless you think the kernel should have multiple redundant drivers. That seems pointless.
There are other ways to generate random numbers if you need to do something secure. If you were say, getting a random number for a video game, I don't see any reason why you would care if intel subverted that in some way. I'm not a kernel developer, but it is my understanding that /dev/random does not rely entirely on rdrand. But I would imagine using rdrand is more efficient since it is built into the chip.
neorush
I believe one of the issues with this instruction as a source of random numbers is that the instruction whitens the output with no access to the raw entropy data. Any physical process that acts as an entropy source will have some (possibly small) biases - it won't necessarily appear to be completely random in particular ways.
This can be audited to see that the output conforms to the physical processes which are described.
If the instruction whitens the output through some algorithmic transform (e.g. hashing) to give apparently random numbers as output, there is no way to distinguish that from say encrypting a counter with a secret key - whose output will also appear to be random - but is trivially crackable if you know the secret key.
So it becomes an exercise in trust in Intel, rather than something which an be independently verified. There was a good comment on the cryptography mailing list about this - that it would be better to have hardware entropy sources, leaving the final steps of random number generation to software.
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.
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:
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.)
The first bit regarding RdRand was inappropriate/rude, but the second half regarding ARM SoC developers most was beyond inappropriate without a doubt. He suggests twice that they're worthy of death, suggests specific methods of murdering them. Here's the bit the submitter didn't include:
"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?"
Linus went out of his way to be nasty and insulting; it is not necessary nor acceptable to treat others in such a way. This kind of behavior has come up before here on Slashdot, and it is still immature, abusive, and mean-spirited.
Linus is exploiting his social status to bully others and I'm tired of people making excuses for it, particularly because he's in a leadership position and serves as a role model to many. The Linux dev community needs to stand up to language and behavior like this, or otherwise the message to young/new programmers they can/should act this way if they're successful enough, and if they're the target of such nastiness, the community will accept and condone it.
In general, I'm tired of excuses being made for bullies simply because they're valuable. Linus is no different from the varsity football star who goes around slamming people into lockers; a gorilla beating his chest. 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.
Please help metamoderate.
Just the ones who put in non discoverable busses. So he got that one about right,
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
KERNAL, it's where Linus goes to when he gets pissed.
It's not XORed. It's mixed in with a twisted LFSR which is only less wrong.
XORing works if the sources are completely statistically independent. Nothing in this world is completely statistically independent. So learn some crypto and use a proper entropy extraction algorithms. Linux should do that too.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
It doesn't do that. What makes you think it does?
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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!
-- Using the preview button since 2005
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.
"...after 20 years of work..."
All the most corrupt people start off as idealists.
But I've never seen Torvalds as an idealist, so I'm not sure that this is relevant.
And note that not all idealists end up corrupt - RMS seems to have stuck to his guns.
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.
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.
If you take one bit from one source, then one bit from the other source, and one of the sources isn't random, you lose half your randomness.
Thats not how it works. If one of those sources is unpredictable and random, it does not matter how predictable the other source is-- you will have no additional info on what the output is.
According to the follow-up question in the petition by Dale Emmons it is XOR.
Like Hans Reiser's Wife, eh?
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You're confusing two issues here:
1) autodiscovery - I agree with you, except 1) it helps only in limited quantity if each SoC out there does this (and does it differently), 2) we know from PCI & USB that better solutions exist. This probably needs to happen within ARM (as they own the AXI/AHB bus IP usually implemented), and as such ARM SoC HW designers are customers themselves with no control. Yes, ad hoc may be necessity for now, IF the right people know of the problem.
2) Hiding datasheets is an entirely separate issue. There are many reasons for this, most have to do with our "friends" over in China and other places whose labor costs are so low, and whose employment conditions are so horrid that they are a threat to the tremendous investment done in the western world. The traditional solution is to hide as much as possible, and force them to steal (which they do a lot) or recreate it. They then stay far enough behind that R&D costs are recouped. This usually ends up wrapped in legal agreements. It seems like an accelerometer is trivial to you, but there's probably a 100 person shop in california somewhere that spent a million or two to develop, harden and characterize it, and who may need 5 years to make that back.
Hardware doesn't always jive well with open-source. But again, Linus's particular concern probably could be resolved in several different ways and he may not care if the accelerometer support never shows up, as long as it's discovered cleanly and ignored rather than through mutually exclusive and abusive hacks.
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.
And you can't even get to RNDRAND directly - you have to access it through Intel's "magic box in the middle that salts the hardware RNG with some magic FIPS algorithm involving some "secret" Intel key" - Jake Hamby.
But, sure, mix it in to the pool.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I don't know anything about how RDRand works so this may be a stupid question, but would it be possible for someone to write a drop-in replacement for it?
The problem is, not all places in the kernel mix RDRAND output. After GKH's fixes, /dev/random does, but get_random_int() does not.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
*Unless* the other source is correlated with the random one.
"Linux Torvalds says something AGAIN that would get him fired from VIRTUALLY ANY COMPANY ON EARTH, and Slashdot fanbois rush to SUCK HIS DICK so hard it breaks".
Look... Linus is a super-genius that has accomplished more in half a lifetime than most of us will accomplish in our ENTIRE lifetime (and this is coming from someone who has 7 published tech books and an 8th on the way- an accomplishment that itself dwarves most other peoples', yet is almost nothing next to what Linus has done)... he is virtually always right when he says something technical and he deserves to be listened to on any technical topic he chooses to speak. His name will echo through the halls of technology history for decades to come, and rightly so. He deserves every accolade he gets.
Yet, with all of that being true, he's a socially-inept bully, plain and simple. If only he could solve that problem with clever algorithms and architectural knowledge, he'd probably be up for sainthood already. Instead, he embarrasses himself every time he opens his mouth in this way, and so do you if you defend him. Belittling people, even when they are completely, amazingly, HOPELESSLY wrong about something, is simply not acceptable.
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Aside from codename coincidence is there objective evidence RdRand is compromised?
Some degree of paranoia is healthy, certainly Eugen's stand against RdRand bypass of the entire entropy pool is sensible if for nothing else than to protect systems against any innocent defects which may exist in RdRand.
It is however difficult in the absence of supporting evidence to see how unbounded paranoia can be useful.
For all I know removing RdRand outright out of unsubstantiated fears is what the NSA is banking on.
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.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Not all of us are as excited as you about the politically correct world we increasingly find ourselves surrounded by.
There was a time when being mean-spirited towards people based on their religion, their language, or their skin color was deemed socially acceptable. Those days are long gone.
Now we're approaching an era when being mean-spirited towards people based on their incompetence or their ignorance is socially unacceptable. Pretty soon, it won't be acceptable to be mean-spirited towards anyone. Not idiots, not rapists, not murderers.
Some of us dread that day. Some of us see the argument that you set forth and want nothing more than to say "Fuck you, Nancy. Fuck you very much."
I'm tired of society bending those of us who are thick skinned and can handle hearing critical messages to the will of the weak. If you can't grow a pair and brush off offensive language, that's your problem. It's rather inconsiderate for you to burden the rest of us with your weakness.
Chuuch. Preach. Tabernacle.
A random source by definition is not correlated with anything. If it is, then it isnt random.
Given a random source, you can produce another source correlated with it.
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
When dealing with computers, spell things right. When dealing with people, don't insult them unless there's an unusual reason. When dealing with people who are wrong, all that you need to say is "You're wrong".
change.org is an independent site. It may have a mostly US focus, but it certainly does not serve solely to petition the US Government... Also once you vote for an issue, they spam you with all sorts of stupid crap like "My Sister got fat eating McDonald's Fries and then got diabetes and then lost a foot to neuropathy! We need to do something about this!".... Sure there are good causes out there, but most of them follow a "I want to complain about my own poor life choices or the poor life choices of a loved one! Find me someone to blame who will pay me millions in damages!" trend...
Maybe you confused it with the White House's "We the People" petition system? The one where the White House has to respond with an official statement (or non-statement) to anything with more than 50,000 unique signatures?
One could argue that, but that would be stupid.
Let's recount: if rdrand is not compromised, we're getting a huge boost in entropy, if it is - we're still getting a boost in entropy, at least vs. those not having keys to rdrand's possible backdoor, and by mixing it with other sources we're not helping those too.
It _doesn't_ stand to reason to remove a component that's only "suspect" in sense of "Well, Intel's a big US company, amirite?..", but which is a net gain whether suspicions are true or not. It is like chopping off your hand because you scratched a finger just now and fear gangrene.
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.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Don't be lazy, read the discussion for yourself. The gist of it is that in gathering entropy for crypto, it never is a good idea to only use one source of entropy. That this is a black-box source that could have easily been tampered with is besides the point. If you want to know more, read up on cryptographic PRNGs and the countless broken implementations of the past. And no, /dev/random is fundamentally different, because it uses multiple, different sources and it is not a black box.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Check out the code names.
Kind of hard to believe Intel could be coerced into including a sneaky key into their hardware.
Either trust it - or use something else.
All your ghosts are just false positives.
...there's bigger issues at[sic] foot with things like microcode.
RDRAND is the bigger issue because trying to validate RNG output is essentially impossible. OTOH, most other types of CPU output are easily verifiable and any accidental triggering (easy to do in a general-purpose part put into thousands of different configurations and applications) of surreptitious behavior in some CPUs would eventually happen under the watch of people who know how to detect and single-out discrepencies (i.e. there's too high a risk that other types of tampering would show, especially when most environments are bound to have significant numbers of both compromised and non-compromised CPUs).
AES belongs in the verifiable category: Give different AES implementations the same (random-seeded) input, and you should get identical output. Its nothing like random number harvesting in that regard.
I agree with Linus' take that XOR'ing RDRAND with the rest doesn't compromise the kernel's random output--it can only push it toward more randomness, not less-- though relying on one reasonable assumption: That the chipset is not rigged somehow to reduce the randomness of the timings of data flows. I believe there is very little room for tampering here (after all, it would not do to cause large delays or even screw-up data in the process) and the difference in the raw data's quality should be detectable.
You're basically right. However...
I've got to wonder if its possible for the chipset to starve the kernel of randomness as well, by making the timing of data flows more regular. These days, the chipset maker is usually the same as that for the CPU.
It seems like that would be detectable (and would degrade system performance, too)... but would they try it?
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.
That's exactly right. Even if the hardware RdRand has a "work reduction factor" built in, i.e. it's not as random as it seems to be, there's some randomness there, and it can be fed into the entropy pool along with other sources of randomness.
Randomness sources inside deterministic computers are scarce. Disk timing, clock jitter, network arrival times, etc. are useful, but generate random bits at a low rate. Thus, "/dev/random" will block if not enough random bits are currently available. This usually isn't a problem, but if every TCP connection you open is SSL and you need random bits for key generation, the supply could run out. If, say, you wanted to fill a DVD with random bits for a one-time key system, /dev/random would probably be a bottleneck. Is Torvalds making that argument?
There's another application of randomness. The only known theoretically unbreakable cryptosystem is a one-time key system where 1) the keys are truly random and 2) are used only once, 3) then destroyed. One time key systems have been broken in practice due to violations of each of those rules. Venona violated rule 1 and 2, and there have been spy cases where the spy hadn't destroyed their keying material when captured.
A reasonable cryptosystem is to make two identical DVDs of random bits. Each party has a DVD, and they can communicate as many bits as they have random bits in common. This is a pain, but it works. Such systems are used by the US for embassy-to-capital links. In the paper-tape era, this was a huge pain, but a DVD can store enough data for a thousand hours of phone calls.
Any reduction in randomness in a one-time key system makes it very vulnerable. It doesn't take much to provide an entry into the cypher.
1. Random numbers exist in theory not reality. 2. Given #1 We settle for "sufficiently" random. 3. Our tools for #2 are predictable, given the method and parameters at time of generation, we only need to corrupt or derive the seed. 4. Given #3 we either use the tool that creates #2 or we create one that is as "good" as #2. 5. Some idiot who believes #2 or #4 is an infallable solution needs to relearn statistics and probablity and rethink #1. (The answer is 42) All "random" generation systems can be corrupted into predictability. The fact that a CPU instruction can be subverted through design or microcode does not negate "good enough".
Just the ones who put in non discoverable busses. So he got that one about right,
If you follow the thread a bit you'll find some reasonable explanation why we have non-discoverable buses. The vast majority of sensors and devices use stuff like I2C and SPI, which simply does not support discovery and never will. It has nothing to do with ARM SoC.
The whole point of a SoC is to as cheaply as possible make a system that does one particular thing and make it as small and power-stingy as possible. Every system is by definition a custom one-off. It will have random I2C devices on random pins, and a bunch of magic arbitrary GPIOs that control stuff.
Not really. But something far worse can happen: The environment can be virtualized. In such a case RDRAND is highly desirable, as it still works at full capability (whatever that may be), while a lot of other entropy sources become significantly degraded.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Yes, this was an ongoing concern with Qubes for a while, then Xen got a patch to address the problem.
So.. some comments say that we can't know for sure if RdRand is flawed because NSA could tell Intel to do it etc... but can't we really? There are standard methods for checking if RNG is working OK or not.. the most simple one is to run a huge number of tests and see if the result is uniformly distributed. Surely it would be hard to see the actual implementation on hardware level but we don't need to see it.. we only need to know if it is statistically random. What am I missing? See also http://en.wikipedia.org/wiki/Randomness_test, http://en.wikipedia.org/wiki/Diehard_tests
Now we're approaching an era when being mean-spirited towards people based on their incompetence or their ignorance is socially unacceptable.
I think we've been in an era for a long time where it is inappropriate to wish others dead simply because they design computer hardware in a way that you don't like. Designing embedded computers in a way that is appropriate for embedded computers but not desktop systems is neither ignorant nor incompetent, per se. To paraphrase so many of the posters here regarding RdRand, "if you don't like that hardware, don't use it."
Your desire to classify this as simply "being mean spirited" is the era we do not want to approach. Refraining from wishing others dead "in painful ways" is hardly political correctness, especially when the reason you want them dead is a disagreement over a CPU design. It's called basic human decency, and it will, I hope, never disappear no matter how much you'd like it to.
If you bothered to read the e-mails from the actual hardware designers in the linked thread (I know, I know, I'm new here and I should know that nobody ever reads anything), you would have seen that the things you are saying in your posts have no relation to the reality of the situation. The hardware people said that they know very well the way they're doing things makes it difficult for the software and they gave their reasons for doing it this way. Whether we agree that the reasons are valid is a seperate question, but your claim (that they are not aware of the fact that this causes the software to be a mess) is simply wrong.
But attacking ARM SoC makers wasn't an attack on ignorance or stupidity. He's just annoyed because their design isn't the design he'd prefer to have. He wants these ARM boards to be like PCs with a big system style rather than the chaotic world of embedded systems and SoCs. The outburst is more of a sign that Linus is over stressed and needs a long vacation (or retirement) rather than someone doing something stupid that needed to be pointed out.
It also means that many people who would otherwise want to port Linux and contribute to it might head off to platforms like NetBSD instead. A willingness to endure abuse may be a requirement as a side show act but it shouldn't be necessary to participate in open source development.
Those aren't the chips he's complaining about though. Most ARMs go into small special purpose embedded systems. They may be $3-$10 each, with people fighting to get the cost even lower. The software knows exactly what the software and what devices are connected to it. Very often the company using the ARM has contracted with someone to create a SoC to their specifications. And yes, you always get the datasheets if you're the system designer (and easy to find if you're not).
If you want to see fights, see the ones between software/firmware people fighting their fellow employees who designed the hardware. It's an old problem. System gets designed as bare bones as possible then software/firmware has to work around the problems with it. Even when there are outright bugs in the hardware the designer just shrugs shoulders and says "deal with it". Worst part is I think the hardware people design based on requirements and plans in year X but then software starts implementing in year X+1 after the requirements have changed.
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
Perhaps some BSD derivative might be more appropriate. The impression I got (admittedly, I'm full of ignorance on the subject) is that Linus though the ARM SoC designers were intentionally designing systems to be incompatible. Perhaps I'm wrong?
OTOH, various past experiences have prepared me to believe that LOTS of companies want to set up a walled garden, and want someone else to provide the software to make it work. I have scant sympathy for any misfortune that happens to someone like that.
I think we've pushed this "anyone can grow up to be president" thing too far.
Xen does /dev/random pass-through? Good to know!
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Most embedded systems are not designed to be compatible with each other, that's true. But that's also normal. They're not being built as general purpose computers. Not that they're intentionally incompatible but because there's no need to be compatible.
I have used Linux personally and professionally since 1996. I have immense respect for Linus and his amazing operating system.
Because I have a lot of experience with the innards of operating systems, last year I began a personal project to [re]develop a small part of TCP/IP that has been excluded from the network stack, with the idea of convincing the Linux folks to merge this bit of code back into the stack.
However, after seeing numerous reports of Linus' behavior, I ditched the project and decided to go into ham radio instead. I don't need anyone screaming at me, irrespective of the quality of the code produced.
The ham radio community is generous with their time and knowledge and I haven't met the first screamer.
Circle the wagons and fire inward. Entropy increases without bounds.
Nice guy.
This is linux, it is trivial to create a random number generator hardware device and have it a part of /dev/random anyone relying on any commodity hardware is NOT truly interested in security.
http://www.robertnz.net/true_rng.html
I really like the "random number CD" that has a pregenerated 600mb of numbers, kind of like a 1 time pad. actually that would be brilliant, mail your reciever the CD and use it as the 1 time pad source for all your communication.
Do not look at laser with remaining good eye.
Some people contribute to the world in ways other than Linux kernel development.
Stop being a coder snob.
Just because it CAN be done, doesn't mean it should!
Not to mention that Linux runs on more types of hardware than any other O/S kernel.
Linux also dominates the embedded, mobile, & server markets.
If you count actual instances of Linux installed across all devices, then Linux is more more mainstream than all the other O/S's put together!
So how is Linux _NOT_ mainstream?
Can we use a Justin Bieber CD? It is mostly white noise.
Just because it CAN be done, doesn't mean it should!
Anyone who thinks that Linux is an OS developed by some 12-year-old dumbass, does not deserve from the benefit of using Linux.
I wish I was good enough to writer something like Linux, at any age! Hell, I wish I was at least good enough to submit a patch and have Linus be rude to me - if my patch was either totally useless or perfect in all respects, then I would hear nothing back.
It simply means not being a petty, insulting git.
Linus named his source control program "git", was it in "honor" of himself?
Just because it CAN be done, doesn't mean it should!
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Yes, it was:
Quoting Linus: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'".
Chuuch. Preach. Tabernacle.
I think we've been in an era for a long time where it is inappropriate to wish others dead simply because they design computer hardware in a way that you don't like.
Die in a fire.
Chuuch. Preach. Tabernacle.
There is absolutely no reason to be "mean spirited" to any person at any time.
Die in a fire.
Chuuch. Preach. Tabernacle.
I agree with all of your points regarding the ARM SoC issue, but regarding the RdRand issue Linus was spot on.
However, my point wasn't so much about Linus being justified in his actions or not. It was about society becoming emasculated.
The other two replies to my comment really highlight this fact; overly sensitive people whining about how something is "inappropriate" or appealing to "basic human decency" or calling out "mean spirited bullies" or fretting about "dehumanizing people". Our ever-more-comfortable society has led us to become so far removed from natural existence that talk like this has become commonplace. People feel butthurt about Linus calling people names as though it's some crime against humanity, forgetting about the existence of things like sex slavery, wars, or genocide.
All I'm saying is (and this isn't directed towards you, Darinbob): if Linus's rants hurt your feelings, I hope you never have to feel real pain. It would crush you.
Chuuch. Preach. Tabernacle.
California (and probably many other states as well) allow the [i]public[/i] to create and present to the voters, laws which the legislature never considers. Many such laws have been passed. The end result is a few good laws get passed, tens of millions of dollars get spent on elections, and many laws get passed, overturned by courts, and otherwise just don't work.
While Linus may or may not be arbitrary, may or may not be obnoxious, may or may not be overbearing, he almost certainly knows more about the subject and it's viability than people who come across and sign a petition on change.org withoout taking the time to fully understand it.
It doesn't do that. What makes you think it does?
Parent it saying it's not supposed to do that, but it *could*. What makes you sure it couldn't?
Watch great movie opening scenes!
Randomness is a resource, you have to obtain it from somewhere. CPUs are explicitly designed to -Not- be random, in operation. To use a CPU to generate a number, is not something that should be depended upon to be random.
A real random number generally requires separate hardware, such as noise from a stressed diode.
That said, if a program wants to use a documented instruction it should be able to. If you want good crypto just don't use that instruction. It is not the job of an OS to prevent programs from running.
>What makes you sure it couldn't?
I designed it (the SP800-90 part - much credit goes many other people for other parts). I understand the organization within which it was designed and manufactured. I know the vectors through which it could be subverted. It hasn't been subverted. I'd notice.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Good for you! Interestingly, your message confirms RdRand *could* be subverted. Luckily now we also know that you would notice, and I'm sure in that case you would let us know ;)
Watch great movie opening scenes!