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.
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.
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.
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.
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.
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.
On August 23, 2018 - Theo de Raadt with OpenBSD even recommended disabling HT in BIOS. His e-mail below.
https://marc.info/?l=openbsd-t...
Life is not for the lazy.