Zenbleed (CVE-2023-20593)

Рет қаралды 155,530

Күн бұрын

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

Пікірлер: 369

@LiveOverflow 9 ай бұрын

SLIM VIDEO UPDATE! For over a year I accidentally recorded my video stretched in width. It's fixed now

@chocolateimage 9 ай бұрын

i actually didn't notice it

@MemoryOfLife 9 ай бұрын

FatOverflow is no more

@user-ot8tb8jk3t 9 ай бұрын

😂 Yeahhhh! Great!))))

@RohitKumarAnkam 9 ай бұрын

I want a video about what the hell is micro code and how it can fix these issues.

@blarghblargh 9 ай бұрын

@@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.

@dooterino 9 ай бұрын

Note to self: the parts of microarchitecture that made my brain hurt when learning about them are where all the worst vulnerabilities live

@Reiikz 9 ай бұрын

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.

@naterthan5569 9 ай бұрын

its because not even the CPU architects and engineers can fully understand it themselves.

@vhlk 9 ай бұрын

@@ReiikzI think that people that buy cpus based on benchmarks wouldn't do it...

@IAmPattycakes 9 ай бұрын

@@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.

@andrekz9138 9 ай бұрын

@@naterthan5569We refer to this kind of vulnerability as Eldritch horror

@VaradMahashabde 9 ай бұрын

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.

@minghaoliang4311 9 ай бұрын

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...

@KieranDevvs 9 ай бұрын

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.

@alexcani4957 9 ай бұрын

@@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

@KieranDevvs 9 ай бұрын

@@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.

@alexcani4957 9 ай бұрын

@@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...

@thecircusb0y1 9 ай бұрын

If everybody would just use the same password, we wouldn’t have to worry about this.

@MegaManNeo 9 ай бұрын

This would still end in xkcd standards.

@mNaximilian 9 ай бұрын

No security issues if theres no security 🤷🏻‍♂️

@miigon9117 9 ай бұрын

yeah totally. Have no idea why ppl collectively spend enormous amount of effort to try to solve something this easily solvable

@r7calvin 9 ай бұрын

I only allow 8-char passwords in my software, so they're all immune to zenbleed.

@MelroyvandenBerg 9 ай бұрын

Problem -> solution

@KingOfSandvich 9 ай бұрын

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.

@magfal 8 ай бұрын

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.

@itsTyrion 8 ай бұрын

@@magfal Even ignoring things like this, many providers are simply not GDPR-compliant

@MeriaDuck 9 ай бұрын

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 😂

@kphaxx 9 ай бұрын

@@JohannaMueller57Point it out, then.

@peterjohansson1828 9 ай бұрын

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 :)

@jamesphillips2285 9 ай бұрын

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.

@ewetoo 9 ай бұрын

I'm not sure they've actually been where we think they've been in the first place tbh.

@michmart9261 9 ай бұрын

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

@michmart9261 9 ай бұрын

And If I know correctly modern CPUs are limited mostly by propagation delays in the transistors basically, but also lightspeed definitely

@SIGSEGV200 9 ай бұрын

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

@kellysmith7357 9 ай бұрын

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.

@kirkanos771 9 ай бұрын

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.

@ABaumstumpf 9 ай бұрын

So AMD should inform everybody.

@marsovac 9 ай бұрын

@@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

@kiseitai2 9 ай бұрын

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.

@twentylush 9 ай бұрын

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!

@pesaventofilippo 9 ай бұрын

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 :)

@phasm42 9 ай бұрын

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.

@Failure_Is_An_Option 8 ай бұрын

AMD is so backwards. I'm surprised they are still a thing.

@VirtuousMarine 8 ай бұрын

Do you happen to have intel stocks or smth?@@Failure_Is_An_Option

@StereoBucket 9 ай бұрын

Oh amazing. That registers explanation makes the register renaming just click instantly. Didn't know they were implemented that way.

@jaspersmit6024 9 ай бұрын

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!

@mattiviljanen8109 9 ай бұрын

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.)

@herkulessi 9 ай бұрын

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

@dealloc 9 ай бұрын

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.

@herkulessi 9 ай бұрын

@@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?

@_sneer_ 9 ай бұрын

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.

@jort93z 9 ай бұрын

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_

@herkulessi 9 ай бұрын

@@_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

@FueledbyJohn 9 ай бұрын

Fascinating discovery good work bringing this CVE to peoples attention in such a thoroughly explained manner.

@SiyuJiang 9 ай бұрын

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

@yup8388 9 ай бұрын

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!

@WyrdieBeardie 9 ай бұрын

