from the hackers-may-violate-your-ring dept.
Intel has backtracked on the license for its latest microcode update that mitigates security vulnerabilities in its processors – after the previous wording outlawed public benchmarking of the chips.
With the Linux 4.19 kernel that just kicked off development this month has been continued churn in the Spectre/Meltdown space, just not for x86_64 but also for POWER/s390/ARM where applicable. For getting an overall look at the performance impact of these mitigation techniques I tested three Intel Xeon systems and two AMD EPYC systems as well as a virtual machine on each side for seeing how the default Linux 4.19 kernel performance -- with relevant mitigations applied -- to that of an unmitigated kernel.
At the BlackHat conference last month, Christopher Domas demonstrated an attack against an x86 CPU using MSR's and an embedded RISC core to bypass ring protections. The full presentation "GOD MODE UNLOCKED - Hardware Backdoors in x86 CPUs" is viewable on YouTube. Is it time for CPU vendors to rethink security?
(Score: -1, Troll) by Anonymous Coward on Monday September 03 2018, @12:14AM (7 children)
Where is the summary of the results? An honest article would put them up front, or in the conclusion, but probably both. Since its missing I dont trust a word of this.
(Score: 0) by Anonymous Coward on Monday September 03 2018, @12:19AM (5 children)
Results for what? The ucode slowdowns for various simulated workloads are in the phoronix article (second link), there's no summary but you can clearly estimate percentages from the test results.
(Score: 0) by Anonymous Coward on Monday September 03 2018, @12:24AM (4 children)
There should be a summary of the results. Ie, "Intel Xeon performance is a% -b% worse depending on workload, AMD Epyc is c%-d% worse." There could even be another sentence about "mitigations had biggest impact (b/d%) for x type of tasks". Then people who are intrigued will read the details.
(Score: 2, Insightful) by Anonymous Coward on Monday September 03 2018, @12:53AM (3 children)
Sure but phoronix is a tech site, these are server tests and you can skim through the synthetic benchmarks yourself and see which is most applicable to your workloads. A summary based on synthetic benchmarks would be misleading as much as it may satisfy clickbait culture.
(Score: 0) by Anonymous Coward on Monday September 03 2018, @01:15AM (2 children)
Why did they split the article up into 5 pages? I think including a summary would be less clickbaity.
(Score: 0) by Anonymous Coward on Monday September 03 2018, @03:25PM
It's for the sake of loading more adds, I guess.
(Score: 0) by Anonymous Coward on Monday September 03 2018, @04:01PM
yes, they have a free with ads/paid without business model. pay up or shut your pie hole.
(Score: 5, Informative) by Anonymous Coward on Monday September 03 2018, @01:14AM
Did you look at all of the graphs of the performance differences for the multiple Intel and AMD chips, as well as two VMs? There were more than a dozen graphs, each representing real world tasks.
There is no single measure of the performance hit because it varies depending on what the system is doing.
(Score: 1, Insightful) by Anonymous Coward on Monday September 03 2018, @12:15AM (6 children)
I haven't seen the Domas presentation covered in the tech press and didn't want to editorialize too much in the sub. I'm sure everyone understands that the complexities of the modern CPU (with embedded processors) present a massive attack surface. Another phrasing for my closing question could be - is spectre / meltdown only the start of these attacks?
Oh and thanks chromas.
(Score: 0) by Anonymous Coward on Monday September 03 2018, @01:16AM (1 child)
Well, Foreshadow is already #3, and there are multiple variations of Meltdown and Spectre.
(Score: 2) by black6host on Monday September 03 2018, @01:39AM
I believe that with the increased complexity of these processors comes more and more vulnerabilities. Basically CPUs and whatnot are nothing more than software modeled in hardware. And software of this complexity? Were it a standalone program what would your expectations be with regards to it being absolutely secure? For me, little to none.
(Score: 4, Interesting) by jmorris on Monday September 03 2018, @05:17AM (1 child)
These are two entirely different animals. The Spectre related flaws are simply a result of complexity and failure to account for every possible side effect of speculative execution. Most efforts to push Instructions Per Clock severely over 1 along with aggressive caching is likely to run into some of these problems. Virtualization means most will be exploitable to cross the barrier to the bare metal and/or into other virtual machines. They will occur over and over, like Flash Player bugs, until we give up on some these ideas. Massively parallel simpler computing cores will be the future and probably spell the end of x86.
The second one is by far the more dangerous. Mr. Domas might say, on advice of counsel, that the feature was installed for customers but since it was never documented it is hard to see who ever used it, at least legit. If somebody at Via hadn't screwed up and filed a patent nobody would have ever known it existed. Every one of those machines would have quietly been recycled with none the wiser. Via is NOT a company with vast resources to waste on designing an entire new never seen before or since processor arch, embedding it into a chip designed with low power as a key selling feature and then forgetting about it. Somebody needs to be demanding some answers, right f*cking now. We need to be told what this damned thing was intended to do, what are the, if any, limits on what it can do and exactly which products have this thing in it. Then we need to look at Intel, AMD and every ARM licensee and ask what deviltry THEY have been jamming into their chips on whose orders.
No more damned secrets. It is time to demand that at least ONE manufacturer of processors and chipsets more complicated than a microcontroller come clean and document -everything- in their products. Although not even microcontrollers are immune to the secret sauce problem these days. If it can't be secured with everyone knowing the inner secrets then it isn't secure. The exact private keys obviously excepted, but it should be possible for researchers and the security conscious to buy unkeyed chips and install their own.
(Score: 2) by pvanhoof on Monday September 03 2018, @03:17PM
Maybe this Deeply Embedded Core is used by other systems too? Then perhaps, using the DEIS that the guy assembled together with fuzzing, we can write a compiler backend for it and then start utilizing it as a nice co processor..
(Score: 0) by Anonymous Coward on Monday September 03 2018, @09:00AM (1 child)
I've mentioned sandsifter last year in the context of blocking javascript and how it could expose secret instructions and microcode capable of circumventing ring privileges: https://soylentnews.org/comments.pl?noupdate=1&sid=22181&page=1&cid=586396#commentwrap [soylentnews.org]
People were fuzzing x86 CPUs for years. Domas recent discovery is important since it proves we weren't being paranoid for worrying about it all these years. But there still no known mass-market hardware being affected so it's not in the "tech journalism" are of coverage.
(Score: 0) by Anonymous Coward on Monday September 03 2018, @10:12AM
I see no problem with some form of mandatory code signing mechanism for javascript or GDPR type click-through for unsigned code.
(Score: -1, Troll) by Anonymous Coward on Monday September 03 2018, @04:02AM
With jewish-owned Intel, who is surprised that it contains hardware backdoors, a (demon)god-mode to harm us?
Tell me the designers of the enhancements in Intel processors did not know they could be misused. In fact, they designed them for that precise purpose while adding a performance gain that they pretend is better than without the compromising architecture.
And by designing the compromising architecture, other manufacturers had to do the same just to compete with the unfair practice.
Reminds me of the diesel-emissions "scandal" some months ago where the regulators who made the regulations knew the output could not be achieved through honest means and they will get to eventually ban and financially harm everyone who did not pass the impossible tests.
It is a characteristic of the jews. They invite themselves to become the leaders through improper means and then control where things head. It is time we said no to the (khazar) jew and everything that race stands for.
(Score: 2) by crafoo on Monday September 03 2018, @04:53AM
The Blackhat video is interesting. Good presentation. He published his CPU fuzzing code on github too. The case study of the VIA chip, and then explaining how a BIOS manufacturer had left the system unsecured by default, allowing the embedded ARM to be enabled from ring 3. I liked the hacked together rigs he showed to do some of the brute force fuzzing.
(Score: 2) by darkfeline on Monday September 03 2018, @09:38AM (5 children)
Don't kid yourself, there's only one possible solution: only run trusted code, if you must, run untrusted code on isolated hardware.
Places with real security demands (properly managed certificate authorities, top secret systems) already knew this for decades.
There will always be security issues. So long as you only run trusted code and only expose a very restricted protocol externally (e.g., SSH), you only have to secure the limited API you expose, not the entire fucking CPU/OS.
Join the SDF Public Access UNIX System today!
(Score: 2) by FatPhil on Monday September 03 2018, @09:47AM (2 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by darkfeline on Monday September 03 2018, @10:19PM (1 child)
If you don't trust the processor, then worrying about malicious code taking advantage of processor design flaws is a non-issue. Fix the first issue before worrying about the second, i.e. make sure you can trust your processor before worrying whether it has unintended security issues.
Join the SDF Public Access UNIX System today!
(Score: 2) by FatPhil on Wednesday September 05 2018, @10:46AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Monday September 03 2018, @09:51AM
Then you better eliminate the human factor, because those meatbags are the runners of untrusted code.
(Score: 0) by Anonymous Coward on Monday September 03 2018, @10:06AM
Not practical. I disable javascript in my primary browser. I have to have it enabled on my secondary browser for an ever increasing number of sites, including my domain name registrar and DNS companies. Gone are the days when it was realistic to manually audit javascript, now we have massive js frameworks and Web Assembly.
And of course, every single device that gets a shell via SSH? Unless you're prepared to run separate air gapped networks, it's not feasible.
(Score: 0) by Anonymous Coward on Monday September 03 2018, @02:15PM (2 children)
No,
It is time for a class action suite by all Via C3 owners.
(Score: 0) by Anonymous Coward on Monday September 03 2018, @04:09PM
exactly. the only thing these people care about is whether it will affect their bottom line or if they can curry favor with entities with more power. they are whores of the supranational surveillance state.
(Score: 1, Interesting) by Anonymous Coward on Monday September 03 2018, @04:10PM
After watching the video, it is likely that the vendor considered their liability when building these architectures, and that the engineering in these architectures were quite expensive to implement. This leads me to the hypothesis that:
1. The architectures were built by request, not by invention.
2. That the requesters would have had contractual obligations if that were so.
3. Those contractual obligations probably would have included indemnification in the event of litigation. Probably in the form of kickbacks through "research grants" or some other innocous budgetary line item, should the manufacturer ever have go to court.
4. Those contractual obligations probably also included a demand that the requester make public their demand for these technologies to mitigate any future deniability.
This would explain the directory of the FBI making ridiculous demands for backdoors. He is just fulfilling a contractual obligations to one or more vendors. They are asking for backdoors in public that they already bought in private, in order to indemnify the manufacturers. The requests are not a declaration of intent, but rather a telltail of existing collusion in a conspiracy to violate the civil rights of every American.