Every Modern CPU Is Still Fundamentally Broken
Vložit
- čas přidán 3. 08. 2024
- For the past 6 years we've been dealing with the Spectre vulnerability and it's following mitigation implementations and people complain and performance being lost but really that performance never should have existed in the first place.
==========Support The Channel==========
► Patreon: brodierobertson.xyz/patreon
► Paypal: brodierobertson.xyz/paypal
► Liberapay: brodierobertson.xyz/liberapay
► Amazon USA: brodierobertson.xyz/amazonusa
==========Resources==========
Bleepingcomputer Aticle: www.bleepingcomputer.com/news...
AMD Security Bulletin: www.amd.com/en/resources/prod...
Intel CVE: www.intel.com/content/www/us/...
New CVE: kb.cert.org/vuls/id/155143
Intel Table: www.intel.com/content/www/us/...
Phoronix 1: www.phoronix.com/review/spect...
Phoronix 2: www.phoronix.com/review/3-yea...
Phoronix 3: www.phoronix.com/review/retbl...
Phoronix 4: www.phoronix.com/review/spect...
Phoronix 5: www.phoronix.com/news/Linux-6...
=========Video Platforms==========
🎥 Odysee: brodierobertson.xyz/odysee
🎥 Podcast: techovertea.xyz/youtube
🎮 Gaming: brodierobertson.xyz/gaming
==========Social Media==========
🎤 Discord: brodierobertson.xyz/discord
🐦 Twitter: brodierobertson.xyz/twitter
🌐 Mastodon: brodierobertson.xyz/mastodon
🖥️ GitHub: brodierobertson.xyz/github
==========Credits==========
🎨 Channel Art:
Profile Picture:
/ supercozman_draws
🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.
Watch: • Debris & Jonth - Game ...
Free Download / Stream: ncs.io/GameTime
#CPU #Linux #Spectre #Meltdown #CVE
DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation. - Věda a technologie
A few of you missed the point I was making, speculative execution might be an important part of the CPU pipeline but the approach that was taken initially was fundamentally flawed, now the CPU developers are slowly reigning that performance gain back in to build a safe product. The levels of performance being offered initially would never have happened with a well designed product.
I rather just disagree on the premise that it wasn't well designed, given that so far as I understand, the speculative execution hadn't been considered as an attack surface until that point.
It was likely designed with the best intentions at the time but in retrospect it's clear that it has serious flaws that now need to be addressed
The next Intel CPUs are removing Hyperthreading. Will that help with security?
@@slowjocrow6451 Yes, a little bit. Hyperthreading means two execution engines share some of the processing units, where full cores don't.
if you don't know CPU design your point is meaningless, go and change your dippers
Accidentally flashing your neofetch is the most Arch btw thing ever
I use fastfetch btw
Yeah accidentally
@@baguettedad it was totally an accident!
"accidentally"
@@guiorgymy fastfetch output is piped into dotacat
"meltdown ... spectre ... also known together as meltdown and spectre"
That's insane
I was afraid this would happen.
I expected a better name. Like "spectre meltdown"
I'd like to interject for a moment. What you’re refering to is in fact, Meltdown/Spectre, or as I’ve recently taken to calling it, Meltdown plus Spectre.
Speltdown
To be fair Brodie: Without speculative execution a modern day processor becomes virtually unusable. Yes, the concept very much has its flaws and the mitigation techniques are horrible, but to be fair to the Kernel developers: It shouldn't be the Kernel's job in the first place to implement mitigations against hardware attacks - it should be the hardware's job. Intel basically threw the Kernel devs into cold waters by not caring about it and not making their microcode open source so people can audit it. They created a gaping security exploit and left the Kernel devs to clean up the mess.
At any rate: Speculative execution is one of those features that you never knew you missed until you actually lose it. You have no idea just how much faster this actually makes processors. So much work can already be done computing instructions beforehand while fetching data from higher cache levels or otherwise idling around and branching.
Just to give you some perspective: A cache miss is something programmers dread and try to optimize away as best as possible. Worst case the CPU has to jump around memory a bit to find the correct data, which costs a lot of time already and can make the difference between 1 and 100ms for an algorithm.
If you have a bad branch in a set of instructions, it potentially has to discard hundreds of calculations it has done ahead of time for nothing, jump back to fetch back the correct instructions, decode those from CISC into microops via microcode, fetch the correct data and start the process over. Meaning the performance hit can be orders of magnitude higher than cache misses. In the worst case it has to start all over again and potentially even wait again just for more data, which might be discarded yet again.
Speculative execution is a massive game changer and without it, we're probably going back to CPU speeds of the late 2000s in an instant.
Thank you for presenting my argument in a much better and more detailed way. People are certainly free to think that they can live without this feature. But they should be prepared to have a really bad experience at best if they really want speculative execution gone.
Brodie isn't a programmer. He doesn't understand hardware. He's just talking out of his rear end in this video.
It's just that speculative execution and caching should keep track of the current security context, and not mix them. It's also the fact that speculative execution runs before permission checks.
@@mohammedgoder He does acknowledge he has limited knowledge about CPUs. I'm not an expert either, I just happened to know that specific fact because I'm writing my Bachelors about TEEs on processors so I need to have a rough idea how the pipeline works.
He has studied CS just as most of his viewers, but it's a wide field and modern processors might as well be arcane wizardry from Harry Potter to most people in the field, especially with what little documentation is available. People need to infer architecture specific details from patents Intel made because there is no better source for this. You need to cut people some slack.
@@JohnDlugosz It physically cannot keep track of that. Segmentation and Paging is not the job of a processor, it's the job of the Kernel. The processor has absolutely no knowledge of what security context it currently is in and is completely agnostic to what memory segments a user has access to, that is by design. Hell, for all that matters the processor doesn't even know what a user is. There are no checks surrounding this, because negotiating page tables with the Kernel would just turn your 14th gen Intel into the equivalent of a CASIO calculator in terms of performance. Without this type of flexibility it would also get even less likely that you could write compatible operating systems.
And I haven't even started talking about virtualization yet. There's a long list of complex calls you need to make to even get something as simple as Intel SGX to run which assigns a protected space in memory that physically restricts access to memory via the on-board memory controller inside the CPU, and even that has its drawbacks and is terribly difficult to use and implement correctly. And even THOSE types of techniques don't break segmentation.
I don't think this will ever be fundamentally solved. As Linus Torvalds said in one of his interviews, "if you want to have any performance at all, you have to speculate".
if you speculate based on bad inteligence... You will get warfare...
If memristors ever become a thing, maybe then. The idea is that it will enable non-volatile memory, a bit faster than RAM. So me might not need L1-L3 cache. Or maybe just L1. And we'll no longer have RAM and HDD/SSD, just memory. But it's been years since I've heard about that and still nothing, I'm kind of leaning on that being just wishful thinking instead of "cool new tech that's still stuck in the lab phase".
@@Winnetou17That would not solve anything. Just think about it, why do we have three levels of cache on the CPU? They are all SRAM anyway. The reason is that larger caches physically need more space, and thus necessarily are further away from where the data is needed. You need caches to be small to get low latency.
@@Winnetou17Issue is to remove every kind of branch prediction you need RAM thats fast enough to serve every CPU core at whatever speed the CPU needs.
It's not really an issue of NV Memory being slow but RAM being too slow for modern processors.
Would it be possible to get rid of speculative execution on specific sections of code? That way most of the code is still fast, except for the part that encrypts your messages.
The fact that my Ryzen 9 7950X which came out towards the end of 2022 is still impacted by Spectre is kinda crazy. At least they fixed retbleed in hardware.
The funniest fact of them all is... The human brain is BUILT upon speculative execution.
The lag from your eyes and processing the data is just too slow, so the brain actually does speculative execution based on what it thinks happens next.
Kyle Hill has a nice video showcasing this video in great detail...
Good news is... No Spectre like vulnerability exists for the brain yet though.
your brain does not really execute arbitrary code either
@@aeghohloechu5022 just wait until neuralink chips become more common and someone will find a way
Not yet.. but I'm thinking it is possible, just somewhat complex, and not as powerful as CPU exploit, since sensitive data is spread thru the brain, not just in cache
Pattern recognition and brain wave / brain activity reading could hack a brain's contents. Also we know how just fast-talking can ram logical fallacies through to a person's dopamine generation. When we study this as a science I'd bet we'll see how politicians were doing it for centuries on instinct.
@@aeghohloechu5022no, but your brain does have intrusive thoughts.
MSI refuses to update their agesa bios for their b450 motherboards anymore. And AMD expects mobo manufacturers to update microcode for them. It should be criminal really.
Good to know. Luckily Gigabyte still updating on X570 motherboard in 2024
Linux updates microcode on its own :)
@kodeytheneko Yes I use arch now BTW!
@@user-in2cs1vp6o nice, I have been using arch for a long time. Ppl keep trying to get me to switch to nix tho
I guess the gigachad move is to have an old burner that has mitigations on and a secure no-network PC with mitigations off where you just live off docs and man pages
Sounds like a good idea, two systems both running, perhaps with circumscribed ways of copying between the two under user control and caution.
No one else remembers the papers in the 1970s warning people to be cautious about speculative execution at the cost of security?
Pepperidge Farms remembers...
For once, that is something that's before my time.
ok boomer
I just wonder how many potential backdoors are unfixable in the intel management engine.
probably as many as in Nvidias version of it in their GPU or AMDs version of ME in their CPUs
ok no more management engine sure, no more overclocking in any way from your desktop, no more updating uefi from desktop and so on
@@bigpodallegedly GPUs don't do speculative execution
@@XGD5layer i was talking about management engine look at the comment im responding to
The terminal opening wasn't by Brodie, it was a malicious hacker and was angry you were talking about this. Stay safe, Brodie!
One thing I didn't catch was how long it takes to do such a covert read without privileges. The data is in a very specific place is it not? Now if it only takes a minute or so to use the covert channel to sniff into it, wowee. I wonder if security can be worked from another angle, catching processes which seem to be doing this kind of sniffing. Every timer read is a system call, or am I mistaken? One would not want to smite down something like a game, however, that keeps looking at the timer to gauge its performance.
Here's the thing: until 2018, CPU design didn't have security in mind in the area of speculative execution because **no one had thought that it was something someone could exploited**. It wasn't intel and AMD skimping on security, or cutting corners, or cheating. These exploits were completely unheard of before 2018.
Keep in mind, speculative execution isn't just "a bit more performance", it's like 10000% more performance than not having the feature at all.
Here's why (simplified):
In an ancient cpu, each instruction would take say, 6-10 cycles, with some taking 100+ cycles such as division. These instructions usually consisted of a number of common steps, like "fetch", "decode", "compute", "write".
In trying to optimize this, they came up with segmented architectures, that's architectures that could do a "decode step" of instruction 1, while "fetch" of instruction 2 is already happening. This means 6x the speed vs older architectures, but the cost of it, was that branch instructions had to wait until the entire chain of in-progress instructions was done, before they could update the instruction pointer.
Later even, they came up with superscalar architectures, which was a more advanced form of segmentation that could handle having multiple units of the same kind and assigning different instructions to each unit. And later still, they came up with out-of-order execution, with even longer pipelines and even more units, and instructions that didn't have to execute in the same order they arrived at the cpu. But as you can imagine, having to flush the entire pipeline would be extremely slow. think like, 2000+ cycles of the cpu doing nothing, until the branch can be decided!!!
It was the late 70s or early 80s in which I, an electrical engineer who studied computer architecture, had learned how seemingly secure data can be deduced by playing games with the cache. This idea ain't new, groooooooan.
@@SeekingTheLoveThatGodMeans7648 If that's the case it is news to me. Everything I read at the time spectre and meltdown were announced indicated that speculative execution had never been considered a target until that point.
I will admit, though, that my knowledge of computer architectures is relatively high level. My title is in Informatics Engineering. We did learn this stuff, but nowhere near detailed enough to go into security. Security was not even mentioned at the time outside learning what an MMU is. "At the time" being sometime in 2003-2004.
Meltdown only affected Intel, so there were some considerations by other vendors.
Fast or secure: choose one.
I choose fast.......
@@Nunya58294I choose secure
One of each. Have to be careful not to pay bills on the same machine used to play games, though. Something like QubesOS, only not as extreme and more automated.
I can't choose... That's the reality... I want secure... Can they deliver?? NO... Basically x86 is bad design... New designs isn't far better... We don't have "reasonably secure" PC... Where we can check every line of code... (OpenPower? RISC V? - we're not even close to that concept... and where can I buy one outside of US in store now?)
@@Nunya58294 why do you choose fast? Do you like your politicians blackmailed to trample on your rights?
I had a friend who a little over 20 years ago predicted the exact problem with branch prediction and speculcative execution that is plagueing so many x86/x64 CPUs these days.
His mantra was: "Don't ever, ever, design a CPU with branch prediction and speculative execution. It is better to have a slower-performing CPU than a CPU riddled with security issues."
Turned out he was right. Too bad he didn't live to see his prediction come true.
Oh yeah, it does seem obvious on retrospect. Give the processor the ability to shoot wildly under the hood, and cleaning up all the telltale miscues is not going to be trivial, to say the least.
Speculative execution is not cheating... This is not exclusive to x86 CPUs. It's a fundamental part of all modern CPUs.
The CPU engineers definitely didn't think about these issues when they came up with these optimizations. Now the only solution is for them to flush the cache on every context switch for older CPUs.
There is a possible solution for future CPUs. CPU and OS vendors need to provide support for a system call that allows programmers to mark memory as unsafe/safe thereby letting the system know that only the marked memory regions need to be flushed. This would solve a lot of these timing attacks and significantly reduce the overhead of the security mitigation.
Intel was cheating, they were deliberately leaving out certain security measures to keep their performance dominance over AMD, which did implement a lot of the security measures and were thus much less impacted by the spectre/meltdown mitigations.
The initial approach was, it was designed with the best of intentions initially however it's clear that serious issues remained present for years undetected. Now that they are known about that initial performance was never supposed to be there as it only happened due to these issues not having been addressed yet
I think you agree with me more than you think, but don't like how I framed it
yeah the spectre class bugs are quite nasty. speculative execution is needed because memory access is slow, while you wait for memory to respond you might as well go ahead and try process ahead of time, the issue is what happens if something ahead of time needs to also access memory? might aswell ask ahead of time so its ready in cache if that branch is taken and we need it anyway.
the issue is what happens when we dont take that branch, you just wrote over some cache with data that shouldn't have been read. you cant undo that overwriting. the issue is cache is also the most expensive area wise for a CPU so to be able to revert you'd need something like a shadow cache to rollback those changes. so the alternative to make the branch predictor know when its speculatively executing privileged data vs unprivilaged data. but it turns out you can also train this behaviour to mispredict that it is speculativly executing as privilaged/unprivlaged, which this latest paper demonstrates.
When you're in a speculative branch you're basically omnipotent on the system with respect to the cached memory space. No privilege checks happen during this phase. If the branch proves to have been genuinely taken once the condition has been determined, then any security violations are acted on, with segmentation violations as required.
I then fall into category 3. I always buy completely overpowered CPUs so that after all the patching I can get to the level I want - somewhere in the mid-range ;)
That's actually an intelligent way of thinking about it.
2:10 "If one of the guesses is correct, there is an increase in application performance. If the guesses are wrong, the CPU throws away the previous work and proceeds as usual without changing performance."
This may have been the case when we started doing speculative execution, but no.
The only reason why CPU are so fast these days (and yes, that's architecture independent, high performance ARM and RISC-V CPUs do speculative execution too, some ARM64 CPUs for example were hit in 2022 by a spectre-like vulnerability) is because of speculative execution.
There is a thing called a CPU pipeline, imagine it as a production chain.
At the beginning, there is somebody putting material (instruction) onto the pipeline.
Then some parts of the CPU work on it (e.g. decoding what it means).
At the end of the pipeline, the thing is actually finished.
As one can imagine from that description, that means executing a single instruction has multiple steps.
But what happens when we get to a branch? For example an IF.
Well, we can either starve the pipeline until we get the result, or we try to make a guess.
Modern CPUs are really good at guessing, so if you write a program to not explicitly try to confuse the branch predictor, it will be considerably more correct than wrong.
And when it guesses wrong, everything needs to be pushed from the production chain, which means that the pipeline will be starved, and it can even mean that the CPU needs to undo some stuff (in case you don't know, a single CPU core can execute multiple instruction in parallel if the aren't related, think of "add a to b" and "add c to d").
I ran into cases where the branch predictor predicted wrong in about half the cases (there are tools to measure that) and after swapping things around to get it to above 90% correct, it had about double the throughput.
It was a tldr explanation, you'd need an entire video to itself to explain how the pipeline functions
"Well, we can either starve the pipeline until we get the result, or we try to make a guess." At least in theory, there's a third alternative: Work on both branches simultaneously. That's of course less performant than working on a correctly predicted branch, but has more predictable performance (less dependent on which branch is ultimately taken) and certainly is more performant than just starving the pipeline. Now it's possible that this can't be done in practice (either because it would be too much effort, or because of some principal limitation that I'm not aware of), but from a purely logical standpoint, it should be possible.
While I agree that speculative execution was not designed with security in mind, it's performance gains are way too massive to give up. Going back to a CPU design without it would not be the solution. What we need instead are more effective ways to disable this feature where we handle critical data, like in the kernel, when handling passwords etc. After all, if all you do is to do uncritical work you can accelerate it a lot by running it in this unsafe but performant mode. It definitely positively sucks for everyone with a vulnerable CPU as the software mitigations really kill performance but at least newer generations of hardware come with the mitigations built-in. This at least recovers some of the lost performance. As much as people may not like it this is the most practical way forward
As someone who's most certainly not an electronics engineer, I wonder... Why not? 🤔 We already have all kinds of modes for modern CPUs. Why not a "xsafe" or something mode with safety from speculative execution?
I really like this idea, and I hope they do implement this. A processor "flag" that can be toggled on a core and disables speculative execution while set. This could be implemented by operating systems by letting you enter/leave high-security mode.
@@gigaherz_ Or they could just add secure fixed timing cores with no cache hierarchies, speculative execution or speculative data fetching along side their high performance cores.
@@mohammedgoder That seems the most logical solution. Multi-core chip, one core with speculative execution, one without. Problem solved. Perhaps they could make up the performance difference with more registers.
The problem with this is on servers or really anything handling a large amount of sensitive data. You're going to go back to the stone ages of computing if you do this.
That's not all true, every major ISA has a branch prediction/speculative execution design, there's probably some bad design choices made when implementing this feature in x86_64, however that's a major reason of why the CPUs are good in the first place, nowadays you simply can't have a design without these things and expect to be competitive, you either have branch prediction and speculative execution or you don't have costumers
I am curious if you can disable branch prediction or speculative execution completely to see how slow cpus would be without essentially cheating, but also, those 2 things aren't bad in theory, they just need to properly clean up the cache, registers and such if wrong
Branch prediction and specularive execution are not ISA features. It is a microarchitecture feature.
You can have x86 CPUs with or without those features, implemented in different ways, same thing for every other ISA.
That is why AMD CPUs have been less affected than Intel ones, differnt microarchitecture.
it's not just x86_64 which gets hit by these types of attacks
but it's considerably more often than the rest
@@rj7250a ... You don't know what you're talking about.
AMD and all other modern CPU vendors also uses speculative execution, branch predicting and speculative data fetching. The vulnerabilities are a fundamental consequence of variable time performance improvements.
@@mohammedgoder i said less affected, reading much?
That is what i said, those are microarchitecture features, not tied to the ISA, every ISA can implement those features in any way they want.
Read carefully before trying to sound smart and inflate your ego.
I know it's going on because every time I configure my kernel when I update the list of workarounds gets bigger. They have an entire section for these mitigations now.
speculative execution was not built recklessly without security in mind. thats why it took a decade to find a problem with it. it basically enables modern computing and going back just isnt an option
It wasn't at the time but in retrospect it had serious flaws, most well intentioned people don't intentionally build something broken
@@BrodieRobertson Also the general idea of playing games with cache and cache activity to get a look at otherwise privileged data is not new. Late 70s to early 80s is when I first got a look at this as an electrical engineer. How many 40 or 50 year old designers were involved with these chips, anyhow? Did economics inadvertently handicap wisdom?
Isn't this kind of thing also happening on AMD and ARM?
Yes, it has happened for various CPUs using branch prediction.
ARM was/is vulnerable to at least some variants of Spectre.
same thing on RISC-V, but it's just plain unpatchable on that arch because it's well...designed too simply to be able to patch spectre/meltdown. that's why people say RISC is bad for security lol
Yes, but not nearly as badly.
It seems as though some of Intel's incredible speed gains on older Core processors was down to Intel not doing things "right" if it meant they could gain some speed by doing it wrong.
It's not about Intel CPUs... That vulns exist even in Apple M* chips... And... CPUs where always "not secure" - You can't even disable AMT and remote administration on some of them... newer than some pentium number (caugh).... And... Bios/ UEFI is flashable from OS that can be exploited? what a perfect solution!!!
I have it all disabled. Living on the edge is fun also so far no issues on mine.
I ran "lscpu" today, to see how much L1 and L2 cache I have and saw that you have there listed the mitigations enabled. Apparently I don't have them all on. But not all off either. I didn't changed or did anything about them, even though I'm tempted to leave them off, the CPU is old, and I couldn't refuse any performance improvement.
But at the same time, I DO have many apps, I do browse the web, I do have some proprietary apps, so I absolutely have to have the mitigations enabled. Sigh.
I wouldn't be surprised if a lot of the mitigations are off by default. I suspect you could largely mitigate it with memory barriers around every system call, but it would be very expensive.
@@brainwater Yup, most likely, on both your accounts.
Mitigations that don't apply to your CPU model will be switched off
technical debt.
Tangent:
Everyone needs to start putting the bars for "lower is better" graphs on the right of the graph going left, and the bars for "higher is better" graphs on the left going right
That way no matter what, the edge of the bar is further right for "better"
Lower is better:
|_=====|
|___===|
|__====|
Higher is better:
|=====_|
|===___|
|====__|
Or the other way, I don't care that much about the final convention, my point is that we have a way to visually encode which is better in a very clear and consistent way. Obviously still label "bigger better" or "smaller better", but if we make it so that both cases are "further right is better", it'll be really easy for everyone to know at a glance which it is, if the convention becomes common
If you profiled and optimised your code, you know that branch mispredicts are pretty expensive and can result in noticeable performance loss. Without a branch predictor every branch, every if, and especially every non-unrollable loop would be a very expensive operation, and writing efficient code would be a nightmare
Pipelining is necessary for substantial performance gains. And if you don't want to lose this great advantage each time the program does conditional branching then you need speculative execution.
Now maybe adding something in cpus and programming languages so that the programmer can actively prevent the speculative execution of specific part of the code could be an idea(I suppose putting some amount of NOPs (or generally useless operations) before the real code could probably prevent it but it's a bit of a hack). Because putting all the work on the cpu at runtime to determine if something should be allowed to be speculatively executed or not seems to me like a potential rabbit hole of conditions...
IA-64 going by some articles runs both branches and only commits results from the one actual taken, not sure if that would be more vulnerable or less vulnerable to the speculation side-channels.
@@1DwtEaUn it probably depends on what "commits" means exactly. As an example if an instruction stores something in memory will the cpu stall before the condition is resolved or not? If yes well you lose potential speed if no you lose security (worse than speculative execution because both possibilities are always executed).
But yeah idk what they do exactly. I will check this out
I started with "mitigations=off" on my main PC because, after spectre&meltdown, my PC couldn't run PCSX2 as it ever did. After tweaking the grub configuration, I never went back. I paid for every clock cycle and they will be used to their fullest.
A spectre is haunting computers. The spectre of branch prediction
I literally had no choice but to turn off the mitigations. My PC was basically unusable. It's now as fast as the day I bought it in 2017. My CPU is basically a naked runner at a shooting range, amazing.
0:24 Or as I've recently taken to calling it, Spectre Plus Meltdown
I think the real question here is: are the CPUs manufactured AFTER Spectre safe against it? Or did they never even fix it because "it can be fixed in software"?
As for the question about mitigations: my PC never ran "well", even before Linux. Losing some additional % to mitigations doesn't even stand out against the % lost to drivers not getting the nephitism treatment that M$ established. Talking about stuff like nVidia drivers which just now are becoming "usable" in performance.
Some of both... They will be fixing future designs for at the time known 'bugs' but stuff found later or to close to CPU launch, will have to be software fixes.
It's looking like it's not a "fixable" problem but a fundamental problem with speculative execution and algorithms that do not run in fixed time.
Not sure how true it is but I did hear CPUs take a crazy amount of time to design, like 5-10 years
@@JordanPlayz158 They run on a 3-5 year cadence nowadays. AMD has two CPU teams that leapfrog development for the next generation of their CPUs.
@@mohammedgoder Ah I see, very nice, makes sense as my source was someone who was in the space in an older time
In 2018 two things happened: Spectre and Meltdown were published and JavaScript became part of a HTML standard, namely HTML-5. Since then web developers further increased the tons of untrusted code that people have to run in their browsers a thousand times every day. Can you spot the contradiction?
The reason the original researchers called it Spectre is because "it will haunt us for a long time", we knew in 2018 this isn't going away
Also, proverbial ghosts (if not real ones) easily traverse walls.
I do wonder if IA-64 aka Itanium approach of running both branches and keeping results of the one taken is better or worse in regards to side-channel issues
It's more about the rollback thats the issue. Not the execution itself.
@@mohammedgoder which is why I wasn't sure if the run both and commit only the branch actually taken would be a protection, or just open up other worm cans
Itanium chips weren't vulnerable, but not for the reason you describe. Indirect branches and control speculation still exist on Itanium, but they are handled by the program code itself. This means that predicted targets can't be set by unrelated code.
Would I rather a CPU with no security flaws? Of course. Can I see a use for CPU's that are 100% faster on certain tasks but have a massive security flaw? Yes, absolutely. Anyone using one of the affected CPU's without mitigations needs to be careful but at the end of the day it's a cost to benefit calculation.
I agree with the folks defending speculative execution. It's the very idea that makes modern CPUs any good, and it's also the thing that inherently causes these vulnerabilities. There is no way around it, we will just have to keep patching it as security researchers come up with new ways to exploit them, and hope that we've done a good enough job mitigating them. Nobody wants to go back to Intel Atoms, which were actually in-order CPUs, without speculative execution, on a more recent microarchitecture than the 90s last high-end in-order chips (original Pentium). They were also terrible.
I lost it way harder than it probably deserves when I saw that the external researcher called his paper 'InSpectre Gadget'
0:51 Classic arch user lmfao
mitigations=off should only be applied on strictly stand-alone computers, otherwise it would be akin to preparing kindling next to a fire that spits out glowing embers from time to time. It will be a matter of time before you'll burn, but it will be inevitable.
Dammit Phil.
Lmao
im the type of humans who appreciates security. and thats also how i can recognize something is not secure. because how i appreciate that aspect so much, and always put forward that first. its like, "living on the edge" but with full body armor. so then i will know if the armor is failing. 😁
Subtle Arch btw moment.
I usually enable mitigations because my CPU are pretty new. I think it's just that slight piece of mind that makes me not wanna turn it off
I use them, but im mad as hell about it.
isn't the fix literally as simple as just having speculative code execution check if the memory slot it's accessing is protected, and if so, clear the cache its data is stored in, then return?
When making a keyboard shortcut program, the thought of it trying to execute without the keys being pressed drove me bananas. Is it using otherwise wasted cycles or is it using more power at simple stuff?
Typically otherwise wasted cycles.
This makes me wonder about performance metrics used In the AMD vs Intel speed competition. Are the processor scores shown in benchmarks with or without the mitigation patches applied? Which one is really faster in the end?
Usually without because private users are the target of those videos. Nevermind the fact that mitigations roll in all the time, voiding those benchmarks
1:40 > _"SPEC-ulaTive Execution"_
ohh, thats how it got its name spectre
Speculative execution isn't bad, it's a clever feature and necessary for the performance we've seen for decades.
The actual problem was mixing it with hyperthreading, which led to this whole mess where one thread can observe information leaked by another.
The mitigations most likely aren’t exactly throwing all of speculation away. Even to theoretically completely fix the issue, you don’t need to ditch branch prediction, but you do need to either return the program-accessible state to a version without the any effects of the speculated instructions or predict the safe route (eg branch hints) when there is one (otherwise yeah no speculation).
I think it's best to think of it as a complete trust efficency gains. If your system isn't networked, turning off the mitigations with exclusively trusted software gets you a small bump.
8:03 this is just wrong. speculative execution has protections in place for doing this sort of thing. if you access any memory that you weren't supposed you won't be able to use it. the exploit uses the fact that your cache isn't being reset as the attack vector. there are videos that explain it better than me but the point is they didn't throw security to the wind
If only he read papers like "Secure Speculative Execution via RISC-V Open Hardware Design" maybe he'd learn a thing or two, but no. Keep raging against the machine, Brodie. I'm sure the ad revenue was worth looking ridiculous.
So i need to take care of this too...
The list of requirements of my CPU is steadily increasing... 😅
Here's an idea: Add a GRUB entry that disables mitigations but also disables networking and KVM. A sort of boot-time game mode.
On my old laptop with a sandybridge cpu that doesn't have hyperthreading but is still vulnerable to some of these exploits, benchmarks show no difference between default and mitigations=off so i just keep it running stock. I also have desktop with r5 5600 and turning mitigations off there also doesn't seem to have any impact so i'm also keeping it enabled.
i have seen some CPUs where disabling earliest Spectre and meltdown mitigations actually makes the CPU slower
If one were running code on one of these processors in a system that had no access to a real time clock, no side channel would be possible to the side effects of speculative execution. That said, I'd think it trivial in a multi core system to keep a loop locked onto one core busy just counting as fast as it can, and to use that as a comparative clock to check the performance of data accesses by another core.
We currently have some security in hardware it seems to me that if the CPU started to implement a lot of the security controls that are in the OS it might be able to reign some of these issues in. However coming from a hardware background i can see how much more complicated the hardware will become.
I was actually the guy that had a Ryzen 7 1800X and when retbleed came out and affected SMT I set my kernel flag to retbleed=auto,nosmt for maximum security...but call me paranoid. Yes that did disable half my CPU threads. I did initially try the IBPB full option but my system became unusable so I went back to auto(unret). I never removed that flag from my kernel command line but I've since upgraded to a 7950X which is not impacted, but the line is still there because I'm lazy.
Seems like the solution is to only use speculative execution when explicitly requested by a program. Thus the default is to be secure but you can sacrifice security for performance if what you're running doesn't deal with sensitive information. (yes, I realize this would have to be implemented at the hardware level)
My CPU was chosen with the mitigations in mind. It is fine for my use case currently, so no need to turn mitigations off. I am looking for an ARM based CPU/board for my next workstation upgrade however. This, (and other concerns) also pushed me into getting a MacBook for my laptop. Good news there is that the Asahi/Fedora remix is looking very good. Bad news is that Apple's current M series chips have a hardware exploit as well (sigh).
"The CPUs seemed to be designed in the dumbest way possible" - candidate for hyperbole of the century. Don't you think you should be more charitable to the engineers?
Not really no.
@@snowthearcticfox1Yes, really. There are many ways that engineers in the computing scene have used to increase performance, and most of them (at least as of now) didn't cause any security issues. What you think is dumb here just made sense years ago and wasn't a serious risk at the time.
@@RealMephres The problem is that they didn't just make this mistake "at the time" or "years ago," but that they are also still making CPUs with the same vulnerabilities currently.
@@MNbenMNThat's true, but at the same time, this is moreso a marketing and corporate issue than the one on the side of the engineers who worked on those CPUs.
@@RealMephres I find it funny that some people think that speculative CPUs are "cheating." These people are the same people that shill rust and haven't ever done any serious programming.
There's definitely some solutions that can be implemented but it will require new CPU instructions for marking memory as unsafe/safe.
I remember seeing mention of SPECTRE V2 mitigation few years ago in Linux kernel
These types of things have happened even with older hardware. I remember blockcipher CAST being broken on some power pc chip that had data dependent cycle count for multiply instruction. I think it was faster if inputs had lot of zeroes or something like that. Which obviously leaked information from inside the block cipher if attacker could time encryption/decryption. Details are hazy since it was a while back thou and im going by memory here.
Mitigations/new microcode actually caused OS-independent frametime spikes and hitching in Dark Souls 3 on my i7 5820K back then.
I'm not affected by these 💪💪💪 (Running an old intel atom which doesn't do speculative execution)
Think again... That's where it all began.
@@mohammedgoder erm, that's where you're wrong sweaty 💅💅💅
lscpu vulnerabilities for Intel Atom N455 Pineview, Linux Kernel 6.8.2
Gather data sampling: Not affected
L1tf: Not affected
Itlb multihit: Not affected
Mds: Not affected
Meltdown: Not affected
Mimo stale data: Not affected
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Not affected
Spectre v1: Not affected
Spectre v2: Not affected
Srbds: Not affected
Tsx async abort: Not affected
This is because this era of atoms is based on the Bonnell microarchitecture, which uses an in-order dual-issue pipeline, meaning it is completely different from Intel's out-of-order speculative execution designs which are the ones vulnerable to speculative execution attacks like Spectre (discussed in this video). Because of this design, the Bonnell architecture resembles that of Intel's P5 architecture that came out in 1993 more than anything else.
The Atoms are THAT bare-bones? I think x86 got speculative execution with the Pentium, so... they're dropping a LOT.
@@CptJistuce Early Atoms were designed from scratch because Intel's existing work at the time couldn't hit power targets, lots of innovations that made their current processors fast had to be left out. You might also be thinking of the 1995 P6/Pentium Pro.
An engineering tradeoff like this really requires the engagement of the OS developers for whatever will run on this processor. If there's a hypothetical back door, at least obstruct it through the OS.
Not only on the edge… i literally build my own kernel without any security or memory config enabled
Can't we create a secure-integer load cpu instruction that forces the pipeline to stop and no predictive execution to run when that kind of data is around?
Maybe it would be time to move to processors that are not programmed by imperative programming but functional programming? In functional programming you can calculate a lot by speculative evaluation but the code cannot observe it. Then processors only need a way to separate I/O code from non-I/O code.
Linux, Windows, MacOS - I usually don't really care much about the mitigations. It's as you said: this "performance" should have never existed in the first place.
0:51 greatest I use arch btw so far
I don't think it was a "bad design" - the fundamental flaw is "I can figure out what the value is by observing the time of some other operation" - it's a timing/side channel attack rather than a direct access.
Result is the same but if you're doing speculative execution for speed you may not think about people measuring the time of an operation after a branch not taken to derive the value that that branch would have produced.
Even in software, almost nobody thinks about timing side channels except maybe people deep in cryptographic algorithms.
kinda confusing, isnt this attack specific to physical attacks? as in: i need to get important data so i put a pendrive with any OS and use an app to read what is happening when i turn on the main HD?
A definitive no, these attacks only get you data in the running system. If you boot your own OS then the original OS isn't in memory anymore.
I want to ask if this is a problem for ALL CPU’s or is this more of a 2018 and onward problem CPU’s and how do I know if I’m affected
Anything from the last 17-20 years.
@@mohammedgoder ah I see so we all are screwed thanks
I still dont get what the subject of the video was.. something something cpu
@@evanknight8572 According to Intel/AMD; you should be fine as long as you keep the software mitigations enabled. Although there is a heavy performance penalty for enabling them.
There are some things that OS vendors can do in software to significantly reduce the overhead of the mitigations. I doubt they'll do anything about it though.
@@OlviMasta77 CPU security vulnerabilities.
7:30 . . . But I thought that the whole point of being proprietary was that you only have to care about speed. Because the code is secret.
6:55 stacking debuffs 😭
Intel has taught us that cheating on tests is actually one of the few useful subjects the school system teaches
Branch prediction is a basic technique in execution calling it cheating is a weird interpretation to me
Quality distros have "spectre-meltdown-checker" in their repo
It should be noted that Meltdown and Spectre are only really dangerous if you run malicious code on your CPU. If an attacker can run malware on your computer, then they don't really need Meltdown or Spectre. The only time this is really an issue is for environments where multiple segregated tennants share a CPU, aka shared hosting, cloud environments, etc...
Keep in mind that bugs can lead to unintended execution of malicious code.
It all boils down to using a proprietary cpu, proprietary memory chip, proprietary motherboard and proprietary firmware on all of them, so open source software has no way to escape these flaws by itself until some freedom fighters come out and decide funding open source hardware especially things like cpu, ram and motherboard
What i did is very basic, but kinda smart. i made two boot entries, one that has mitigations on this the default and one with mitigations off this when i play games or i do anything that really needs every drop of proformace, so i kinda balanced between security and proformance. Let me know what you think about this trick
So Theo was right all along.
Speculative execution is a basic technology in modern CPUs. Nobody will get rid of it because of minor security vulnerability (it's not exploited in the wild). If you want to use CPU with full performance (e.g. for games) you may dual-boot Windows. And disable mitigations on Windows. Just don't visit not trusted websites.
So essentially we need to get back to monke in cpu terms
Still on Bulldozer and Sandy Bridge over here. I am monke.
@@erinw6120 Sandy Bridge does speculative execution, and was impacted by Spectre and Meltdown too.
@@mss664 True, but AFAIK, it's not affected by the new Inspectre Gadget issue, at least according to the absolutely confusing Intel chart.
You would think that after the original Spectre and Meltdown that they would audit their entire branch prediction and speculative execution pipeline and implement new internal requirements for securing the data. NOPE! That's an upfront investment, and companies don't like that!
There are some chips which don't have these problems, but they're not CPU's that we'd be buying for home computers.
I would've happily enabled every single mitigation to run my system secure and always tried to do so by simplifying things to be able to control them and understand what is happening, but todays browser and todays web is so bloat and ugly that you just can not trade away that performance, especially on laptops where heat management and battery drain can make difference as much as working for 8 hours and working for 3 hours. Not to mention that you can achieve 20 hours fully working PC if you're openned only static sites and code something in vim. They played us like a fiddle.
Any CPU today uses branch prediction there are even things in ARM chip…
Most modern Chips need Spekulative execution to work, else you get back to a very dark time.
Sounds like as long as almost everyone else uses these security fixes, it means some people can get performance increases by not using security fixes. Well then, like Brodie, I recommend everyone else should not disable kernel security mitigations.
this vulnerability is making me glad i went with AMD for my linux home server
We need to stop relying on the MMU for security. The processor should have a way to restrict a process to a 48bit address range. and then have the MMU map everything that the process needs into that range. Then the speculation engine could also enforce that range. This allows the MMU and cache to focus on what they are good at and the processor has a simple rule to follow.
One simple solution, stop using out of order execution, & any other variant like speculative execution, & stick with in order execution with hardware based scheduling to allow for parallelism on in order hardware, so CPU core becomes so called, pixu's(parallel in order execution units) for future hardware onwards, I think that'll solve the spectre & meltdown problem for certain!
good thing about using an amd cpu is that I don't need that many layers of mitigations
I don't use mitigations=off. I just use kernel compiled without them.