This was effing GREAT! Man, I feel like I could talk with Tavis for hours! Great job, both of you!

@warker_de 9 ай бұрын

Wow, I've learned many new things about the low level internals of a cpu 🤯

@tg7943 9 ай бұрын

Awesome and so much work in this video! Thank you

@thatstupiddoll 9 ай бұрын

My man really called a CPU manual "Really high level" 💀💀💀

@Takyodor2 9 ай бұрын

Well, compared to the electric fields that bend and twist and flip and flop inside the physical transistors, it kind of is high level 😅

@bene5431 9 ай бұрын

It's all relative. C was a high level language at some point

@yarmgl1613 9 ай бұрын

@@bene5431i'd say C is mid level

@Puzomor 9 ай бұрын

@@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.

@AndrewTSq 9 ай бұрын

Op code - machine code - assembly - c

@chillibits 8 ай бұрын

Thanks for the understandable explanation. Learned a lot today!

@calopii 9 ай бұрын

Thank you for the explanations in this video. The complexity and the mechanisms under the hood are blowing my mind.

@DarkLord-mp8fu 9 ай бұрын

Absolutely loved the video. The way you explained it... I am thankful.

@cygmoid 9 ай бұрын

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

@makers_lab 9 ай бұрын

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.

@logiciananimal 9 ай бұрын

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!

@kevinwydler7305 9 ай бұрын

This is crazy! Thank you sooo much for an update on this!

@kylegivler8372 9 ай бұрын

You are an amazing teacher, thanks for sharing this!

@djenning90 8 ай бұрын

This was super interesting, thank you!

@interstellarsurfer 9 ай бұрын

Waiting for someone to do the same technique to Intel's management engine. 👌

@PedroLucasbp 9 ай бұрын

Thank you for the amazing work on this vídeo.

@AK-vx4dy 9 ай бұрын

Times when cpu producers be mandated to certify or reveal internals coming fast... They recreate old mainframes from those abundant transistors

@MyChannelOnThisSite 9 ай бұрын

Mandated by who?

@AK-vx4dy 9 ай бұрын

@@MyChannelOnThisSite Governments, EU, Google, market

@carlosgarcialalicata 9 ай бұрын

When you started explaining the "shadow world", it remind me to quantum superposition

@DNinjaDave 9 ай бұрын

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.

@user-dt8mf8nt2v 9 ай бұрын

that microcode update on reboot thing happens on linux too.

@bur2000 9 ай бұрын

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...

@EliLPD 9 ай бұрын

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

@sdjhgfkshfswdfhskljh3360 9 ай бұрын

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.

@konradw360 9 ай бұрын

Liveoverflow has unlocked the red hacker glow

@creatorofimages7925 9 ай бұрын

Really good second part, thank you for the really good explanations and providing additional background knowledge. Learned so much from it!!

@df0rce 9 ай бұрын

Awesome video! Thanks

@RohanKumar-wf9sc 8 ай бұрын

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.

@mazzukmachu 9 ай бұрын

Happy Onam ☺️

@kuzetsa 9 ай бұрын

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.

@philrod1 9 ай бұрын

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

@dgxo 9 ай бұрын

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!

@shiftbyteworld73 7 ай бұрын

Fascinating ❤

@plexsheep1296 9 ай бұрын

The last part was interesting, i too think it would be good to inform customers of hardware security bugs in their rented products.

@kphaxx 9 ай бұрын

Holy crap, great explanation! Changed the way I think about modern CPUs.

@csmastery1337 9 ай бұрын

Wow I don't know what the aim of this 26 minute long advertisement is, but I liked it!

@ireallyreallyreallylikethisimg 9 ай бұрын

Intel's research team really is going all out to find vulnerabilities

@dealloc 9 ай бұрын

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.

@russellchido 9 ай бұрын

You succeeded in explaining to me how this works. Amazing exploit!

@S4im0n 9 ай бұрын

That code overlay at 7:18 to show it's the same code is pure gold

@TMinusRecords 8 ай бұрын

This video opened up a whole world to me. Had no idea cpus and registers are now like mini compilers

@flyviawall4053 9 ай бұрын

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.

@Getsbuffer 9 ай бұрын

He explained it because the register renaming is important for the bug. That behavior confuses the compiler when it runs vzeroupper.

@fusca14tube 9 ай бұрын

WOW! Amazing! I have just discovered that exists a whole computer inside a CPU!!!! Mind blowing!!!!

@Anton1699 9 ай бұрын

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.

@aspirohk3558 9 ай бұрын

Wooow, if he made a c or asm learning tutorial I would definitely follow to the letter ,this is great

