SoylentNews is people
SoylentNews
The Intel® FPU speculation vulnerability has been confirmed. Theo guessed right last week.
Using information disclosed in Theo's talk, Colin Percival developed a proof-of-concept exploit in around 5 hours. This seems to have prompted an early end to an embargo (in which OpenBSD was not involved), and the official announcement of the vulnerability.
Also at The Register, Hot Hardware, and BetaNews.
An update to the article appearing in The Register adds:
A security flaw within Intel Core and Xeon processors can be potentially exploited to swipe sensitive data from the chips' math processing units.
Malware or malicious logged-in users can attempt to leverage this design blunder to steal the inputs and results of computations performed in private by other software.
These numbers, held in FPU registers, could potentially be used to discern parts of cryptographic keys being used to secure data in the system. For example, Intel's AES encryption and decryption instructions use FPU registers to hold keys.
In short, the security hole could be used to extract or guess at secret encryption keys within other programs, in certain circumstances, according to people familiar with the engineering mishap.
Modern versions of Linux – from kernel version 4.9, released in 2016, and later – and modern Windows, including Server 2016, as well as the latest spins of OpenBSD and DragonflyBSD are not affected by this flaw (CVE-2018-3665).
Windows Server 2008 is among the operating systems that will need to be patched, we understand, and fixes for affected Microsoft and non-Microsoft kernels are on their way. The Linux kernel team is back-porting mitigations to pre-4.9 kernels.
Essentially, hold tight, and wait for patches to land for your Intel-powered machines, if they are vulnerable. CVE-2018-3665 isn't the end of the world: malicious software has to be already running on your system to attempt to exploit it, and even then, it can only lift out crumbs at a time.
[...] Red Hat has more technical details, here. RHEL 5, 6, and 7, and Enterprise MRG 2 not running kernel-alt are vulnerable. In a statement to The Register, the Linux vendor clarified that this a potential task-to-task theft of information:
(Score: 3, Interesting) by Subsentient on Friday June 15 2018, @03:02AM (4 children)
I'm getting so tired of all these crippling bugs in Intel's chips. Most of these patches have a performance hit. Depressing. IO speed has gone in the toilet for me since I enabled KPTI on vulnerable systems.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 1, Interesting) by Anonymous Coward on Friday June 15 2018, @03:51AM (2 children)
Most of the current issues would not BE issues if the original kernel/application memory address boundaries had been followed, instead of the performance optimization of placing kernel memory in a subset of application memory. However the added bounce buffers to pass data back and forth between kernel and user space were considered too great, and the choice was made to forego that protection and place everything in the single memory space that has persisted until today. Tanenbaum is being proven correct in his microkernel vs monolithic kernel debate, and we are finally reaching a point where the compromises in security taken for the sake of performance are being reassessed. Both processors and system memory are now fast enough for all but the most intensive workloads to not be significantly impacted by the loss in performance, and for applications that still require that level of performance, so long as they are not network accessable or scriptable then it is safe to use them with the protections disabled on a application by application basis, while everything else is properly isolated with kernel/application memory space isolation. The major exception to this is Web Browsers, which are going to take a huge performance hit, and things like WebGL, Javascript Coin Miners, and DRM will no longer have the access nor performance necessary to do their stated tasks.
(Score: 0) by Anonymous Coward on Friday June 15 2018, @05:32AM
Uh, no. Watch the talk. The working assumption that they started with, which allowed someone to write an exploit in less than one workday, is that the hardware is not bothering with permission checks until the decision about which tree to collapse is made.
(Score: 2) by shortscreen on Friday June 15 2018, @08:29AM
BIOS and DOS (including DPMI) system calls were done using interrupts. I'm not sure if DPMI hosts put their own code/data in the program's address space. Maybe your VMs would be safe from illicit memory reads as long as you only run DOS software...
(Score: 1, Insightful) by Anonymous Coward on Friday June 15 2018, @08:42AM
Well maybe Intel can think about ways of using all those billions of transistors to actually make their CPUs faster without so many security issues rather than just give us more and more cores.
Maybe half the reason why Intel is faster than AMD is they cut more of these corners?