Your comment about the page size isn't quite correct: A modern x86 CPU fetches and writes 64 byte chunks of memory (the cache line size). The 4096 byte page size refers to the minimum chunk of memory that can be virtually addressed, i.e. mapped from virtual to physical memory. So basically, as you're watching replace "page" with "cache line" in most of this video. Page size only becomes relevant later when it comes to memory access controls.

I love how a negative result was so pivotal.

While I might be a bit biased, I really have to say that this video turned out extremely nice! Great job explaining this in a very easy to follow way!

I really respect Intel for not only taking silicon vulnerabilities so seriously, not only starting a bug bounty program, but sponsoring people to promote it by analyzing existing bugs. This is dedication, and I really hope we see more companies treat security in this way. I've seen more and more companies start bug bounty programs recently, and it's definitely a move in the right direction.

I discovered this channel 5 years ago, thanks to the reverse engineering playlist. I took CS in Uni 3 years ago, inspired by this channel. Some months ago i started writing my thesis on the formalization of relaxed memory models and their speculative behaviour, and today this video is uploaded. What a journey, Live :)

I never had someone explain branch prediction so well to me. Thank lord.

You actually show out-of-order-execution (; ) vulnerabilities, like meltdown. Speculative execution (foo: xor rax, rax; jnz bar; jmp foo; bar: ) vulnerabilities like spectre are slightly different concepts. The first class is afaik intel-only, the second class is an issue for other modern CPUs of other ISAs too.

42 TOOTH lmao. These things just make my day. Thank you!

"The forty-twoth page" really gets me. Forty-second.

In my view, every field should have journals of negative results. I had no idea that the history of the speculative execution vulnerabilities was so rich.

waaaaaaaau, I always wanna understand that issue and you just explained it briliantly! I salute you, man!

Always awesome content @liveoverflow!

If anyone else wants more videos like this to watch, Christopher Domas' Defcon talks on x86 architecture are extremely fascinating.

I did not understand much of the video but still find it intresting

4:12 I don't know if anybody has said this yet, there are only 243 comments right now, but: What you pronounced as "fourty-two'th" should be "fourty-second" . In general: good job. Your work is appreciated.

This is one of the best video's you've posted. Well done!

What a great timing of that upload hence I just read about them but didnt know how you would discover something like this

Amazing video! I hope we get more content on hardware-type vulnerabilities and “hacking”!

shoutout to intel for sponsoring this, lol! amazing video as always

I made my Bachelor's thesis about RIDL, it was awesome! 😍 I basically used it to leak the hash of the root password of my Professor 's PC remotely through ssh. Cool video, thank you !

Big props to you and intel for doing this!

Holy smokes, i was waiting on this one ! Big Thanks.

Amazing video! You interested me in security years ago and at finally ended up on DEFCON CTF. Might bait me into CPU bugs now...

this reminded me of Chris Domas on his research on the x86 instruction set. loved his defcon talks

Amazing video to start digging CPU vulnerabilities!

This was awesome! Been grinding through your binary exploitation playlist. Keep it up🔥

Anyone knows what's that IDE theme (2:50)? Looks nice

Very interesting topic. I must admit I didn't understand 100% of everything but it definitely gave a nice insight into the topic.

4:10 42th? :DDDD I think you meant 42nd?

In reality bug bounties are the most cost effective way to handle security related topics, as you find the people who are very vested in the topic spending countless hours that you don't have to pay for. Then just pay for the result. I am surprised it took them so long to find someone that figured that out O_o

Awesome video! A difficult topic but very well explained and broken down to smaller pieces!

The research was 🤯, think time to start exploring micro architecture

Super interesting, thanks for sharing and the great editing/research. Love your channel, huge fan!

This video is just pure Gold. Thx

Love watching your videos man. Amazing detail.

This shows the importance of publishing negative results! In some areas of research, negative results never see the light of day because they have a much smaller chance of getting accepted into journals. I think this needs to change!

Thread is a kernel side term for process, to be specific thread whose id is the same as the thread group id is a process, while thread whose id belongs to a different thread group id is a thread in the userspace sense.

Really was looking for it. So nice, that Intel actually contacted you, since they reacted quite "salty" to the doings of one of my lecturers (whom I admire, you might know him: Michael Schwarz). Really really cool video! :) He tought us about fencing etc. and the simplicity of analyzing the "performance" via plotting a histogram. No big ML needed here. :D I don't know, but the segfault handler seems either like a really useful feature or as if you shot yourself in the foot. xD

Have you considered doing more general overviews/tutorials related to programming oriented towards a more professional audience? While I love computer science, your channel is one of the very few that has managed to keep me interested. Of the programming channels I have tried watching, most are either lengthy tutorials for complete beginners or short overviews of frameworks/libraries. I wish there was a place I could find programming deep dives on more advanced/novel concepts while assuming some industry experience from the viewer.

There is a talk/video from 33C3 back in 2016 titled "What could possibly go wrong with (insert x86 instruction here)?" which goes through the CPU cache side-channel attacks.

4:12 I'm sorry but the forty twoth (?) is triggering me so much . . . nonono, forty second (!) :(

Thank you for this high quality content!

Interestingly enough in 2017 i watched the Computer Scienece CrashCourse Videos and when they mentioned caches and pipelining i thought of if you could measure the cache access time of forbidden variables. But i brushed it off, thinking that when the CPU miss predicts it would also flush the cache.

Spectre and Meltdown really changed the way we look at malware

2:04 compiler explorer is everywhere

VUSEC gives great courses by the way! They teach it at the Vrije Universiteit Amsterdam In the courses I took we got to reproduce one of their papers actually. I reproduced GLitch :)