@erwynnipegerwynnipeg8455 7 ай бұрын

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.

@whtiequillBj 9 ай бұрын

Can you recommend any further reading on modern CPU internals architecture?

@0xddcce1 9 ай бұрын

basically, there is a saying "its better to take the normal route than shortcuts"

@tomgimon5267 9 ай бұрын

It seems like a good practice would be to completely zero out and reinitialize the internal heap every time a task switch happens.

@IPear 9 ай бұрын

What a nice video!

@andysPARK 9 ай бұрын

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.

@eslof 8 ай бұрын

this is so simple that it makes me feel good about my personal level of skill

@DemonixTB 9 ай бұрын

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.

@maxmustermann7397 9 ай бұрын

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._

@ABaumstumpf 9 ай бұрын

"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.

@DemonixTB 9 ай бұрын

@@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.

@MelroyvandenBerg 9 ай бұрын

Most unrated comment!! 😢

@MelroyvandenBerg 9 ай бұрын

We need to go to risc v

@AdamFJH 9 ай бұрын

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?

@Hauketal 9 ай бұрын

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.

@beardymcbeardface69 8 ай бұрын

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.

@bitcores 9 ай бұрын

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.

@D0w0ge 9 ай бұрын

This might be your best video ever

@SimGunther 9 ай бұрын

Is this more support for the case that we need 100% open source CPUs or just that with great performance comes great vulnerabilities?

@fluffy_tail4365 9 ай бұрын

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

@parabolicpanorama 9 ай бұрын

@@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.

@Iaotle 9 ай бұрын

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).

@lunlunnnnn 9 ай бұрын

@@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

@slicer95 9 ай бұрын

This is something that would not have caught even if you have a 100% open source CPU.

@davidjulitz7446 8 ай бұрын

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?

@ashajjar 8 ай бұрын

Wow … this is crazy .. I wonder how is this not big news .. 😮

@Stthow 9 ай бұрын

Amazing video.

@DanielTheRat 9 ай бұрын

Yay a new video

@Henrik0x7F 8 ай бұрын

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?

@sreyanchakravarty7694 9 ай бұрын

I can't thank you enough for this video. The explanation blew my mind, but it is the best explanation that I have found.

@Takyodor2 9 ай бұрын

zen2_leak_pepo_unrolled is my favorite Twitch emote

@kenziewebm 9 ай бұрын

you can update your microcode by updating the `amd-ucode` package on your system and rebooting

@alexlowe2054 9 ай бұрын

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.

@ewetoo 9 ай бұрын

how far does register renaming go back? i am looking at the z80 with suspicion!

@AnotherFreakingDude 9 ай бұрын

I always thought that assembly was as low level as one could get, then the shadow realm appeared.

@maxmustermann7397 9 ай бұрын

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.

@genstian 9 ай бұрын

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".

@maxmustermann7397 9 ай бұрын

@@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._

@genstian 9 ай бұрын

@@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.

@jotch_7627 9 ай бұрын

@@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.

@lunlunnnnn 9 ай бұрын

@@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.

@outkast9882 9 ай бұрын

Let’s goooo

@kai990 9 ай бұрын

do we already know how to disable those mitigations once they are in?

@gFamWeb 9 ай бұрын

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?

@marsovac 9 ай бұрын

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).

@patrikjankovics2113 9 ай бұрын

@@marsovactldr not going to happen? xD

@0xD1CE 9 ай бұрын

A CPU without registers is just a rock. Even stack machines need registers to store the stack pointer and program counter.

@gareth2021 9 ай бұрын

already waited for this video :)))

@yngndrw. 9 ай бұрын

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?

@mlhscanada1069 2 ай бұрын

How do they access the CPU? Through the existing backdoor?

@KieranDevvs 9 ай бұрын

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?

@hyakimarru 9 ай бұрын

I hope to understand this video in upcoming days.😓

@sylvie_v2939 9 ай бұрын

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.

@benjaminb1337 9 ай бұрын

This is why if zero trust should be implemented if there is any risk involved.

@MegaManNeo 9 ай бұрын

The sad part about your videos is I understand it all at a basic level due how well you explain things but I usually forget the contexts too eventually 😅😢 Would love to make a joke about x86 but ARM is proven to have bleed bugs as well.

@hackjealousy 9 ай бұрын

All I can say is thank god Ormandy uses his powers for good.

@denisapain 9 ай бұрын

There is a "advertisement" text in the top right corner lol (through the whole video)

@neilfpv 9 ай бұрын

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!

@propellergarage 9 ай бұрын

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.

@neilfpv 9 ай бұрын

got it @@propellergarage