Slashdot Mirror
Another Day, Another Intel CPU Security Hole: Lazy State (zdnet.com)
Steven J. Vaughan-Nichols, writing for ZDNet: The latest Intel revelation, Lazy FP state restore, can theoretically pull data from your programs, including encryption software, from your computer regardless of your operating system. Like its forebears, this is a speculative execution vulnerability. In an interview, Red Hat Computer Architect Jon Masters explained: "It affects Intel designs similar to variant 3-a of the previous stuff, but it's NOT Meltdown." Still, "it allows the floating point registers to be leaked from another process, but alas that means the same registers as used for crypto, etc." Lazy State does not affect AMD processors.
This vulnerability exists because modern CPUs include many registers (internal memory) that represent the state of each running application. Saving and restoring this state when switching from one application to another takes time. As a performance optimization, this may be done "lazily" (i.e., when needed) and that is where the problem hides. This vulnerability exploits "lazy state restore" by allowing an attacker to obtain information about the activity of other applications, including encryption operations. Further reading: Twitter thread by security researcher Colin Percival, BleepingComputer, and HotHardware.
This vulnerability exists because modern CPUs include many registers (internal memory) that represent the state of each running application. Saving and restoring this state when switching from one application to another takes time. As a performance optimization, this may be done "lazily" (i.e., when needed) and that is where the problem hides. This vulnerability exploits "lazy state restore" by allowing an attacker to obtain information about the activity of other applications, including encryption operations. Further reading: Twitter thread by security researcher Colin Percival, BleepingComputer, and HotHardware.
Humans are a security problem,
remove all humans from any computing equipment and
all security problems will be solved.
This just keeps getting better and better. "Hey, I got a ideal! I'm going to switch to intel for this build." I thought to myself. I wasn't even smoking any good weed when I did that, or bad weed. Nope, my dumbassery was my own fault.
I read at +2. If your post doesn't reach that level I will not see or respond to it.
Dude link her to a burn ward webzone after that
...For some operating systems, the fix is already in. Red Hat Enterprise Linux (RHEL) 7 automatically defaults to (safe) "eager" floating point restore on all recent x86-64 microprocessors (approximately 2012 and later) implementing the "XSAVEOPT" extension. Therefore, most RHEL 7 users won't need to take any corrective action.
Other operating systems believed to be safe are any Linux version using the 2016's Linux 4.9 or newer kernel. The Linux kernel developers are patching older kernels. Most versions of Windows, including Server 2016 and Windows 10. are believed to be safe. If you're still using Windows Server 2008, however, you will need a patch. The latest editions of OpenBSD and DragonflyBSD are immune, and there's a fix available for FreeBSD. ...
This vulnerability exists because modern CPUs include many registers (internal memory) that represent the state of each running application
Does the submitter mean to imply that AMD processors are not modern or that they don't have registers? FFS, it's literally the sentence immediately after noting that AMD isn't affected!
It just more of the same Intel propaganda where they have to admit that they screwed up but then comes some fuzzy words like "modern" or "most" etc, implying that everyone are affected - which is patently false.
AMD should be dumping money right now. Making all this as public as possible and pushing its own CPU's Go AMD go!
This doesn't make any sense to me, unless they're actually shared registers. If not, when would anyone use a FP register for encryption? This just sounds like a way to make an otherwise very tiny vulnerability sound bigger and scarier than it actually is.
For some types of chips and applications, perhaps having real security means not being able to do fancy optimizations that degrade security.
I wonder how well typical PC operating systems would work if they were re-compiled to not take advantage of optimizations and run on a completely-de-optimized architecture-compatible CPU with buses, memory, chipsets, etc. that were similarly "de-optimized" and had other things in them like less-tightly-packed circuits to prevent certain side-channel attacks (e.g. rowhammer).
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I just built a new PC after 10 years on an Intel Q6600. Glad I picked an AMD Ryzen 7-2700.
TFA includes a claim that the fix for this hole will actually improve performance. I don't see how that's possible - the problem is caused by a feature that improves performance, and the fix, as I understand it, is simply to not use that feature. Is there something I'm missing?
This is the Google-era, so posts shouldn't be conditional on something that you don't know. Do your homework and find out whether Intel CPUs share FP and integer registers. Depending on the answer, either cancel your entire message, or replace "unless they're" with "since they're not".
which also means another day when I am too lazy to attempt First Post on /.
Which also has little to do with Lazy FP state restore, whatever that is.
It's a slashdot post, it's just not worth the time and effort for them to look all that up.
Actually describing them as FP is misleading, they should be called the vector registers, they are wide (128, 256 or 512 bits) and while all (except legacy x87) FP instructions only work on these registers, there are plenty of instructions which use them as fixed size arrays of 8, 16, 32, and even 64 bit integers.
Of course you could perform the same tasks on the regular 64 (formerly 32) bit registers but this would be much slower. Using the vector register file also frees the integer registers to be used as counters, pointers and so on. This was especially true on 32 bit, where out of the 8 registers, the stack pointer (ESP) cannot be used for anything else, the frame pointer (EBP) may be needed for debugging/dynamic allocation, and EBX is used for addressing in position-independent code (all libraries). In many cases, the compiler was (32 bit is obsolete) left with 5 or 6 registers to play with.
I thought AMD and ARM cpus were also susceptible to exploits. Is that wrong?
Indeed lots of different CPU manufacturer could be producing CPUs susceptible to spectre vulnerabilities.
But not all CPU are created equal.
There are some key differences :
- not all CPUs actually do speculative execution. only a couple of ARM core actually do. The huge remaining amount doesn't and thus can't in any way be subjected to Spectre class vulnerabilities.
(Even some of Intel's own core, like some older Atom, or like Xeon Phi GPGPUs don't do speculative execution)
Intel has a different safety vs optimization threshold than most of others:
- with most other CPU manufacturer, Spectre vulnerabilities boil down to "access memory region to which the process should already have had read access anyway" (see v1 and v4), thus it could be already addressed by safe practice (v1: don't put 3rd-provided JIT code and crucial information in the same process. e.g.: a browser's JIT engine running webpage's scripts and the password manager should not be in the same process) (v4: always clean up your stack before bailing out if it could contain cricital data, or better keep all the critical data in some specific mapped pages), etc.
- Intel tends to push performance first to the detriment of anything else : some security test coming in too late.
AMD and most ARM won't speculate past memory protection. If a memory region is blocked from access for the process (generally : kernel memory), AMD will check the memory protection and never attempt to access the restricted region to begin with. Whereas Intel CPUs will speculatively access the restricted region and only do the check much latter, by which point the usual Spectre's cache loading side-channel leakage could have happened.
(There are few select ARM which are susceptible to Spectre v3a. Basically the same concept, but regarding system-reserved register - this being RISC architecture, with tons of registers)
AMD and ARM will honor non-maskable interrupt. In today's vulnerability Intel tries to speculatively execute the point past which the system should contect switch the FPU registers (which includes stuff like SSE and AVX registers. i.e.: an attacker could be speculatively peeking into what another process did with these - SIMD operations with SSE/AVX are used in encryption/decryption, so an attacker could occasionnally spot what other process are decrypting/encrypting and whith which keys)
So you end up with vulnerabilities v3 and today's which are Intel exclusive.
Also Intel tends to be a tiny bit more aggressive and/or jumping through some shortcut and/or having way deeper pipeline and longer speculations, in order to shave a few cycles off :
end results :
v2 (Indirect Branch prediction) is currently successfully exploitable on Intel. Though in theory some AMD CPU could do speculative indirect branching, there are no current usable exploits in the wild.
v1 actually works on Intel CPU without even activating the JIT - the speculation is so deep that an bytecode interpreter could speculatively access stuff
v4 works much easier on Intel (deeper pipeline higher chance to manage to read something that wasn't erased from memory yet)
etc.
TL;DR: due to technical choices prioritizing performance, Intel CPU tend to be even more vulnerable.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
They're listing lazily to the left. Boy, this guy knows some maneuvers.
Where's the tablet-optimised website? This one's just a few tweets, it doesn't even have a logo! Where's the superbowl ad?
In an era where every single vulnerabilities needs to get a catchy name and a well designed reactive website (almost a superbowl ad ?), even before confirming if there's a viable exploit, it's nice to see the big hats of security reacting (cpercival - the daddy of Scrypt) and taking time to write an actual exploit to test, even if communication is done over an unglamorous channel as twitter.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
You, my friend, have too much free time.
Floating point registers are used for encryption?
This doesn't make any sense to me, unless they're actually shared registers.
Exactly :
the FP registers are shared with integer SIMD registers
(FP87 and MMX are exactly the same register file under a different name, modern CPU tend to use AVX/SSE for their floating point computation and use the same registers also for interger SIMD, etc.)
Basically (As cpercieval explained in his Twitter thread), the CPU will only always switch the content of its basic CPU registers (rax, rbx, etc.)
Everything else (e.g.: SSE's xmm0, xmm1, etc) will only be switch when needed (though a non maskable interrupt). But just like with Meltdown Intel CPUs didn't give a fuck about memory protection, in this spectre vulnerability Intel CPU don't give a fuck about context switching and will happily speculatively execute and process old left-over data in these registers.
The problems is that most efficient crypto implementation are likely to be implemented using MMX, SSE or AVX (including the AESNI hardware), thus critical data is likely to be hanging in these registers when a process that handle encryption is interrupted and multi-task-switched to the attacker's process.
On any other CPU, if the attacker's process attempts to access of there registers, the process will immediately be interrupted, and the kernel will also switch the FP/MMX/SSE/AVX context (the process will only see it's own content of XMMn).
On Intel hardware, the CPU will happily try to speculatively continue executing based on the old stale content of the XMMn register (which could be containing the data that the encrypting process was manipulating), enabling possibility to leak through the usual spectre's cache side-channel, until the NMI is served the correct context is loaded and the speculative attempt thrown away.
Sounds stupid, but it enables Intel CPU to show a couple of % faster on benchmarks.
e,g,; benchmarks that do encryption are less likely to be hit performance-wise by multi-tasking :
in the case of switching an encryption process -> normal CPU process -> back to the encryption process, a normal CPU (like AMD) will lose time forcing a reload of the SSE/AVX context when returning to the encryption.
An Intel CPU will happily continue immediately the encryption with the content of the XMMn registers, and speculative execution will eventually turn being right as the left-over data in the XMMn registers is the encryption's own content from right before getting interrupted by the CPU-only thread (which left it untouched).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I wonder how well typical PC operating systems would work {...}
Well lots of smartphones and nearly all single-board computers (including the Pi) use ARM core that don't do any speculative execution.
(Only very few high-performance smartphones use ARM with speculative exec and thus potentially spectre-vulnerable)
They are still not that bad at common browsing tasks.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Where's the tablet-optimised website? This one's just a few tweets, it doesn't even have a logo! Where's the superbowl ad?
And where are all the usual APK-copycat trolls trying to push the APK Hostfile Engine as the definite solution against these security holes (with all their "See subject" and over-abuse-of-bold glory) while the original APK dumbshit itself tries to whine about impostors and fake nicknames ?
CAPTCHA: unbiased ;-)
See subject & via APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p (remove spaces between characters & download).
Yields more security/speed/reliability/anonymity vs. any SINGLE solution (99% of threats = hostnames vs. IP address (that most firewalls use)) more efficiently/FASTER + NATIVELY 4 less!
(... Vs. "Bolt on 'MoAr' illogic-logic" competitors slowing you, hosts speed you up 2 ways (adblocks + hardcodes u spend most time @) vs. competition loaded w/ bugs (DNS/AntiVir) + their overheads (messagepass ('souled-out' to advertiser addons) + filtering drivers) & their complexity leads to exploitation).
* Created in FreePascal/Lazarus 1.8.2 using GTK3 on OpenGL 3.1 via KDE Plasma desktop on Kubuntu 18.04 plus patches.
APK
P.S.=> Enjoy - it's much better vs. the Windows model on many fronts (speed & efficiency (plus new "merge" feature))... apk
VW plays fast and loose with diesel emissions to gain performance, and is fined billions. Intel plays fast and loose with speculative execution to gain performance, and...nothing.
While Intel hasn't broken any regulations (AFAIK), they have sold defective goods, likely deliberately. It's time for them to at least reimburse all customers for the damages.
Enjoy life! This is not a dress rehearsal.
No wonder intel is so much faster... they skipped all the fking checks. I've now got $100m of virtualised hardware which can be hacked.
Nice..
Methinks you don't understand what "shared" means in this context. (Although I don't doubt that Intel engages in spying, as the existence of the Intel ME strongly suggests, as has been discussed on /. before.)
The good news is it's really not necessary to go that far back, it's just the more excessive optimisations that need to be scaled back and more thoughtfully applied - if at all.
This.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
This is the Google-era, so posts shouldn't be conditional on something that you don't know.
Well, this also is the social-media-era where knowing what you are talking about (let alone wanting to know about it) isn't too high on anyone's list.
"Fixing" these will go on forever, probably, because there are all kinds of side channels enabled by the fact that modern CPUs use many different optimizations. They aren't the simple machines they look like from the software side. Disabling all of those optimizations would have a significant impact on performance.
Modern processors switch between various modes a million times per second. One way to get the best of both security and performance would be to have a security mode, in which all caches and such are either disabled or cleared upon entering or leaving security mode. The CPU would run as a much simpler implementation, maybe roughly akin to a 286 in complexity, which would increase security while it's computing a cryptographic hash or whatever. It would be slower during those few milliseconds, so a cryptographic operation might take 4 milliseconds instead of 2 milliseconds. Standard high performance mode would then be restored, with caches cleared, while you edit video or do other CPU-intensive tasks.
I think of it similar to Windows Safe Mode - only essential functions are enabled, so it's unlikely anything will break.
I once had a computer that was used *only* to store credit card information in order to bill customers monthly. I could permanently set that computer to safe mode all the time. Most desktops would switch to safe mode for only a few milliseconds at a time, as signaled by either applications which wish to execute a critical function, or possibly automatically by the CPU when certain instructions indicate sensitive operations may be in progress.
1) APK is never wrong
2) APK is the greatest thing since sex. In fact, the fact that APK has deigned to grace us with his presence here is better than sex and we must bow down before the mighty APK.
3) Even if you can show that you wrote a program to invoke world peace, have all the taxes you ever paid refunded legally, and give you head each morning, unless you got a better rating from ZDNet than APK, you still ain't shit, and more specifically, you ain't a pimple on the ass of the mighty and powerful APK.
4) Network engineers ain't shit, most especially compared to the deity-on-earth known as APK. APK Knows this because many years ago, he was an NT admin for a couple of years.
5) APK knows all computer law better than the DOJ web site.
Just as cpercival's tweets are wilfully rushed: Siddown and give us the low-down already. Take those few minutes to do a write-up. Because a well-written executive summary has a lot more reach than having to piece it all together from tiny fragments here and there. So I say he also is guilty of hyping by rushing. If he's that much a "big hat" he better make it show, and this is what he's making show.
The perennial complaint with "computer security" is exactly that the shtick is entirely rushing and hype. If even the "big hats" do exactly that, then that's a point to the complaint and more proof that even the best, even this guy is barely above a s'kiddie. And yeah, if that's the best the "computer security" industry can muster, that's a problem.
TFA says "What a horrible year in security for Intel".
It was mostly horrible for Intel's customers.
I never said that (as you try shit on my program many here like & use that a not-man "ne'er-do-well" you can't produce or do BETTER than yourself - hostnames my program puts into hosts aren't "long known" - they're as CURRENT AS POSSIBLE (often daily updated, some of my sources do it every 20 minutes).
* See subject: However, it's pretty obvious I've stomped you many times under "registered 'luser'" fakenames you also hide behind w/ unidentifiable ac posts you now troll me by (since you're so "butthurt" over it, grow up) - & you know it.
APK
P.S.=> Heck, the very FACT you hide behind your UNIDENTIFIABLE anonymous posts PROVES I've done you in MANY times under your doubtless MANY sockpuppet fake names you use here (which I know is done here)... apk
Comment removed based on user account deletion
Roughly yes.
Except that: instead of comparing on X versus Y, you can make a giant array of Y with lots of pages, and for each possible value of b that you want to snoop on, you make sure to load a different page. (So if you want to distinguish between 16 values of b, and Y is stored in a region that is cached into 16k pages, you allocate 256k for the Y array).
And then process 1 measures timing access to each chunk of array Y to see which one was already loaded into cache. (not necessarily on the same pass).
See Google Project Zero's demo code for spectre 1 and metldown to see examples.
Also, on branches, the scheduler doesn't take "both branches" it makes a bet based on how the jump looks like (loop tend to point backward and tend to be taken, if condition tend to jump forward and often aren't jumped) and based on prior knowledge (the spectre v2 tries to leverage the exact way this "prior knowledge" works to confuse the scheduler and have it jump speculatively were you want. That's the reason why Intel god exploited, but AMD doesn't have any concrete exploit in the wild : despite also doing indirect branch prediction too, it's much more complexe, and it's not clear whether there's a practical way to abuse this prediction).
Lastly there's the whole "keeping the units busy" part of speculative / superscalar execution.
The CPU might be busy executing some other stuff right now, and meanwhile you could have the math unit sitting idle.
Intel CPU have extremely deep pipelines and looking an insane distance in the future.
There might a few FP maths instruction waiting on the pipeline. So why not keep the FP math unit busy?
the scheduler could speculatively have the FP maths start running, while keeping note that these instruction depend on the register XMM0 - which currently isn't expected to change, i.e.: the CPU doesn't think that it needs to wait another instruction that return a value inside XMM0 (eventually these speculative FP instructions triggers the loading into data cache of some parts of the Y array. Which depend on the content of XMM0).
Much later, the scheduler : "Oh, shoot ! It turns out that we did actually overwrite the content of register XMM0 ! Let's quickly trough out of the windows any speculative execution that was tagged [this speculation depends on the content of XMM0]!"
(Except not exactly everything is thrown out, the page of array Y is now sitting on the cached)
Intel CPU are much more affected than the competition by having much deeper pipeline and more aggressive tendency to speculate. (But that makes nice numbers on benchmarks)
That's why with Intel CPUs Google Project Zero code did work even without turning the JIT on : even if it take much more steps to interpret bytecode (compared to execute any actual instruction that was compiled by the JIT), the Intel CPUs speculate so much ahead that the spectre exploit will manage to run successfully.
The above is also the reason behind Spectre v4 (accessing a bit of memory that should have been overwritten, but the CPU doesn't know yet: e.g.: because the instruction is "overwrite content of location [very long and complicated formula]" eventually the formula turns out to be "b", but by the time the CPU realises it, there's already some Y array page preloaded based on the older value of b).
regarding kernel memory mapping : you don't need to map all the memory. As long as there are a few interesting bits of information in the kernel space to retrieve, meltdown is interesting enough. (On linux only the currently "active" memory is mapper, the rest of the address space is mapped to a magical pages that always return "0". The address space is usually split : e.g.: "negative" addresse (with the most significant bit = 1) are kernel. MSB=0 is userland of the current process)
regarding the precise timing :
You can somewhat compensate by repeating over and over again the attack and doing statistics.
Regarding the crypto libraries :
the worse part is that AES-NI hardware extension is very precise in which XMMn register holds what.
So you know exactly which regtister to hammer in order to exfiltrate the key. Do it enough and you could statistically rebuild a good idea of the key.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I never say hosts stop Intel or AMD cpu hardware issues (but I see you impersonate me to do so trying to make me look 'bad' etc.)
* You trolls are just pitiful & stupid - POOR IMITATIONS, & nothing but undereducated unskilled "ne'er-do-well" do NOTHING jealous jowies that WISH you were me!
APK
P.S.=> You IMITATING & IMPERSONATING PROVES IT IN FACT - you DO wish you were ME, lol... apk
You're struggling & FAILING as I catch you trying to put words in my mouth to make me "look bad" https://it.slashdot.org/comments.pl?sid=12234158&cid=56789668/ that I never say!
* ... & MORON, I've been upmoderated easily 500++ times on /. so it's clear others DO understand what I write + that YOU have the ADD/ADHD dyslexia "issues" in that DULL brain of yours...
(You PROVED you wish you were me, someone who made a useful program on a simple effective principle others on /. even LIKE + USE, that a DO-NOTHING zero "ne'er-do-well" wannabe that's undereducated & unskilled in yourself CAN'T EVER MANAGE let alone do BETTER than!)
APK
P.S.=> You're so pitifully transparent - & your UNIDENTIFIABLE anonymous posts PROVE you're not only afraid of me but the bs in them like impersonating me OR trying to make me look bad only proves I've crushed you before in tech debates & your STILL "butthurt" due to your FRAGILE EGO being destroyed for it publicly (under 1 of your MANY fake name SOCKPUPPETS you also use)... apk
Arstechnica = losers who stalked me to NTCompatible.com & Windows IT Pro magazine forums to their dismay in Jeremy Reimer & Jay Little + Jarrett DeAngelis (who posts here on /. until I drove his ass off too) when their websites were REMOVED by their hosting providers in Shaw Canada & CrystalTech (for both email harassing me caught on a tracking ticket + stalking me & posting lies about me on them AFTER I destroyed them both PUBLICLY @ Windows IT Pro on Exchange Servers memory being freed UNHALTING them (which tells you Exchange is HEAVILY POINTER ORIENTED, which leads to memory fragmentation that CAN halt a serverware)).
Jay Little the "self-proclaimed 'EXCHANGE EXPERT'" HAD TO CONCEDE IT from MICROSOFT'S OWN DOCUMENTATION proving it FOR me there (where they as usual stalked me AS YOU ARE NOW AS YOU'RE OBVIOUSLY ONE OF THOSE IDIOTS TOO ) & they can't "ban me" ANYMORE than I can be "banned" here on /. - as nothing stops ME, but me!
I just left their site after a VERY BRIEF visit in 2001 (finding they are UNDEREDUCATED DO-NOTHING LAZY WANNABE "Fake it Till you Make It" types - shams & "ne'er-do-wells").
APK
P.S.=> I find it HILARIOUS you fools from "arseHOLETechnica" are STILL BUTTHURT over it (Peter Bright GOITER MAN, lol, frogchin also had his IRC server rooms taken over by "yours truly" EASILY as I drove them ALL out of them running, lol)... apk
See subject & see nothing but FACT much to ArseHOLETechnica's utter PUBLIC dismay (lol) https://it.slashdot.org/comments.pl?sid=12234158&cid=56791034/ & my pleasure to a pack of 'WEEZIL" scumbags I totalled easily due to their OWN stupidity.
* Like usual? Mere JEALOUS JOWIE "ne'er-do-wells" BRING IT ON THEMSELVES... everytime.
APK
P.S.=> No way for YOU to ignore that common-sense & the rationality of FACT... apk
In many cases, the compiler was (32 bit is obsolete) left with 5 or 6 registers to play with.
And of those registers, two or three of them are the mandatory locations for input and output of instructions, meaning that x86 effectively only has two or three general purpose registers.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"