I believe that in the accidental discovery, you need to guarantee that you are running both process in the same core... P.S.: It's curious how the video approaches RIDL without the necessity of talk about Meltdown.. time really goes fast... Thanks for the video.

This again is a great showcase of the outstanding cyber security research going on in germany! No matter whether its the CISPA in Saarbrücken or the HGI in Bochum. Developing CPU attacks? Standardizing the new post-quantum cryptography schemes? Germany takes a major role there! Of course our neighbours from the netherlands and other universities are also very good;)

I was at eurobsdcon in 2017, and someone modified the kernel to exit instead of throwing an segfault. I didn't understand at the moment, but now i think this could mitigate this bug. Maybe we rely to much on bugy code that segfaults are not handled critical enough..

This is fascinating 👏 This is a very great video and in depth explanation. I love your channel 😃 keep it up sir

Intel: Bounties are too expensive, we need to hire a hacker on the cheap... 😂🤣

Very nice video! I wish I understood 100% of it!

great video man the fact that intel sponsored the video is crazy haha

Yes cpu pipelining has been here for ages(Motorola 68040 from 1990 was pipelined, 386 and 486 definietly was pipelined). Out of Order Execution goes back to pentium pro(pentium 2). I somehow expected superscalar to be mentioned as that came before Out of Order Execution, but I see how it wasn't super relevant to the video.

High quality content fr

nice video! very informative and relatable

Did I understand correctly? The parent code will try to make read on secret value, which is same address on both processes, and speculative execution will run it. The speculative execution will run with actual secret value, and then it will learn that it made error because the secret's value in parent process is nullptr. Then it will trigger exception. And then we can't simply check which page table is loaded very fast.

"42th page" was kinda painful

bit of a random question, but what kind of shop would I find club mate in? is it just any old supermarket, or do i have to go to a special mate shop? (assuming im already in germany)

I would like a video on what microcode is and how it can fix these problems.

with those steps of: 1. prepare weird payload (something known that shouldn't work) 2. use it 3. measure seems awfully like how people use cheatengine.... interesting. Hope you have a great day & Safe Travels!

A thread is an actual code being executed. A process is the container that has addressing and other process data including the thread. A thread is executed not a process.

Now do the TPU and the baked in "Management" ROMS. ;-)

What CPU manufacturers plan to do with these vulnerabilities?

Amazing video

We are crowd sourcing practically for free the work that intel should be doing their self.

Could you maybe look into the USB-JTAG vulnerability on older Intel CPUs?

15:33 this is what students are supposed to do when writing their thesis :)

18:40 "I hope this code looks familiar" Me who only used nested loops for printing stars

How would the speculative execution behave if one instruction *will* change the opcode of one of the next instructions? I know it's not the usual case for the executable code to change the next executable instructions, but it's still possible to do this, right?

4:13 "Forty-second", not "Forty-tooth"

I'm shocked this is the thumbnail that won the poll

love for your super explanation.

Probably meant 42nd as in forty second instead of 42th? :)

Isn't it fun seeing the wheels turn inside the minds of incredibly intelligent people?

when the sponsor wants them to talk bad about him, that's wild!

Isn't the release of failed results (15:34) contradicting guidelines for ethical disclosure of vulnerabilities? I mean, the bad guys might already have managed to use these informations to figure out the remaining piece of the puzzle before researchers did and whence also before intel would have the opportunity to fix it? So, refering to some other comments I read: I agree that sharing negative results is a good idea, but just from the scientific perspective! Taking into account the above mentioned negative side-effects, this may be a bad idea for IT-Security. What do you think?

great video! very educational

Awesome!!!

I love this category of vulnerabilities. They are so crazy complex, yet knowing how and why they work is very satisfying. Please do more of these and a bit less Minecraft 😍

Thanks for explaining, you have such great energy

Wish i could understand what you said. I was intrested none the less :)

Shouldn't 42th be 42nd?

11:42 how could I get a kernel address? doesn't my process use virtual memory? I should not be able to address kernel pages at all... ?

Great Work ❤️

This is why negative results are also research results.

Where can I find the code you show in the video at 18:30?

I feel like a 10x hardware hacker now!!!🤪

21:55 is this him rocking Grado cans with shipibo pads???

I still find it confusing how in a rational universe, any memory value could be read (and used in any way) _before_ access is checked. Since all the memory is virtual in the context, it has to at a minimum, look to see where the memory is actually mapped to (if at all). And I would think the mapping and access check would be done hand-in-hand. I mean, I'm all for optimization, but you have to wonder WTF were the engineers thinking?! I wonder if to work around this (aside from fixing their broken access model), if they have or are adding a sort of "speculative" caching to newer CPUs. So as caches are read, they are somehow marked as tentative and only confirmed after the operation which requested the memory has completed successfully and with certainty. If an instruction generates an exception or is discarded, then any resulting cache is never confirmed, and treated as non-existent (unless in the same thread/task which triggered it). This could still give the benefit of caching in 99+% of speculative cases, but avoid most (all?) of these kind of vulnerabilities.

What was the "small mistake" the initial blog/paper missed in exploiting leaking kernel memory?

What a great video !

I've been preparing for the shadow world my whole life with persona 4

42nd, not 42th . Great video though.

very good explaination, but looking at the example code: does fixing something like this make sense vs. losing performance?? Personally, I would not bother and dismiss this edge case finding. Nobody should even be able to execute arbitrary code anyway, plus with knowledge about the issue, software if required can guard itself from these flaws.

4:12 forty 🦷

Thanks for this very good and interesting video! I personally like these low level / computer architecture videos a lot more.

Can you tell from where your intro music / medley is from or who prdocued it? Cheers!

the cpu instruction multiverse

so can this be automated?