Slashdot Mirror
Intel CPUs Impacted by New PortSmash Side-Channel Vulnerability (zdnet.com)
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.
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
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.
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.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It's not a bad idea in general and it certainly made a lot of sense when Intel introduced it since the number of stages in their CPUs' pipelines were massive (eventually ~30 with the last generation of P4 chips) and adding the functionality cost very little in terms of additional die space for the performance boost you would get.
No, I'm not saying take no action, I'm saying don't tell me it's the end of computing unless it really is. Quit acting like all these *potential* vulnerabilities amount to anything but a "possible fear". They aren't fully-formed threats, they are nebulous bullshit until they can be shown to be something else. Also, this shit has been going on all through 2018 if it's so bad that we all need to prepare so much, then why haven't ANY of these flaws really resulted in 4/5ths of 5/8ths of FUCK ALL?
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.
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.
The reality of 2018 is that they have had SQUAT for impact. Hand wave and fear dance all you want, but that's the reality.
Although no one has tested it, the article indicates that the people who discovered this vulnerability think that AMD's SMT implementation would also be vulnerable to this kind of attack. While that isn't a confirmation, it does appear as though this exploit is general enough that it wouldn't be specific to Intel. Hopefully they also disclosed this to AMD so that they had time to explore this for themselves and work on a fix if necessary.
"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.
The aliens in Independence Day never stood a chance.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
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/...
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.
---- Teach Peace. It's Cheaper Than War.
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.
While I was initially annoyed about the pedantry of the original poster who corrected the use of the term BIOS, I feel that your comments are... not entirely accurate?
This is incorrect. EFI and UEFI and BIOS (and OpenBoot, etc) are all forms of firmware, but are only partially related. EFI and UEFI have nothing in common with BIOS except being standards for PC firmware.
BIOS is BIOS if it contains bootstrap code (code to load an operating system) and a set of code vectors providing a minimal HAL defined by the original CP/M operating system. It has nothing to do with the IBM PC, though the original IBM PC does have a BIOS as CP/M (specifically CP/M 86) was one of the intended operating systems, and Microsoft's MS DOS, based upon QDOS86, also used Digital Research's BIOS specification to ensure it could easily be ported to other 8086/8088 based computers at the time.
Confusingly, in the IBM architecture, only some of the BIOS is actually located in the ROM.
Well, tough, because they did. Compaq documented everything they did and had teams of lawyers on staff to make sure of compliance, which is how they managed to end up with a BIOS that was almost completely compatible with IBM's, but contained mostly different code. If they had "stolen" it, the code would have been identical in most of their implementation. It would also have contained a BASIC interpreter because IBM's firmware included a BASIC interpreter that either loaded when you didn't have an operating system disk, or could be patched and loaded from an operating system using the 'BASICA' command.
Bear in mind we're not talking about an enormously complex piece of software. The original IBM firmware was 16K including both the BIOS and that BASIC interpreter. The BIOS component was probably less than 2K in size. Compaq's reverse engineering process wouldn't have had many different test cases needed to determine behavior under each applicable condition. People greatly overestimate the complexity of computers during the 1970s and 1980s, and while copyright infringements did occur, most supposed "They copied this" rumors are bullshit. See also: MSDOS vs CP/M (two operating systems with dissimilar file systems, dissimilar command lines, dissimilar process architectures, but sure, MS DOS must be a copy because... uh it implements a CP/M API. Consisting of, what, less than forty functions? Including "LIFT HEAD" and other things that were NOOPs by 1981?
See above. When a computer comes with a BIOS, it generally still has that jump table to a HAL compatibility library, which is why it's able to run MS DOS (and CP/M 86 if you can find a copy.) EFI requires you load an optional extension which, essentially, contains a BIOS, EFI by itself is not a BIOS.
Source: I was there. Get off my lawn etc.
You are not alone. This is not normal. None of this is normal.
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
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 to replicate for RSA-1024. The projection was that RSA-1024 would have been publicly broken by about now. It hasn't happened. Why? Because it is way too onerous a process, both financially and time-wise. If you have a certificate meant to be valid for 10 years and meant to protect really critical, world-importance data then, sure, use a bigger RSA key or ECC. Otherwise, nobody is going to bother attempting to break your RSA-1024 key - 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 than trying to brute-force your key.
In a nutshell, security people engaging in hype, probably for job-security reasons.
I run my Minecraft server as root so I can dig past the bedrock, you insensitive clod.
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.
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 Law and carefully (actually that's debatable but that'll get us side-tracked) calculating people dragging feet versus new and improved advancements in processing. So the idea is that folks would indeed drag their feet on RSA-1024 and thus calculate a point when processing power is good/cheap enough to break RSA-1024 and subtract 20-30ish years from that. That's the date we need to pull it. But again, you are totally right in that we're not near getting to a point where folks freely break RSA-1024 all over the place.
The largest RSA keys that have been brute-forced were RSA-768 a few years...The projection was that RSA-1024 would have been publicly broken by about now. It hasn't happened. Why?
Also, I just want to point out there was money involved. RSA stopped paying people in 2007. That might (I'm guessing here so feel free to call me out on my BS here) have had some effect on when these things get broken by research efforts.
Because it is way too onerous a process, both financially and time-wise
Absolutely, expect in cases where it is worthwhile to spend that time and money on breaking it, which are few and far between which again, you already pointed out.
If you have a certificate meant to be valid for 10 years and meant to protect really critical, world-importance data then, sure, use a bigger RSA key or ECC
Exactly.
So you might wonder, why deprecate RSA? Because you aim for lowest common denominator here. In 20-30ish years computational power is going to be to a point where breaking RSA-1024 will become easier, not at the point where we do it on a desktop, but definitely within the realm of someone who's got enough equipment to do such a thing. Thus, since folks tend to drag everything out, let's call it now (which was 2010) and eventually everyone will catch up, eight years later, still seeing folks using RSA-1024. So the dragging feet argument I think has some merit.
Now of course that was based on processing power growing at a steady state, which I think we're hitting a point where that will no longer be true. If we do hit a plateau, well then good news! All the worrying was for naught. So you have an incredibly fair argument here and I commend you. However, I think it is fair to remember what the thinking was way back in the day when RSA was designed. You know simpler times and when there was massive idealism about where computers were heading.
As far as the Uber-hype that shortly followed when RSA-1024 was going out of date. Yeah, that's totally...
In a nutshell, security people engaging in hype, probably for job-security reasons.
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.
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?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"