Zenbleed (CVE-2023-20593)
Вставка
- Опубліковано 1 чер 2024
- Let's explore the "most exciting" CPU vulnerability affecting Zen2 CPUs from AMD.
Watch part 1 about fuzzing: • The Discovery of Zenbl...
buy my font (advertisement): shop.liveoverflow.com/
This video is sponsored by Google: security.googleblog.com/2023/...
Original Zenbleed Writeup: lock.cmpxchg8b.com/zenbleed.html
Grab the code: github.com/google/security-re...
cvtsi2ss: www.felixcloutier.com/x86/cvt...
AMD Security Bulletin: www.amd.com/en/resources/prod...
RIDL Video: • How The RIDL CPU Vulne...
Tavis Ormandy: / taviso
Chapters:
00:00 - Intro
02:27 - zenleak.asm Patterns
03:56 - The C Exploit Code
05:20 - Assembly Generation with Compiler Preprocessor
07:40 - What are XMM and YMM Registers?
11:56 - Zenbleed: Trigger Merge Optimization
14:28 - Register File & Register Allocation Table
16:39 - Register Renaming
17:55 - Speculative Execution
18:55 - vzeroupper and SSE & AVX History
21:22 - Zenbleed Explanation
23:55 - How to fix Zenbleed?
=[ ❤️ Support ]=
→ per Video: / liveoverflow
→ per Month: / @liveoverflow
2nd Channel: / liveunderflow
=[ 🐕 Social ]=
→ Twitter: / liveoverflow
→ Streaming: twitch.tvLiveOverflow/
→ TikTok: / liveoverflow_
→ Instagram: / liveoverflow
→ Blog: liveoverflow.com/
→ Subreddit: / liveoverflow
→ Facebook: / liveoverflow
SLIM VIDEO UPDATE! For over a year I accidentally recorded my video stretched in width. It's fixed now
i actually didn't notice it
FatOverflow is no more
😂 Yeahhhh! Great!))))
I want a video about what the hell is micro code and how it can fix these issues.
@@RohitKumarAnkam modern CPUs aren't truly x86 CPUs. they have their own internal non-x86 machine code, and expose that to the world through an x86 abstraction.
the x86 abstraction layer isn't fully hard wired into the chip, and can be reprogrammed by flashing a new firmware onto the CPU.
there can be bugs in the underlying hardware, or in the x86 abstraction layer. the x86 layer can often be patched to work around either type of bug, or fix them.
CPU manufacturers don't often post full listings of their CPU firmwares, or fully document their microcode implementation layer. they often end up being a proprietary trade secret.
Note to self: the parts of microarchitecture that made my brain hurt when learning about them are where all the worst vulnerabilities live
we made a pact with the devil the moment we decided that the cpu needed to try to be smart about what it runs and not the program smarter in the way it runs in the cpu.
I've always said that this stuff is bs and I rather we use less performant but more barebones cpus but it is what it is.
its because not even the CPU architects and engineers can fully understand it themselves.
@@ReiikzI think that people that buy cpus based on benchmarks wouldn't do it...
@@Reiikzwith my job in HPC, I'd be a damn broker for the devil for the amount of deals I'd do for him to keep the insane BS that CPUs need to go faster. We've had to go down real far to get the performance we need.
@@naterthan5569We refer to this kind of vulnerability as Eldritch horror
It always makes my mind bend that the CPU manufacturers just made a smaller compiler/software stack inside of hardware to run the actual software we see faster.
Well, think about that there can be potentially multiple models of CPUs running on the same type of motherboard, and vice versa, it's not hard to say there's at least one layer of abstraction inside the CPU to ensure croes-platform compatibility.
And when there's one, there can be many...
Its not a pre-processor within the hardware. x86ASM is still a "high" level language i.e. its not machine code. There's an x86ASM compiler that will compile these instructions down to your CPU op codes. This is where the pre-processor runs and the binary is generated. This is all still in software land.
@@KieranDevvs He's referring to the CPU microcode, which is indeed a tiny CPU inside the CPU that contains the code that tells how to run the instruction in the architecture's instruction set. It's mind blowing indeed
@@alexcani4957If he's talking about cpu microcode then that doesn't make sense either. Microcode isn't for performance, its to add dynamic compatibility and to simplify certain routines. It takes longer to decode a microcode instruction and execute the actual machine code because you're going through an abstraction.
@@KieranDevvsI agree with your point about the performance, but I usually choose to believe that people don't believe that the processor runs actual assembly code...
If everybody would just use the same password, we wouldn’t have to worry about this.
This would still end in xkcd standards.
No security issues if theres no security 🤷🏻♂️
yeah totally. Have no idea why ppl collectively spend enormous amount of effort to try to solve something this easily solvable
I only allow 8-char passwords in my software, so they're all immune to zenbleed.
Problem -> solution
The PC I'm watching this on happens to have a Zen 2 CPU, so I tried the exploit code in a VM.
Sure enough, I found strings that definitely belong to the host machine, including HTTP header data for my browser fetching this very video.
So I just hypervisor-leaked myself with this. Interesting and scary stuff.
Shows how public cloud is a dead on arrival concept for anything that handles sensitive data.
Look at the results of sandsifter and tell me that there aren't instructions there that have even worse security implications.
@@magfal Even ignoring things like this, many providers are simply not GDPR-compliant
You can feel the satisfaction of the person who optimized strcmp to use avx instructions. And also the satisfaction of the person who came up with that zero flag in the register file.
And then the satisfaction of Tevis who came up to use these creatively 😂
@@JohannaMueller57Point it out, then.
My world is shattered. What do you MEAN registers aren't physical location on chips anymore. One of those things i've always thought is that eventually computers are going to be limited because of the times it takes to send data from 1 register to another because of the physical distance between them.
Admittedly this is way more clever and really cool. Engineers can really do some crazy surprising things when you let em :)
I figured out CPUs would top out at around 3Ghz last millennium based on a board size of about 30cm.
My errors kind of cancelled out. I did not know that the Front-Side-Bus was much slower in modern CPUs (was using a 486 at the time, when Pentium II's were the hot thing). Did not know that the speed of light in copper is only 2/3 the speed of light in air. Those Pentium II processor boards were also way smaller than 30cm.
I'm not sure they've actually been where we think they've been in the first place tbh.
Well, actually... Transfering data between these registers is slow, so they made "shortcuts" where the data can go straight from the computation to another instruction without writing to the register file in between
And If I know correctly modern CPUs are limited mostly by propagation delays in the transistors basically, but also lightspeed definitely
In my opinion, services that rent out hardware should absolutely inform and educate their customers. Imagine if a vehicle manufacturer had a critical issue with their product and a rental service just rented out the vehicles without informing people or fixing it. I realize it's not a great metaphor but hopefully you get the gist of my perspective.
Yes and No. You see, investing in good communication with your customers cost money and not all companies can. They'll end up with the basic newsletter like "this week, we patched all microcodes of our machines, to circumvent to the last known CPU flaws you may have heard of on the news, bla bla blah". But this kind of behavior is detrimental because such a company would be cherry picking bugs. What happens when the company is vulnerable to something they didnt inform about ? Only the biggest companies can inform 24/7 (OVH) about the hundred of vulnerabilities discovered each week and the actions taken. Most choose to stay silent and act behind the scene when most needed.
So AMD should inform everybody.
@@ABaumstumpf AMD does not know who is the end user of a server that hosts an AMD cpu - they might inform Hetzner, but not the customers of Hetzner
No need to inform in this case. You don’t update the microcode per se. The firmware is packaged as a binary blob that your kernel applies at runtime. Even if the server company did not know about the exploit, the moment they update the kernel (most servers are Linux servers) and microcode packages, they are protected.
Hwd rent services in any industry can’t have it both ways. Either its my property that i am liable for during a time duration, or its their property that they are liable for that I am paying for the privilege to use. If the liability is on the customer then the customer should get the rights that are associated with being able to avoid them!
I was really into assembly back in the x86 days, fascinating to see how CPU internals have increasingly become software that's compiled into silicon.
AMD is so backwards. I'm surprised they are still a thing.
Do you happen to have intel stocks or smth?@@Failure_Is_An_Option
This is the best liveoverflow video so far, this is the kind of content we who wants the lower level look on issues want , thanks a lot fab
Oh amazing. That registers explanation makes the register renaming just click instantly. Didn't know they were implemented that way.
This video/series is amazing! I knew the basics of assembly before, but learning about Zenbleed and other similar vulns has always intimidated me, because they seem so complex at first (and they are!).
This is the first time I feel like I understand a hardware vulnerability of this type. Thank you for this explaination :)
My mind was blown when you told me registers work like that. I didn't even learn this in college so these video's are a fantastic source of education. Thank you so so much!
Great video! Small point though, at 13:21, the upper 96 bits of the XMM register are maintained (see the line before the underline); it's the upper 128 bits of the corresponding YMM register that are zeroed. XMM merge optimizations allow the CVTSI2SS instruction to run out of order if it's known that some number of upper bits of XMM are 0
So: Humans have a thing they want to do, and they optimize the heck out of that and turn it into code. Compiler takes the code and after optimizing the heck out of it, turns it into assembly. Assembler then takes it, optimizes the heck out of if and turns it into machine code. The CPU takes the machine code, _optimizes the heck out of that_ and runs it in ... uh, an architecture and micro-architecture specific execution pipeline which takes every shortcut and guess it can? WCPGW? Yeah, a breeding ground for bugs (all mentioned levels, actually).
Again, thanks for covering Zenbleed. This video was even more interesting than the previous (I actually thought the assembly part would be boring, but oh no...) I'm out of vocabulary, and my brain is out of breath. I assumed all registers a CPU has are fixed in the chip, but there goes that old piece of knowledge. (I knew about the zero register in RISC-V but that's used differently.)
Fascinating discovery good work bringing this CVE to peoples attention in such a thoroughly explained manner.
Your Packagemanager of choice should automagically install the new microcode
Fun fact: the Microcode can be patched without rebooting: Microcode should be applied as early as possible, it should be one of the first things your OS does when booting and if you install a new version you shouldn't wait for the next reboot to apply it
As always, it depends. If an update provides additional CPU flags or features, like IBRS (Indirect Branch Restricted Speculation) or SSBD (Speculative Store Bypass), then you'll need to reboot to make those available.
@@dealloc Huh interesting... I thought microcode had to be applied on every boot (as the cpu is missing storage to store it). Did I get that wrong, or is there some point that breaks new features? Like something only being patchable in like 16 bit mode or whatever?
Apparently the fix for this causes 54% of a performance drop for MariaDB. I don't think that it should be installed automatically for that reason. Admin should decide what is more important.
That's inception, CVE-2023-20569. This is zen bleed, CVE-2023-20593. DIfferent bugs. Inception is for Zen 3 and 4, zen bleed is for Zen 2. Zenbleed was only published 5 days ago(i think most operating systems released their patches on the same day or the day before), i don't think people have measured the speed of the fix yet.
.@@_sneer_
@@_sneer_ I think with past CPU vulnerabilities the mitigations were enabled by default but could be disabled if you needed the performance and were sure you were unaffected by the security issues
This was effing GREAT! Man, I feel like I could talk with Tavis for hours!
Great job, both of you!
I know that CPUs have cache, but for some reason I've never thought about how it might be used. "heap", renamed registers and pointers in HW, that's something I've never even started to think about. But now when I think about the parallell/out of order/speculative execution demands it all suddenly fits togerther. It actually makes sense!
Awesome and so much work in this video! Thank you
Thank you for the explanations in this video. The complexity and the mechanisms under the hood are blowing my mind.
Absolutely loved the video. The way you explained it... I am thankful.
Amazing video LiveOverflow. These concepts are really new (for me), like register renaming, speculative execution, merge optimization and the explanation you gave was really onpoint
Speculative execution goes back a long way, and in the 80's and early 90's when I was doing my Comp Sci degrees there, Hatfield Polytechnic in the UK created the VLIW architecture HARP, Hatfield Advanced Risk Processor, which featured an early example of speculative execution and was influential on commercial CPU developments that followed.
Thanks for the understandable explanation. Learned a lot today!
This is crazy! Thank you sooo much for an update on this!
You are an amazing teacher, thanks for sharing this!
My man really called a CPU manual "Really high level" 💀💀💀
Well, compared to the electric fields that bend and twist and flip and flop inside the physical transistors, it kind of is high level 😅
It's all relative. C was a high level language at some point
@@bene5431i'd say C is mid level
@@yarmgl1613"highness" of level is very relative... It almost makes no sense to talk about it. Compared to minecraft command block language, C is definitely not mid level - it's very very low level.
Compared to machine code, even assembly is relatively high level, let alone C. Again not mid level but very high level.
Op code - machine code - assembly - c
Wow, I've learned many new things about the low level internals of a cpu 🤯
That "use after free" way of looking at the topic is remarkable. I had no idea that register files were now indirect like this - I haven't done any hardware stuff for 20 or so years in my student days!
An awesome explanation of how the zenbleed might have worked in practice! I really liked the way on how you dissected and explained each instruction and the relation of "strcmp" libc function with AVX registers. Great explanation and the way it was presented.
Thank you for making such educational videos.
Thank you for the amazing work on this vídeo.
This was super interesting, thank you!
Ich mag deinen Kontent. Ich verfolge dich ja schon seit einigen Jahren. Habe aber selber nicht viel mit dem zu tun. Aber interessant auf jeden! Deine Aufarbeitung ist auch nice. An deinen Englishakzent hab ich mich schon gewöhnt xD
The last part was interesting, i too think it would be good to inform customers of hardware security bugs in their rented products.
I'm really liking the use of "goto boring" in the C code at 5:11. I always avoid goto, but maybe sometimes I shouldn't
Hey, your old video about SIM cards popped up in my recommended earlier and it really intrigued me to see how something I never even thought about worked, in detail.
I was just wondering after watching that video how printers and scanners communicate with devices, through USB and wifi, as that technology has been around for so many years that there will surely be relics of programming from that time still used today, and something like that would be so interesting to me and I'm sure many others as well.
Thanks!
Really good second part, thank you for the really good explanations and providing additional background knowledge. Learned so much from it!!
Holy crap, great explanation! Changed the way I think about modern CPUs.
When you started explaining the "shadow world", it remind me to quantum superposition
You can update your microcode with a BIOS update for your motherboard / server or if you run Windows, Microsoft will eventually release a microcode update that gets loaded by windows every boot.
that microcode update on reboot thing happens on linux too.
I think the microcode is just updated via the package manager under Linux. And then applied automatically at boot time. So if you keep your server up-2-date it should happen seamlessly. Now at least I know why I had a microcode update a while back...
You succeeded in explaining to me how this works. Amazing exploit!
This is why software like Bochs is important - it allows to be sure that code will be executed exactly as expected. But it is slow of course.
Awesome video! Thanks
Times when cpu producers be mandated to certify or reveal internals coming fast...
They recreate old mainframes from those abundant transistors
Mandated by who?
@@MyChannelOnThisSite Governments, EU, Google, market
sad thing is, the microcode update caused many instructions to execute twice as slowly now. Software these days is extremely slow, programmers don't care to learn about cpu architecture anymore, partly because it's gotten so complicated, partly because it's undesirable by management and the economy.
But CPUs will not get much faster. We are not in the golden days of Moore's "law" frequence isn't getting faster, single threaded performance isn't getting much faster, now they're running out of space for more cores so they're cutting them down to "E" cores that are smaller and do less, so clearly that will stop soon too.
And sure AVX512 is here and MTX 1024bit matrix operations are up and coming for around 2027, but these things will not go on forever. The bulk of the performance we gain now is all we will ever have.
I guess the root cause of most of the CPU security bugs nowadays are due to side effects of unideal optimizations. So of course the CPU is slower when these are patched later on.
I guess it's similar with writing code. Checks can be added all over to prevent security bugs but these will make the code execution much slower. So to only add them there they are really needed for a specific implementation. Where it's maybe forgotten on some important places, or the code get used somewhere else later on where a check would be needed without a proper adaption. Like when the code is used later on for rare edge cases the original writer wasn't aware off. _Assuming the original creator was aware of writing secure code in the first place._
"programmers don't care to learn about cpu architecture anymore"
No, not really. The problem is a bit more complicated. The whole thing starts with sloppy design, and then programmers that are not given the time and utilities to even start making their code better. There is absolutely no need to learn about CPU architecture when you do not even have the time to think of how the system will look like after 2-3 months of development, let alone years.
It happens a lot that i fix some simple bugs that would have been found if the person writing that code had 2-3 days for actual testing - they just never got the time for that.
@@ABaumstumpf@ABaumstumpf yes. that all happens and It is bad.
simple bugs have always existed and are a part of the process. however
my point above was intended to note that even for performance critical parts of the code, barely anyone knows how to make those fast enough, which didn't use to be the case since when something is too slow on a 90s cpu, it takes way too long, where as now its only agonizingly sluggish, so it gets a pass.
there are many more things contributing to the state of things too, such as the ones youve said, and more.
Most unrated comment!! 😢
We need to go to risc v
Happy Onam ☺️
That code overlay at 7:18 to show it's the same code is pure gold
Liveoverflow has unlocked the red hacker glow
on debian there's a package called amd64-microcode ~ if it's a dedicated server instead of a VPS, there's a driver in linux for loading microcode without needing to do a bios update. worst case, for a VPS there's a chance the package won't work and it'll silently fail, but I can't really give any details about debugging an arbitrary distro which isn't on bare metal like it would be for a dedicated server.
If they provide the hardware as a service, but not access to said hardware (i.e. to secure yourself from vulnerabilities present in hardware), they are responsible for making sure that hardware is up to date with any security fixes and should disclose any vulnerabilities that may be applicable. Whether or not they were fixed.
What's good is that in their FAQ they do acknowledge Zenbleed and Downfall:
> We apply all currently released stable patches and microcode updates. Depending on the update the mitigation becomes either active immediately or is activated as part of the continous maintenance and update cycle of our platform.
This video opened up a whole world to me. Had no idea cpus and registers are now like mini compilers
Waiting for someone to do the same technique to Intel's management engine. 👌
Fascinating ❤
There’re some parts not really affect one to understand this bug, like register renaming. It’s a higher layer abstraction(relative to register file) isn’t really involved here. But on the other hand, I think it’s worth to explain some more details. For example, what is the expected state after side effect roll back when speculation breaks. Or where will a freed register points to after rollback, what variants we can have etc.
He explained it because the register renaming is important for the bug. That behavior confuses the compiler when it runs vzeroupper.
Wow I don't know what the aim of this 26 minute long advertisement is, but I liked it!
Intel's research team really is going all out to find vulnerabilities
Wooow, if he made a c or asm learning tutorial I would definitely follow to the letter ,this is great
WOW! Amazing! I have just discovered that exists a whole computer inside a CPU!!!! Mind blowing!!!!
Modern CPUs are magic. I'll stick to 6502.
It makes sense for modern CPUs, with multiple cores and many sets of code concurrently running on them, to have "virtual" registers rather than hard coding them, or else two sets of code that reference the same register would bottleneck when there are still resources available, but now the CPU has to make sure that no data from other processes is in this process' registers.
The thought I had part way through was that the XMM register merge optimization was making the CPU fast-track the availability of that area of the "register heap" when the YMM move causes register renaming to occur, allowing the CPU to allocate that area to another register. So if the CPU then jumps back from the failed speculation, the area of the YMM register it was using may now have some data in it.
Thanks for the detailed breakdown of how this exploit works, or bug is triggered. And fixed. :)
Gosh, we're going to be in trouble when ai is used to accelerate such bug discovery and exploit construction.
It seems like a good practice would be to completely zero out and reinitialize the internal heap every time a task switch happens.
Excellent vid thank you. That was very well explained. So programmers just need to make sure avx instructions aren't used in processing of security sensitive data to avoid this issue?
First, the choice of instructions is not yours, but the library writers. On program startup the fastest variants for each routine available on the CPU is selected.
Second, this bug is just in a specific generation of the processor. There should exist a microcode update removing the problem. It just wasn't installed here at the time of video creation.
If you avoid all complex stuff in your code, there is some probability you introduce other bugs by doing so. And then there is the question of how much paranoia is healthy or if you are paranoid enough.
For merge optimization, if what you do (for example SQRT2SS) does not affect the upper 96 bits of a destination register. It can bypass result merging (validation of the result). Result merging is when you do an operation that doesn't modify all bits, the processor has to merge the result back to validate and use it - like it combines your 32 bits (example) with your old data you didn't touch before (96 bits) to create the new value that you have asked it to (128 bits, full register). With merge optimization for things like SQRT2SS the processor intrinsically knows how many 0s there is in the register at all times, and does not need to validate how many 0s there is thus it doesn't need to merge the results, which speeds up processing greatly.
Amazing video.
Is this more support for the case that we need 100% open source CPUs or just that with great performance comes great vulnerabilities?
not necessarily, x86 CPUs tend to have lots of bugs with many shared historical instruction with quirks and weird registers. Part of this bug exists because AVS and SSE share registers and are partially incompatible. Having cleaner vector extensions would help
@@fluffy_tail4365but that's the main issue. x86 is complex and not documented well. something like RISC V would be a smaller attack surface since there aren't as many instructions, and they would be well documented.
I would guess switching to ARM would reduce the attack surface as well, but most ARM chips are custom silicon which might as well have specific instructions that stay undocumented. Like Apple having a hardware layer conversion from x86 to ARM for their M series.
It's a sign that CPU architecture is immensely complex. Strange edge cases occur that the architects did not account for, which causes bugs. In essence this is no different than a software bug, it's just software implemented in hardware (according to the video, in this case it's a microcode issue).
@@parabolicpanoramaRosetta 2 doesn't actually use apple silicon-specific instructions. Apple provides a build of it for Linux (intended for VMs running on macs), but people have gotten that to work on other arm64-based computers
This is something that would not have caught even if you have a 100% open source CPU.
Can you recommend any further reading on modern CPU internals architecture?
What a nice video!
basically, there is a saying "its better to take the normal route than shortcuts"
Tavis is a legend. His research into stepping out of VM's, into other adjacent VM's and even into the host hypervisor, was invaluable in bringing those championing that virtualisation increased security, back down the Earth.
He thankfully proved that virtualisation essentially created brand new attack surfaces.
This might be your best video ever
this is so simple that it makes me feel good about my personal level of skill
Correction at 13:21 - the lower 32-bit of the XMM register are set to the result of the integer-to-sp-float conversion, bits [127:32] are set to bits [127:32] of the first source operand (XMM0 in this case) and bits [MAXVL-1:128] are set to zero. This is similar to 64-bit registers in x86_64. If the target register is an XMM register, the upper bits of the corresponding YMM register are set to zero implicitly.
This is exactly what the XMM merge optimization is intended for. SSE & AVX allow the "packed" processing of floating point numbers, but you can also use the lower 32-bit / 64-bit of an XMM register for "scalar" single- or double-precision float processing.
you can update your microcode by updating the `amd-ucode` package on your system and rebooting
A detailed video "What is microcode" would be nice, because it's there especially to fix CPU issues. I guess this topic would be even interesting for people who are already very familiar with computer science. Not sure how easy it's to make such a video because I think it's especially interesting because it's a very complex topic. I guess microcode not just implements all the more complex instructions, it likely also handles the structures mentioned as "register file" and "register allocation table".
I was surprised when I learned that the microcode isn't static and need to be loaded each time to patch the CPU. That the BIOS applies the initial update on start and that the OS can update it again, like when the BIOS is outdated.
The issues themselves often exist in the microcode as all of these complex instructions is implemented there (and francly all the less advanced once too), and not actually in the CPU itself. At a rough level, the microcode does the actual work of your decoded instruction, we're talking code like set register 1 to the ALU side A, register 27 to ALU side B, set the ALU carry to zero, ALU flag to do an addition, store the result in register 7, set flags such as negative, zero, overflow, and carry, and jump to the next instruction and increase the IP, and you have something like an add instruction.
Assembly is kinda just like python or java opcode, but with a low level CPU interpreter - the microcode.
And here we just have a bit of "if zeroflag is set, don't do this code".
@@genstian As far as I know the microcode exists specifically to have something to fix CPU issues. It were added to patch the CPU in a case something isn't working as it should be to prevent that the CPU can't be used reliably anymore. So of course it's designed that if there is a bug that this is likely in the microcode, for the most or maybe even all instructions. An issue in the hard wired transistor logic would be a nightmare. _I can imagine that some of the simpler and first instructions which were present since the first x86 CPU and so are well known are maybe not in microcore or if in a rudimentary way._
@@maxmustermann7397 Every single x86 instruction map either a single uop (like those very simple instructions that have been present since forever), or upto 4 per insutrction in the decoding table (agnors data from 2015, like those "do this and that" instructions) or a full microcode function, and of cource, some instructions do have hardware uops and simply map those 1:1, modern cpus have like 20.000 different once, even full blown hardware instructions for sha or rsa, but any assemply instruction can be overwritten in microcode. A fairly large permanent microcode for instructions have been present since the 486.
@@maxmustermann7397microcode can be *updated* to fix some CPU issues, but it is not created for that. think of it as a kind of firmware: everything you do with a modern CPU is going through the microcode from day zero because the hardware itself doesnt actually run x86 machine code. without a microcode, your CPU is useless, so you dont even have a chance to worry about CPU bugs.
@@maxmustermann7397in Ben Eater's breadboard CPU series, his CPU uses microcode to specify how each instruction is actually implemented. It's basically a sequence of states for the various control lines in the CPU. For example, the add instruction could look like this in microcode:
1. register 1 output enable, ALU input A enable
2. register 2 output enable, ALU input B enable
3. ALU add, ALU output enable, register 1 input enable
And if there were some bug in this implementation, a microcode update could fix the bug. It could also add completely new features though, for example it might add a second add instruction that operates directly on memory rather than registers.
Microcode in modern CPUs likely works in a similar way, but of course way more complex with all the optimizations they make.
Wow … this is crazy .. I wonder how is this not big news .. 😮
Copying data and forgetting to modify the correct copy. Getting deep in a nested operation and forgetting to set modified data back to the correct values. Using memory after freeing it. This video helped me realize that CPU designers are just regular programmers making the same mistakes as the rest of us.
I can't thank you enough for this video. The explanation blew my mind, but it is the best explanation that I have found.
Does it mean, this issues cant happen if the more classic x86 string instructions are used? Seems to me only the newer x86 simd instruction sets (SSE to AVX512) are vulnerable?
25:55 yes drive down to their data center pull the rack with the other virtualized servers on it and updated the BIOS and chipset driver with the crash cart from the maintenance closet...that will go real well. The cloud is just someone else's machine.
If registers are essentially all stored together in the same memory collection, it seems that the idea of a register is more fluid. Thus, could we see a day where there's a CPU that uses a different paradigm, other than registers?
if you want to throw away all the compilers and software stacks in the world yes (since there would be no level of rewrite to make them compatible to a new architecture that does not use registers - unlike for example translating from x86 to ARM or RISC V). You could implement C in the CPU itself directly (the heap) without the CPU needing registers. You would loose the ability to run low level assembly and compilers for all other languages, but you coudl do it. Oh yes you would also need to rewrite all microcode / BIOS as well. The change would be so big as going from traditional to quantum computing. Everything reset to point 0. But sadly no benefit, just downsides (CPUs would lose the ability to do low level optimisations like in this video, and they would not be language agnostic anymore, or you would need to run code that has been compiled into the intermediary language - such ones already exist but here we are talking about a worldwide usage, not a specialized use case).
@@marsovactldr not going to happen? xD
A CPU without registers is just a rock. Even stack machines need registers to store the stack pointer and program counter.
So why is there any data in that register anyway? Shouldn't that be cleared during the context switch? Or is the clearing also optimized away?
Let’s goooo
We're using AWS and most of our applications are running in dedicated EC2 instances. Could there still be a concern? Thanks for the video!
ec2 instances are virtualised, so yes, very few of them are Zen2 based though, so if you want to be sure then check what cpus are powering your instances.
got it @@propellergarage
I always thought that assembly was as low level as one could get, then the shadow realm appeared.
How do they access the CPU? Through the existing backdoor?
do we already know how to disable those mitigations once they are in?
how far does register renaming go back? i am looking at the z80 with suspicion!
There is a "advertisement" text in the top right corner lol (through the whole video)
zen2_leak_pepo_unrolled is my favorite Twitch emote
"Modern CPU": Register renaming is actually more than 20 years old :)
Yay a new video
This is why if zero trust should be implemented if there is any risk involved.
Regarding your Hetzner question, I think it raises another thought. (Okay slightly different given that microcode updates are not persistent) As a person renting a dedicated server, is the renter or the provider expected to update firmware on say a hard drive, network card or a HBA? Is a renter even allowed to do it? Who is liable if a failed firmware update bricks the hardware?
With that in mind, even though a microcode update shouldn't cause any persistent damage - What if there is an issue and who's then liable?
As I understand microcode updates on linux at least they are really quite ugly afaik. I think whats actually happening is that you basically reload the CPU microcode with patches from software on boot every time. They are not even applied permanently. So I guess in the early boot phase even patched cpus are technically still vulnerable.
And this is the reason why Hetzner is not doing anything about this. From a practical standpoint fixing microcode is entirely a software task and Hetzner doesn't have anything to do with this.
It would still be nice if they would inform you that you might be running vulnerable microcode, I agree, but that would be almost more like a personalized newsletter for their customers.
For microcode-loading and patching there are many defined entry-points. In general you have the fixed hardware-code, then a patch-table that needs dedicated flashing-boot, then early boot where the bios can apply some stuff from ROM, then late bios were memory is initialised already, then later UEFI and down to live-updates by the OS.
And basically everything aside from the bios-flashing is "vulnerable" during boot.
"root@minecraft": glad to see you're still a minecraft channel
I think you can run the microcode updates on every boot if the BIOS fails to do so. They will get reverted every power cycle.
fab explaining fab vulnerability.😅
Id like to know why it doesn't work on zen 3, I assume because the silicon architecture changed and the bug is no longer present?
I hope to understand this video in upcoming days.😓
I think other superscalar cpus have it to, we just not found a way to trigger it...yet...
I wonder if microcode update can be target for "rootkit"...
We deal with another layer of hidden software, crazy
As any other complex software always has bugs.
Microcode can be rootkit-ed in theory. But it is an obfuscated binary blob which is incredibly hard to reverse-engineer.
Also it definitely has signature of some kind, so CPU will not so simply load a modified one.
@@mk72v2oq This things I know, I wondered more about how big payload can be fitted there. I was thinking about something opening privileged access for other component. One guy found in some processor other processor wich had access to x86 registers...
@@AK-vx4dy iirc, AGESA part for every Zen generation takes ~5 MB.
Microcode patches shipped with operating systems are much smaller though. As for Linux 6.4.12, microcode_amd_fam17h.bin (Zen/Zen+/Zen 2) is ~12 KB. microcode_amd_fam19h.bin (Zen 3/Zen 3+/Zen 4) is ~38 KB.
Which I think implies that the patch size may be arbitrary.
@@mk72v2oq whole patch yes but I wonder how long can be code for particular instruction
already waited for this video :)))