 much shorter I think. I didn't know there were that many people coming. I think last time I was at the papers we left it was like three people or something. You're here because of you. Yeah exactly, all because of me. My name draws to people. Yeah so I didn't prepare any slides anyway. And again this is going to be very brief and I think there are probably a couple of people here who know more about CPU architecture than I do. Probably most people here know more. And I guess some people have read the paper. Who's read this or the spectra paper or the Google block thing. Okay so some have looked at it. So yeah let's start this one into roundtable discussions. I don't look too dumb when we talk about this. So just chime in when you have something to say. Anyway, Meltdown right? It's a CPU bug. Well no that's the thing like if you ask Intel it's not a CPU bug. They work as designed. It's like maybe it's an undesired feature. An undesired side effect. And I think it's true because it's so it's well it's a side channel attack and there are lots of side channel attacks that are kind of weird and strange to think about. And this one is I think it's quite a mindfuck. It's quite interesting that this is possible. Right so how does it work in general? So generally sidechain attacks are basically exploiting side effects of say in this case of the inner workings of a CPU. So you have the desired normal effects. You feed the CPU instructions, it executes the instructions, you get back results. But there are always or there can be side effects and by sort of exploiting these side effects you can extract information that's general choice of it. Now Meltdown specifically is about out of order execution which is how CPUs, modern CPUs currently work or like break down instructions into smaller micro instructions. So you have like the CPU instructions that you all know if you know if you ever looked at assembly code or ever debug anything on low level. So you have CPU instructions they get broken down into into smaller instructions and they can get executed out of order because some parts of the CPU might not always be might be utilized on different levels. So you kind of want to paralyze as many things as possible. So you don't necessarily want to keep the order of of the instructions. So you kind of look ahead a little bit and you see what you can what you can execute in advance, particularly memory fetches which are really really take a long time in CPU terms. I think hundreds of instructions. Does anyone know? Yeah, so hundreds to thousands I think, right? And then you have about three layers of cache nowadays which I think reduce it to tens until I think single digits. Yeah, but that level one can be almost single digit instructions I think, right? Yeah, something like that. All those are magnitude different. So some of these so basically the memory fetches in particular they execute speculatively as well like they execute they may execute. Well, no, it's not speculative execution. That's what Spectre is about. So it's slightly different. But if you have say instructions that check for access and following that you have instructions that in the case that access actually under this speculative execution. Anyway, these instructions follow the instructions checking for access or any sort of like CPU features which could CPU security features we could trigger a CPU level exception. The memory fetch instruction could still be executed before it's actually checked whether it should be executed because of this out of order execution. Now in Meltdown specifically the way the exploit works is by this is called the snippet. So essentially let's go I'm not sure if they have a schema explaining the whole idea. So in the exploit you have two components. One is the component that extracts the information in this case the entire kernel memory that you can read out. The entire actually the entire system memory that you can read out because it's mapped into basically the entire address space is in operating systems nowadays is mapped. It's just you have like access controls via a specific bit. So only the kernel technically can access all the memory but again like that is sort of checked at a slightly inopportune time. Now you have the information extraction part essentially which tries to execute the instruction that fetches memory that tries to execute that tries to access a specific memory address and afterwards based on that and again this is these are all just instructions that don't officially get executed but get executed sort of out of order. You fetch a specific memory address and then you use this memory address to fetch a memory like you use that you use the content of that memory as the address of another fetch you do on your own memory and again this all gets executed and then the CPU realizes that it wasn't supposed to actually give you that memory so it kills your process but at that time you already the second fetch is already executed and the content from your memory the byte that you wanted to fetch with this address sorry the block that you wanted to fetch with this address in this byte that you originally got from the memory you were not supposed to access that part will be in memory so in the cache so now in the second process it can run technically also in a different like virtual machine everything completely independent of the first process I think you access the the same memory and check the timing exactly so that address then the address of that memory is the actual byte you wanted to like you were not supposed to read so with that it's possible to read out the entire system memory of a of a system and I think the speed I think they mentioned the speed of how quickly they can do it and it's some somewhere around 500 kilobytes a second or something which is yeah 502 502 kilobytes a second which is kind of a lot if you want to read out a couple of gigs I mean it takes a couple minutes two hours yeah it's a lot of loops so it's it's in in CPU terms yeah 502 kilobytes a second this is very slow because there is yeah there's a lot of a lot of stuff involved this is also so the original thing I think the first approach was you have this process trying to fetch this this memory from from the kernel address space somewhere and that usually kills the process you get a segmentation fault your process dies so they have some some strategies against that one is um what did it die no going to it is a real-time well yeah I think my machine got meltdown what? on the other side or is it on the other side? yeah sure this is working but it doesn't really matter I was just scrolling up and down into the paper and it's fine that was okay that was actually something cool I read the whole the the exception suppression this is feature I think the Intel TSX is explained a bit further up this is yeah here this is cool so Intel has this sort of like transaction feature for for memory operations so you can basically say you can you can group multiple instructions and and then if one of them fails which it will if you like one will fail if you try to access memory are not supposed to access and your process still stays alive it's just all the other instructions that group are not officially executed so you can you can kind of you can avoid your process dying so you don't have to fork all the time and that speeds it up a little and then there's this they mention the the kernel address address space layout randomization stuff that's been going on in the kernel that is now default which I think mostly helps although it's still it's it's not it doesn't necessarily make it completely impossible just sort of not very feasible I guess you need to I mean before this you knew where it was so you could get it very quickly whereas now you kind of have to worry the whole memory and fish in the dark a little yeah isn't isn't the memory mapping table it's it's not technically in a memory isn't somewhere in the air maybe that's exactly why it takes a bit longer so yeah anything anybody wants to contribute and if like those who read the paper what was the most interesting thing anything anything I omitted but it was super cool to see the the chaining of attacks it almost felt like because it's like the fact that it the meltdown itself is basically that it doesn't undo it that it's it's supposed it says that this instruction it goes ahead it goes ahead and dust up out of order but then something breaks it doesn't fix and clean up all the crap it did right doesn't go to clear the caches it clears the registers but not the cash yeah I think the problem is that if you if you I mean this would also happen in the case of branch misprediction which is which is a case of spectral right but if you want to flush the cash every time that happens that will probably make it much slower as well that's that's a software fixture which is you flushed the whole cat well if it was probably designed in hardware it would just this because it knew where what was the stuff it just did yeah yeah yeah so like so that would be from a hundred percent much harder from itself but that should be the right way to solve it rather than the software fixes we are putting in right now which is well every time you do a exception just flush the whole cash but then if you flush a specific cash entry won't that also open a side channel where you can say if you where you can figure out whether a particular cash entry disappeared yeah so basically you can have like a temporary cash that you only commit into your real cash when an operation ah right so if it's already cached then you wouldn't you wouldn't flush it in the actual yeah so much that through on on the on the end of an atomic whatever instruction that you have at the end of this push everything through the real right for reading so again these are again things that they will probably end up doing in the long run but yeah it's super cool and then big big they found that with the whole cash sniffing in a side channel attack by just doing the timing even so this stuff is all but the way they figure out what's not in cash and what's in cash super cool I mean these side channel attacks are I felt the specter was a bit more of a mindfuck in the sense that they do like super crazy stuff in there like identifying bits in the code you're like specter is a bit a bit different because I think you have to sort of still find sort of vulnerabilities in the in the target and these weird I forgot what they are called we basically can jump around that is that is even more complex this one is almost straightforward compared to it no it's more like I think you need to find some specific constellations of I forgot what it was do you have the melt that the specter paper yeah but yeah we covers back to the next month okay so if we were to play that was evident so how would we absorb intel of this what I mean does the ISA say anything about the cash it probably doesn't because the cash is fully transparent but then the ISA doesn't say anything about about brand out of order exactly so if you just stick to the ISA you can't observe the impact and the timing is not specified in the ISA so you can't make any inferences based on memory read speed yes so if you're only programming against the spec yeah well yeah that is that is that this kind of the the abstraction of the ISA which is the architectural level and then everything that happens below it's it is internals Intel internals the micro architectural level that is not really the access time of memory yeah yeah it's technically not defined that kind of you probably have some uh definition saying that it's gonna be faster whatever but at that kind of granularity not at the kind of nanosecond granularity that people actually use to compare is like aha this one was faster okay I thought um the um one of the one of the mitigations but I'm not sure if that was meltdown or specter is that browser may cause uh decrease to the resolution of that time was so you can't you can't explain it by travel screw which is also very ugly fix in a way but this is actually much more than just mother and specter this basically generally just to be able to not do the whole cash uh sniffing right yeah so any kind of cash sniffing whatever he gets you get stopped by the the hammer especially yeah yeah right um yeah the other thing that was interesting about this was uh I think there was a discussion on the linux kernel mailing list where linus throw a fit and uh uh somebody else tried to explain it to him a little but I I don't know I haven't really followed that after the initial couple mails I read but it's interesting there was a very interesting article about the whole like the way you're talking about it more than half like what does intel do to it not so much of like the micro architecture side of things uh by uh about uh whether we should like whether we should take an intel like whether we should be angry against intel or how should we approach them so he's basically saying that the problem is because uh you don't we are we are not paying them enough money or like you know because we're because of the way the whole economy works they are more and more uh what like the intel's like hiding more and more things in the way they implement the micro architecture so like we are going away and away from transparency of how stuff works internally and then this kind of stuff will pop up uh because of the way uh the whole stuff is it just because it just gets more complicated right it's only that right it's also they don't open it up right if it was more more if we first explain better we will be able to find this way earlier and we you know not not with like this stuff in I don't know a million machines or whatever part of it is probably also the fact that the ISA is so far removed from really hard yeah that's that's the complexity yeah x86 and all of these things are patches and patches and patches but I mean that that's not really a change in the approach of this right it's really just the complexity underneath that layoff abstraction that you need the documentation that you need to implement things um it just gets more complicated it's not a not a political thing or like how did he explain that political but yeah maybe I maybe I'll just post the the link to the article there I think it's it's better I think he explains it better than I do but a lot of issues with a lot of stuff being hidden because if you know the thing is the second you have something like this people's gonna call people are gonna call for rms and then he tells to you know take on all the cost of dealing with all this stuff so they try to hide more and more things because there's a lot of times like you know in the silicon process you know you have buggy ic so they're you know I think AMD was covering this where they had a four core ic and then they'll just test the four cores and one of them was underperforming they just cut out the the core and then sell it at the three core ic yeah well I thought it was also with with um that's not really called I thought it was standard practice also for intel and also the the uh the the frequency the I think the clock frequency the frequency been this thing it depends yeah it depends on the quality of the chip if I sold you a four core chip saying well this is a three core chip but it's you know whatever I I'll give you a 25% discount many people will be like no I don't want this right but if I say yeah it's a three core chip right so there's a lot of economics and how people think of us psychology yeah yeah anyway I'll close the link to the to the article it's interesting but this was it was on the other end Intel has made an absolute fuck up on handling the servers either they had like six month head start yeah I'm pretty sure they were running around like less chickens for six months yeah sounds like it but but then yeah nobody would like in in December where you started reading the news of of strange OS patches with very little comment like in the linux kernel as well just um and and then people started looking I think at the updates for was it windows or OS X where they also like yeah yeah yeah it was interesting I am and I wonder what the long-term damage for Intel is as well um it's just this approach of doing out of order execution needs to be much more thought than much more probably you know it's like much more formalized and somehow tacked to the to the icing it now it's like in hindsight it's like of course this is this is a vulnerability and I mean you wonder why nobody thought about that when you say like wouldn't you think about the side effects of doing these things um first and and think of like the people who built this should know yeah it's all right no I think yeah I think I think we're done no need to I think what's interesting also is like if this is you know it's just if you think about it's like a super simple you know very easy straight forward just all the things that haven't been changed that haven't been cleaned up that should have been cleaned up imagine all the other crazy things that you can have with all the different modes of the cpu and the sleep mode and this and that and how that interactive you will find a lot more of these kind of bugs going forward now that people are saying look at this okay I'm following it now the register allocator is going to be the next search okay think about it right it's like super complicated this stuff is simple it's it's kind of cool uh I I guess this is getting more attention now because some a couple of young researchers these guys uh PhD students and everything sort of this sort of became overnight stars of the security scene more or less and and Google kind of took second place they're like oh yeah we also discovered this stuff and they actually had a nice I think the Google blog entry looks a bit easier to understand as well right there's a bit more um uh graphics and stuff in there but um I didn't I didn't actually read that I just looked at that yeah let's go for bios