We used to have a lot of Motorola, but now that Intel dominates the market, most processors are little-endian. Not a defined standard (why would we make one), but a kind of standard by popularity.
And even if we had an open source CPU, the fix wouldn't be any faster: the "bug" (actually design issue) that has been existing for 20 years, is based on having as much speed as possible, while keeping data safe (data is not "retired" if it's not supposed to be seen by the user). And that work(ed) well. These new attacks based on the time taken by the CPU to load some data into the cache, or not if it's there already, are subtle, really clever, and the fix at the CPU level requires a lot of deep changes.
I like this comment "Don't these kernel updates get any testing? I realize that CentOS may have very limited resources for testing, but doesn't Red Hat test these updates?". What? Maybe it compiled just fine!
This is not how it worked. Intel has been aware for quite a long time, a year or more probably. Google found the problem in June, and vendors were made aware around that time. If it wasn't for Google, the issues would probably still be kept secret by Intel (until a hacker or another country find and take advantage of the vulnerability). Intel should have informed vendors a long time ago, like Google did, without of course making the issue a public story until a fix is installed. But Intel admitting the flaw would have triggered many compensation requests. This is one reason why the class action makes sense.
Intel PR seems to forget that they sell CPUs not (usually) to the final end user, they sell them to PC manufacturers or computer skilled people. None of these persons would be fooled by PR speeches.
TFA: It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.
From TFA "It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the contents of protected kernel memory.".
It could explain why Intel did put the brakes on CPUs production, and some of the 2017 are very hard to find.
Slashdot Mirror
We used to have a lot of Motorola, but now that Intel dominates the market, most processors are little-endian. Not a defined standard (why would we make one), but a kind of standard by popularity.
Or you could disable the current CPU cache...
And even if we had an open source CPU, the fix wouldn't be any faster: the "bug" (actually design issue) that has been existing for 20 years, is based on having as much speed as possible, while keeping data safe (data is not "retired" if it's not supposed to be seen by the user). And that work(ed) well. These new attacks based on the time taken by the CPU to load some data into the cache, or not if it's there already, are subtle, really clever, and the fix at the CPU level requires a lot of deep changes.
Yes. But it'll be 100 times slower.
We clearly don't trust Intel ... why would we trust Chinese CPUs??
Because you trust already many stuff made in China. Have you a smartphone?
I like this comment "Don't these kernel updates get any testing? I realize that CentOS may have very limited resources for testing, but doesn't Red Hat test these updates?".
What? Maybe it compiled just fine!
This is not how it worked. Intel has been aware for quite a long time, a year or more probably. Google found the problem in June, and vendors were made aware around that time. If it wasn't for Google, the issues would probably still be kept secret by Intel (until a hacker or another country find and take advantage of the vulnerability). Intel should have informed vendors a long time ago, like Google did, without of course making the issue a public story until a fix is installed. But Intel admitting the flaw would have triggered many compensation requests. This is one reason why the class action makes sense.
...to the 0xDEADBEEF bug?
Thanks, and interesting, but the thread is "old", nobody will see it. You should post that to the next coming "Intel bug" story (in an hour or so?)
And the next French presidential election is in 4 years...
Oh yes Apple learned. Selling 20% quality-up 80% more worked well, so far.
It depends on what does actually mean "Apple-customized CPU, SSD". Is the customization worth it?
That's a link to your mailbox...
According to Project Zero, Intel was notified of these exploits in June.
Intel could have been aware of the problem early on, and decided to ignore it until it's revealed from outside.
None of these persons would be fooled by PR speeches.
But the shareholders might be.
Intel PR seems to forget that they sell CPUs not (usually) to the final end user, they sell them to PC manufacturers or computer skilled people. None of these persons would be fooled by PR speeches.
Intel have been very slow in producing new CPUs the past months. This issue (they've known for a year) is likely related to the decreased production.
Intel PR translation.
Intel are in full damage control, but they deserve to lose business after this disaster and ME.
After this disaster and YOU? What did you do?
There is a nice "translation" of Intel PR speech by The Register.
Yes, but the Motorola instruction set is nicer.
TFA: It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.
Technically speaking Intel fails to provide a CPU that works as advertised.
From TFA "It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the contents of protected kernel memory.".
It could explain why Intel did put the brakes on CPUs production, and some of the 2017 are very hard to find.
to provide 6502 performance from an i7."
Well, if it uses the 6502 instruction set as well, all is not lost!