There is no way we can blame Javascript, or any orther language, for exploits made possible by faulty/unreliable hardware. The RAM chips in this case.
Let's face it, if you CPU or RAM or other components have such failings it's all bets off no matter what software you have.
My question is, how do we avoid buying or otherwise getting such RAM into our machines? Testing RAM is amazingly difficult if not impossible. Especially considering how conceptually simple it is.
It certainly is progress to hear that they are getting native compiled C/C++ like speed out of the JS engines now a days. I still think that is amazing.
I can imagine Ford saying that. "We have pushed materials science hard, kept cost low, sorry our cars are now so flimsy they fold up at any little bump in the freeway at speed".
Something has to give. I'd rather it was not the products we buy failing at random.
Ford is required by law to insure performance minimums, and that law exists due to this problem. There are big CAE clusters there very regularly crash simulating cars. That is actually darn cool stuff.
Of course the risks are high too. Makes sense to insure cars aren't cut just a little too thin.
Electronics do not always present the same risks. Sometimes they do though.
In another life, long ago, the young Heater, being the green horn on the team, was tasked with creating some memory tests for a embedded product. Power up self test and even run time tests. What could be easier? Memory is simple, you just write it and read it, much simpler than all the other complex hardware in the system, right?
Wrong. I lost a lot of sleep over that problem. Until I realized, and was shocked to realize, that it is basically impossible.
Let's say you have a paltry kilo bit of memory. To be sure that it works you need to write every possible combination of 1024 bits to it and read them back successfully. That's 2 to the power 1024 writes and reads of the entire memory. Or a 300 odd digit number in decimal or 250 orders of magnitude more than the number of planets in the universe!
But it's worse. Not only do you have to check that you can write every possible state to the memory you have to check that you can transition it to every other allowed state (with an 8, 16 or 32 bit write of anything to anywhere).
But it's worse. What if there were some weird malicious logic in the memory such that it could pass all those tests, but it sneakily detected some sequences of reads and writes which triggered a memory corruption?
Well, that was a military project that dealt with encryption and security so they were paranoid about such faults and I did think about it a lot.
Blow me down, decades later comes this DRAM bit flipping security exploit. And it is exactly that "weird malicious logic" in the devices that I speculated about all those years ago.
In a way, given the impossibility of the task, I almost can't blame the manufacturer for this fault.
Seems to me, the much higher cost of military grade devices would be one example where the extra testing, or use of much more conservative, or just older and more robust process physics plays out differently. Back in the 90's, a company I worked for got these great, or supposedly great, servers featuring large quantities of RAM for what seemed like a seriously good price!
Fast, cheap, and good?
Not so fast. At the time, I looked at the thing casually and didn't see the catch right away. Thought maybe they were competing on margin, or had figured out some clever tech optimization or other.
A few months later, nobody could explain those servers just doing odd things. Nothing specific, just oddities.
THERE WAS NO PARITY ON THE RAM!
Worse, this was a fairly technical team. They were adept at things like high end computers, IRIX, advanced CAD, Internet. Smart cookies.
Nobody really understood why the parity bit was needed, and apparently, at least one group founded a company on the idea that RAM was a perfect thing.
When I whiteboarded the basics of the CPU and RAM and highlighted the problem, they were all kind of stunned.
So it was fast and cheap, but no good.
Interestingly, I put Red Hat Linux on it. Had it doing mail, web, and a few other things just for grins. A look in the syslog of that box was amazing. The kernel was generally pissed most of the time, recovering from this and that, but there were no real worries. That no parity machine performed nicely enough on Linux.
But it ran a little slower too.
I thought that a very notable dynamic. Better (at the time) kernel / OS capabilities basically compensated for error prone RAM well enough to make the machine useful. Not that it should be used. Just that it could be used. Was some good OSS advocacy at the time.
Win NT 3.51 and 4.0 both slowly went senile on that box. Would run good, but over time, just fail hard. And fail in an amazing number of ways.
RedHat just worked.
That box ended up under my desk as a testing type machine. We, a few of us techs upstairs, would to torturous things to it. Vacuum the floor. Run it on low voltage. Block all the vents. Hit it. Whatever. If it still played our mp3 file share, great! Next "test" It endured our abuse for a coupla months, and then ended up in the trash bin.
What I wonder about these days is the more aggressive processes used and how they will endure. My Apple, Atari, Color Computer, Tandy Model 100, all work just fine. Some of that stuff is 40 years old. Sometimes I gotta replace a cap, but not often. They get powered up enough to seemingly stave off that issue, or they just had good caps. I don't know.
Where things like cheapo Internet routers, Netbooks, and such seem to die after a few years.
Is there a digital wave of death coming for specific processes? Old NMOS, CMOS designs, and even the P1 we use today are using HUGE process details. I don't think they will die anytime soon. When the 6502 chips start failing, we might get a hint on that.
But these new things? They might not go 10 years, or 20. Who knows?
Yes, whatever happened to parity checking and ECC on RAM ?
Back in the late 1970's all the RAM on the military minicomputers I dealt with had parity on RAM. In fact every RAM board in the rack had a red parity LED on it.
By the late 1980 I was reading everywhere that chip scales were getting so small that memory bits would be flipped by cosmic rays and background radiation so parity or ECC would be essential to get them to work reliably.
Today, we have features sizes orders of magnitude smaller, huge amounts of RAM, and I see no parity or ECC anywhere!
What happened? Was this a non-problem all along? Or did it get just get swept under the carpet in the name of economy and well "the consumer won't notice"?
I was thinking about this recently after hearing details of a couple of catastrophic failures that brought down whole server farms. One at Google and one at Amazon (if I remember correctly). In both cases the failures were traced to flipped bits that propagated around the systems bring down node after node. The conclusion of both presentations was "checksum everything".
...the biggest cause of soft errors today is cosmic rays....Unfortunately, the PC industry has largely failed to recognize this cause of memory errors. Electrostatic discharge, power surges, or unstable software can much more easily explain away the random and intermittent nature of a soft error, especially right after a new release of an operating system or major application....
So there we have it. Soft RAM errors are a problem and it was sept under the carpet.
I think I'm going to try an experiment:
1) Get some simple RAM test running on a Raspberry Pi.
2) Put the alpha emitter from a smoke detector on top of the RAM
Wait for errors
Although I'm guessing alpha particles don't make it through the chip packaging much.
If we can get 1% of the emissions out of say, a smoke detector source, and through the RAM chip packaging (very thin on a Pi RAM chip) perhaps we can see an effect. Given enough time...
If not, it's time to fire up that big old CRT and catch a few x-rays out of it
Heater - have you run across something called ScriptCraft? It enables people to script Minecraft with Javascript. So you can either type in short snippets interactively, or write full blown Minecraft mods. A company in San Diego out of UCSD (LearnToMod) is using this along with a blocky interface to enable kids to mod from their browsers, but ScriptCraft is open and on github. There has been some recent drama in the Minecraft server world, but writing mods in javascript has to be much more enjoyable than in java.
The absolute worst thing about JavaScript are all the frameworks (e.g. Dojo, jQuery, AngularJS, etc) its fans create. Why?
The lifespan of a typical framework is far shorter than the typical lifespan of a software project. So when it starts Backbone is hot, everyone wants to write it in Backbone because only geezers use Dojo. About six months in Backbone is for heretics and AngularJS is the one true framework.
Now even if you try to avoid the churn it is almost certain the business partners will see some hot widget written using the new framework and you have a messy migration problem.
Then there's the build tools. NPM is the one true build tool, no it's Grunt, no it's Gulp. Don't even get me started on all the nearly identical unit test and mocking frameworks.
(1.HHGTTG 11,59) The pink cubicle had winked out of existence, the monkeys had sunk away to a better dimension. Ford and Arthur found themselves in the embarkation area of the ship. It was rather smart.
Comments
That someone can use JavaScript to attack your DRAM.
Let's face it, if you CPU or RAM or other components have such failings it's all bets off no matter what software you have.
My question is, how do we avoid buying or otherwise getting such RAM into our machines? Testing RAM is amazingly difficult if not impossible. Especially considering how conceptually simple it is.
It certainly is progress to hear that they are getting native compiled C/C++ like speed out of the JS engines now a days. I still think that is amazing.
As for the DRAM, we have pushed the process physics hard, kept cost low, and something has to give.
Something has to give. I'd rather it was not the products we buy failing at random.
Avoiding it is one reason I try hard to not always make it about price in my life, and I support others who do the same and focus on value.
The cheapest thing with the thinnest margins is not always the best value. It is not in far more cases than I realize sometimes.
And everything costs something. Sometimes that pops up in surprising ways.
Of course the risks are high too. Makes sense to insure cars aren't cut just a little too thin.
Electronics do not always present the same risks. Sometimes they do though.
In another life, long ago, the young Heater, being the green horn on the team, was tasked with creating some memory tests for a embedded product. Power up self test and even run time tests. What could be easier? Memory is simple, you just write it and read it, much simpler than all the other complex hardware in the system, right?
Wrong. I lost a lot of sleep over that problem. Until I realized, and was shocked to realize, that it is basically impossible.
Let's say you have a paltry kilo bit of memory. To be sure that it works you need to write every possible combination of 1024 bits to it and read them back successfully. That's 2 to the power 1024 writes and reads of the entire memory. Or a 300 odd digit number in decimal or 250 orders of magnitude more than the number of planets in the universe!
But it's worse. Not only do you have to check that you can write every possible state to the memory you have to check that you can transition it to every other allowed state (with an 8, 16 or 32 bit write of anything to anywhere).
But it's worse. What if there were some weird malicious logic in the memory such that it could pass all those tests, but it sneakily detected some sequences of reads and writes which triggered a memory corruption?
Well, that was a military project that dealt with encryption and security so they were paranoid about such faults and I did think about it a lot.
Blow me down, decades later comes this DRAM bit flipping security exploit. And it is exactly that "weird malicious logic" in the devices that I speculated about all those years ago.
In a way, given the impossibility of the task, I almost can't blame the manufacturer for this fault.
Now that we know, it can be addressed.
There are surely others lurking around our tech.
And that dynamic is why such intense records are kept for auto and aerospace and similar efforts.
Seems to me, the much higher cost of military grade devices would be one example where the extra testing, or use of much more conservative, or just older and more robust process physics plays out differently. Back in the 90's, a company I worked for got these great, or supposedly great, servers featuring large quantities of RAM for what seemed like a seriously good price!
Fast, cheap, and good?
Not so fast. At the time, I looked at the thing casually and didn't see the catch right away. Thought maybe they were competing on margin, or had figured out some clever tech optimization or other.
A few months later, nobody could explain those servers just doing odd things. Nothing specific, just oddities.
THERE WAS NO PARITY ON THE RAM!
Worse, this was a fairly technical team. They were adept at things like high end computers, IRIX, advanced CAD, Internet. Smart cookies.
Nobody really understood why the parity bit was needed, and apparently, at least one group founded a company on the idea that RAM was a perfect thing.
When I whiteboarded the basics of the CPU and RAM and highlighted the problem, they were all kind of stunned.
So it was fast and cheap, but no good.
Interestingly, I put Red Hat Linux on it. Had it doing mail, web, and a few other things just for grins. A look in the syslog of that box was amazing. The kernel was generally pissed most of the time, recovering from this and that, but there were no real worries. That no parity machine performed nicely enough on Linux.
But it ran a little slower too.
I thought that a very notable dynamic. Better (at the time) kernel / OS capabilities basically compensated for error prone RAM well enough to make the machine useful. Not that it should be used. Just that it could be used. Was some good OSS advocacy at the time.
Win NT 3.51 and 4.0 both slowly went senile on that box. Would run good, but over time, just fail hard. And fail in an amazing number of ways.
RedHat just worked.
That box ended up under my desk as a testing type machine. We, a few of us techs upstairs, would to torturous things to it. Vacuum the floor. Run it on low voltage. Block all the vents. Hit it. Whatever. If it still played our mp3 file share, great! Next "test" It endured our abuse for a coupla months, and then ended up in the trash bin.
What I wonder about these days is the more aggressive processes used and how they will endure. My Apple, Atari, Color Computer, Tandy Model 100, all work just fine. Some of that stuff is 40 years old. Sometimes I gotta replace a cap, but not often. They get powered up enough to seemingly stave off that issue, or they just had good caps. I don't know.
Where things like cheapo Internet routers, Netbooks, and such seem to die after a few years.
Is there a digital wave of death coming for specific processes? Old NMOS, CMOS designs, and even the P1 we use today are using HUGE process details. I don't think they will die anytime soon. When the 6502 chips start failing, we might get a hint on that.
But these new things? They might not go 10 years, or 20. Who knows?
Yes, whatever happened to parity checking and ECC on RAM ?
Back in the late 1970's all the RAM on the military minicomputers I dealt with had parity on RAM. In fact every RAM board in the rack had a red parity LED on it.
By the late 1980 I was reading everywhere that chip scales were getting so small that memory bits would be flipped by cosmic rays and background radiation so parity or ECC would be essential to get them to work reliably.
Today, we have features sizes orders of magnitude smaller, huge amounts of RAM, and I see no parity or ECC anywhere!
What happened? Was this a non-problem all along? Or did it get just get swept under the carpet in the name of economy and well "the consumer won't notice"?
I was thinking about this recently after hearing details of a couple of catastrophic failures that brought down whole server farms. One at Google and one at Amazon (if I remember correctly). In both cases the failures were traced to flipped bits that propagated around the systems bring down node after node. The conclusion of both presentations was "checksum everything".
Interestingly a google search just now for "PC RAM parity ECC" does not include any discussion of this in the last five years in the first page of results. But I find this interesting article from 2010: http://www.quepublishing.com/articles/article.aspx?p=1416688&seqNum=8
And I quote:
...the biggest cause of soft errors today is cosmic rays....Unfortunately, the PC industry has largely failed to recognize this cause of memory errors. Electrostatic discharge, power surges, or unstable software can much more easily explain away the random and intermittent nature of a soft error, especially right after a new release of an operating system or major application....
So there we have it. Soft RAM errors are a problem and it was sept under the carpet.
I think I'm going to try an experiment:
1) Get some simple RAM test running on a Raspberry Pi.
2) Put the alpha emitter from a smoke detector on top of the RAM
Wait for errors
Although I'm guessing alpha particles don't make it through the chip packaging much.
But is that "blocked" or "mostly blocked"
If we can get 1% of the emissions out of say, a smoke detector source, and through the RAM chip packaging (very thin on a Pi RAM chip) perhaps we can see an effect. Given enough time...
If not, it's time to fire up that big old CRT and catch a few x-rays out of it
We should have a party.
https://web.archive.org/web/20080213171613/http://wp.netscape.com/newsref/pr/newsrelease67.html
Sigh, you missed it.
"We should have a parity."
Yes, that was my type of parity too.
The lifespan of a typical framework is far shorter than the typical lifespan of a software project. So when it starts Backbone is hot, everyone wants to write it in Backbone because only geezers use Dojo. About six months in Backbone is for heretics and AngularJS is the one true framework.
Now even if you try to avoid the churn it is almost certain the business partners will see some hot widget written using the new framework and you have a messy migration problem.
Then there's the build tools. NPM is the one true build tool, no it's Grunt, no it's Gulp. Don't even get me started on all the nearly identical unit test and mocking frameworks.
(Origin: http://www.dailymail.co.uk/news/article-3129629/Nessie-elephant-Loch-Ness-Monster-gets-run-money-jumbo-going-swim-underwater-Botswana.html)
(1.HHGTTG 11,59) The pink cubicle had winked out of existence, the monkeys had sunk away to a better dimension. Ford and Arthur found themselves in the embarkation area of the ship. It was rather smart.