Intel CPUs Impacted by New PortSmash Side-Channel Vulnerability (zdnet.com) 116
Intel processors are impacted by a new vulnerability that can allow attackers to leak encrypted data from the CPU's internal processes. From a report: The new vulnerability, which has received the codename of PortSmash, has been discovered by a team of five academics from the Tampere University of Technology in Finland and Technical University of Havana, Cuba. Researchers have classified PortSmash as a side-channel attack. In computer security terms, a side-channel attack describes a technique used for leaking encrypted data from a computer's memory or CPU, which works by recording and analyzing discrepancies in operation times, power consumption, electromagnetic leaks, or even sound to gain additional info that may help break encryption algorithms and recovering the CPU's processed data. Researchers say PortSmash impacts all CPUs that use a Simultaneous Multithreading (SMT) architecture, a technology that allows multiple computing threads to be executed simultaneously on a CPU core. [...] Researchers say they've already confirmed that PortSmash impacts Intel CPUs which support the company's Hyper-Threading (HT) technology, Intel's proprietary implementation of SMT.
Never liked Hyper-Threading... (Score:2)
Never liked Hyper-Threading. It always seemed like a fishy hack — and now my irrational fears have been "substantiated" by Finnish and Cuban academics...
Re:Never liked Hyper-Threading... (Score:5, Informative)
Re: (Score:2)
What "performance boost"?..
Re: (Score:2, Informative)
SMT adds the ability to achieve about a 30% overall system performance gain at the cost of a mere 10% additional die space.
As far as design choices go and economics, it's a very solid choice to make.
Overall system throughput is of course load-dependent.
Neither multiple cpus, multiple cores, nor multiple contexts will help a single threaded workload just the same.
Re: (Score:2)
Only when your code is inefficient and causing pipeline stalls, if your code is well optimized then SMT is more likely to cause a performance loss.
Re:Never liked Hyper-Threading... (Score:5, Informative)
Some code can't be compute-bound, no matter how well written. Stuff with very random memory access patterns, for example - 3D particle systems are notorious for this. While one thread is blocked on a LLC or RAM read, the other has full use of the core.
Some code can also be very optimized for SMT. It's rare to have two threads using almost exclusively separate execution units of a core, but if your problem is naturally divisible in such a way, you can get a full 100% performance improvement. Think a Huffman decoder feeding data to some kind of SIMD floating-point number crunching - one thread's using mostly shifts and integer math, the other's using SSE, and SMT will let both run simultaneously.
Re: (Score:2)
Re: (Score:3)
I've never liked hyperthreading either, but in my case it's because it didn't optimize things correctly for me. I want genuinely separate multi-processor systems that can communicate rapidly with each other. And rather than fancy instruction sets, I'd be satisfied with a 64 bit version of the z-80...plus a few to handle interprocessor communication.
OTOH, I realize that my proposed task-load is substantially different from the most common case.
Re: (Score:2)
Machine is used to surf slashdot.
FTFY
Netbooks are garbage for anything but surfing the web. You cant do 80% of the things you can do on a typical desktop. Damn sure not more than one at a time either. You get a little better performance on linux than you do windows, however it is still very limited. I used a netbook for a year or so cause I had no other choice.
Re: (Score:2)
Netbooks are garbage for anything but surfing the web.
Most of them are garbage for that, too, because these days web surfing elegantly requires multiple cores and at least 4GB RAM, plus more for caching if your storage is slow.
Re: (Score:2)
Oh how right you are.. I could never try to deal with that torture again.
Still waiting on my remote root SSH exploit (Score:1, Flamebait)
Re:Still waiting on my remote root SSH exploit (Score:5, Insightful)
Stupid point of view, you're saying we have to wait until some no-goodnick exploits a known and proven weakness before we lift a finger to do anything? No, they need to be fixed before something bad happens. some of us are responsible for machines that handle billions of dollars, we can't take your lazy attitude
Re:Still waiting on my remote root SSH exploit (Score:4, Interesting)
Re: (Score:1)
Relax. It's an ongoing war, and the doomsday scenario you're hoping for might indeed happen.
The way software works, you don't just have one surface area that can be attacked like popping a balloon. It's more like an onion composed of many stacked layers. Some of these vulnerabilities are serious because they're either lower level, in hardware or code that we thought was well-tested for years or even decades, and other times they're serious because there's no quick and fast workaround that doesn't cause it
Re: (Score:2)
Comment removed (Score:5, Funny)
Re:Still waiting on my remote root SSH exploit (Score:5, Insightful)
It's not really a war, it's more intrigue and economy
The state actors will try to have the exploits first. They'll pay mightily to have them, and let them do work quietly for a long time. I suspect they're already at work. Because of the problem in AMD's PSP chips, some exploits will never be detected, ever, only blindly wiped at some point.
Other exploits will try to be quiet and quietly unobtrusive for as long as possible. Then there'll be a leak or a copycat found, and available on an onion address for a short while at a slowly degrading price, until someone buys and exposes it, and then there will be a fury of patching until variants of that bug come alive, while other bugs are sitll in stage one or two.
Don't believe nothing's going on. We're just in the quiet stage, until someone either screws up and lets their EK become revealed, or a handy packet snifter starts alarming someone to a rogue somewhere. Then something at stage one will go to stage two. That's how this works.
Re: (Score:2)
Re: (Score:2)
Re:Still waiting on my remote root SSH exploit (Score:5, Interesting)
Those were big bugs, and they have real impacts. Not all impacts allow remote exploit. For home users, the impact is to change any remote exploit that gains user privileges into one that gains root privileges. That's important, but not a disaster.
Where the real disaster is is in virtualized systems. That class of exploits allows you to potentially hack from one VM into another running on the same physical hardware. That's a disaster for cloud providers, but fortunately, they have professional IT teams that can stay on top of required patches, to the extent that they are able to do so. Unfortunately many of the patches may need to be done inside the user-controlled VMs.
This sounds like a somewhat similar bug in that if you can execute on one hyperthread, you can figure out what is going on on the other one on the same core (or at least I suspect that's it--I didn't read the article). Again, that's bad for virtualized systems, but not that serious for most home users. It does potentially blow a big hole in the security for whole-disk encryption and things like that, which some people are going to be very concerned about.
Re:Still waiting on my remote root SSH exploit (Score:4, Informative)
Re: (Score:3)
The reality of 2018 is that they have had SQUAT for impact.
Remember Y2K? It had squat for impact because a lot of people did a lot of work. Guess what?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The last time worms came close to "ravaging the Internet" was 15 years ago.
For very elastic definitions of "close".
Everything has been fine since then.
And just about everything was mostly fine then. It was, once again, 95% hype and 5% reality.
Re: (Score:2)
> The last time worms came close to "ravaging the Internet" was 15 years ago
Not quite. There was plenty of nasty stuff a couple of years ago involving buffer overflows, especially a particularly nasty one caused by the way a very popular image library handled JPEG files that ended up enabling "drive-by" exploits.
On the hierarchy of badness for a typical non-enterprise user, "drive-by" exploits are absolutely, positively the worst, because those are the exploits that can nail even people who are aware
Re: (Score:3)
While this is obviously a trolling attempt, the fact is that there is an element of truth in it. An example: we have been told for years now that RSA-1024 is insecure, and that it should have been ditched long ago. In truth, no RSA-1024 certificates have been compromised because an RSA-1024 has been broken. The largest RSA keys that have been brute-forced were RSA-768 a few years. After many months of work on many different systems in the network. I.e. after a huge effort, that nobody has so far attempted t
Re: (Score:3)
I don't dispute what you said, it's correct, however, I do want to point out a few things.
we have been told for years now that RSA-1024 is insecure, and that it should have been ditched long ago
If someone told you it's insecure, then they should have preceded it with, "in some situations". And you hit on the reason a bit further in your comment, here.
If the bad guys/government agencies really wanted your data (which they probably don't anyway) they have far more efficient, faster, cheaper and better methods at their disposal to obtain it
But brute-forcing it is also an option for State sponsored cracking efforts. And indeed, for most folks, RSA-1024 is good enough unless you're targeted. At least right now. But the timelines for when to retire a given RSA strength was based mostly on Moore's
Re: (Score:1)
...it's just not materializing.
Re: (Score:1)
Re: (Score:2)
So... (Score:2)
Do not buy the new 2018 top-of-the-line i7 Mac mini, the i3 and i5 options without hyper-threading are safer. Got it.
Re: (Score:2)
Hyperthreading usually can be shut off in BIOS, why not do that if you're worried and your apps don't need it? my apps certainly don't benefit from it much...
Re:So... (Score:4, Informative)
Hyperthreading usually can be shut off in BIOS, why not do that if you're worried and your apps don't need it? my apps certainly don't benefit from it much...
No BIOS on Macintoshes. And no other way to permanently disable HT, AFAICT. You can disable it with Instruments.app and probably with sysctl. (I do not own a Mac with an Intel CPU, I just googled.)
Re: (Score:3)
"To be clear, Macs don't have a BIOS, they have an EFI." I know fuck all about macs, but you got me curious. Then I realized after 2 clicks you were being pedantic as usual.
Re: (Score:2)
EFI and UEFI are both a form of BIOS. BIOS is not "BIOS" unless you're on an old IBM PC.
Compaq stole BIOS from IBM and basically revolutionized the industry. No, Compaq did NOT develop a compatible implementation in a clean room scenario. No fucking way. Yes, I know they won in court. No, I'll still never believe that load of horse shit.
The BIOS you have today is not IBM's BIOS, but a basic input/output system used for low level setup, hardware initialization, etc. EFI and UEFI are simply modern versi
Comment removed (Score:5, Informative)
Re: (Score:1)
Not to mention that IBM provided the source code for the BIOS in the extended manual kit, so Compaq had a good idea of what they were not supposed to copy...
Re: (Score:2)
Compaq claims they produced a compatible BIOS without even so much as taking a peek under the covers. Absolute horse shit.
Re: (Score:2)
Compaq claims they produced a compatible BIOS without even so much as taking a peek under the covers. Absolute horse shit.
Those BIOSes were stunningly simple. They hardly did anything because they hardly had anything to do. The 5150 PC had one bus, with little more than a keyboard controller and a floppy controller on it, plus whatever primitive display card you had — mine didn't even have graphics when I got it, just a text-only display card. The original BIOS didn't even know how to talk to a storage controller other than a floppy, though my PC had upgraded ROMs that would do it.
It's not hard to imagine that Compaq cou
Re: (Score:1)
You're missing the point entirely. They're all BIOS. They all serve the same purpose and function that BIOS does. Saying EFI and UEFI have nothing in common with Coke is like saying Pepsi has nothing in common with Coke, while failing to realize you're in Atlanta and Coke is the common term for all cola. Just because a given EFU / UEFI doesn't support the same hardware as a given BIOS does, doesn't mean EFI and UEFI and BIOS are fundamentally different.
It has EVERYTHING to do with the IBM PC because Com
wait for the 2020 mac pro with amd! (Score:2)
wait for the 2020 mac pro with amd!
Re: (Score:2)
I was waiting for the 2018 MacBook Air with ARM... disappointed it still uses an expensive piece of junk from Intel, dual-core only too.
Re: (Score:3)
AMD has problems too
in fact only modern arch not proven to have problems yet is Sparc...but fuck Oracle, don't buy their shit. They will have auditors come and camp at a customer and be a pest for months until they break down and buy UNNECESSARY licenses. There are now consultants that help clients reign in Oracle to only get fees for legally required things without the extra theft money Oracle is trying to extort.
Re: (Score:2)
AMD has problems too
They do, and so far they seem to be vulnerable to most of the SPECTRE-type attacks. However, because they at least tried to do the right thing, they are not vulnerable to MELTDOWN, and mitigation seems to be cheaper in all of the cases where the AMD processors are vulnerable.
The real question is, if Intel was willing to deliberately compromise the security of the entire system in this way, in what other ways have they done so?
Re:AMD (Score:5, Interesting)
Multicore will be next (Score:5, Insightful)
If a hyperthread can spy on the other hyperthread that runs on the same core, it is possible to disable hyperthreading.
However, the next exploit will be that one core can spy on another core. This is possible because all cores use the memory subsystem including the L3 cache that is shared between all cores.
Comment removed (Score:4, Informative)
Re: (Score:3)
Yes it does, that's the whole idea. Hyper-Threading is the Intel implementation of SMT or Simultaneous Multithreading. The idea is to make use of execution resources that would otherwise be wasted to run an extra thread of execution (or more). This is what make it different to other designs like for example switch-on-stall threaded processors which run a thread until it have to wait for something and then switches to another thread.
Haven't looked at it but: https://en.wikipedia.org/wiki/... [wikipedia.org]
So (Score:4, Funny)
The aliens in Independence Day never stood a chance.
HT available only for one process? (Score:2)
How does this exploit work in practice? Do you have one legitimate process doing encryption/decryption while another process tries to get itself hyperthreaded with the first in order to spy on it?
Why not have HT available only for threads of a single process? That would stop two unrelated programs from sharing the same core simultaneously.
Yawn (Score:2)
In lay terms, the attack works by running a malicious process next to legitimate ones using SMT's parallel thread running capabilities.
Once again, we are presented with an 'exploit' that requires one to have compromised the target already, rendering this as a "Why bother? You're already inside."
This feels more like bashing Intel than anything else at this point.