Episode 44: Spectre & Meltdown

Posted on by Christie Koehler

Download: Episode 44.

This week Audrey and I chat about Spectre and Meltdown. Enjoy!

Show Notes

Community Announcements

Now Broadcasting LIVE most Fridays

We broadcast our episode recordings LIVE on most Fridays at 10am PST. Mark your calendars and visit recompilermag.live to tune-in.

We love hearing from you! Feedback, comments, questions…

We’d love hearing from you, so get in touch!

You can leave a comment on this post, tweet to @recompilermag or our host @christi3k, or send an email to podcast@recompilermag.com. You can also leave us an audio comment by calling (503) 489-9083.

Transcription

CHRISTIE: Hello and welcome to The Recompiler, a feminist hacker podcast where we talk about technology in a fun and playful way. I’m your host, Christie Koehler.

Episode 44: Spectre & Meltdown. This week, Audrey and I talk through those two exploits and try to explain in simpler terms what they are and what they mean for people. And we also, of course, share our favorite things on the internet. Enjoy!

This week, we’re going to talk about Spectre and Meltdown. Those are kind of groovy names.

AUDREY: Yeah. I saw somebody point out that Spectre haunts you and Meltdown melts the borders. So, they’re good choices.

CHRISTIE: Okay. So, this is all very new. I think a lot of us are still even processing what this means. Did this just start yesterday or Wednesday?

AUDREY: Wednesday. So there’s [inaudible] of security of vulnerabilities that we all found out — well most of us outside the various specialized work that’s involved in fixing them found out about just this week. We got the announcement I think a week early from what was scheduled. Somebody leaked it and so, Intel and other companies were forced to say something a little bit faster than they intended. But work on understanding the bugs and looking at how to mediate them has been going on since June, I think.

CHRISTIE: Yeah. The CVE was first filed in June. And so, that’s I think when people started getting notified about it. I do think that having read through the Spectre and Meltdown papers that this has been work that’s built upon ongoing work that predates that. I think we can get into that a little later.

AUDREY: Cool.

CHRISTIE: So, I think what we wanted — this is one of those combinations of where the media and others were reporting that this basically affects everything. And then it’s really bad, like it doesn’t require physical access to the machine that it can’t really be traced. And then it affects a huge number of platforms. But the explanation around why that is so is very, very technical and complicated.

AUDREY: Right. Because it happens at such a low level on the system that it’s something — I mean, just to read about it and to make sense of it, I had to understand a lot of things about processors and about how we use computer processors that I hadn’t known before. And that makes it harder to explain.

CHRISTIE: And the thing that I think is important to keep in mind here is that the researchers working on this are basically making observations in empirical experiments on the processors rather than — so, they’re making guesses and hypotheses about what’s happening, and they’re having to try things and see what the results are and sometimes the results are variable. The researchers aren’t saying with certainty this is a thing that is happening or they can say some things are happening but they can’t specifically define the bounds of what are happening.

AUDREY: That’s why those research papers are valuable because they try to show the extent to which it can be predicted or determined and how you would test that, right?

CHRISTIE: And there’s also multiple people working on this.

AUDREY: I thought it was interesting that for both vulnerabilities, it referenced multiple groups that had found it on their own and come together once they started reporting it. So yeah, this had come out of multiple sets of research.

Another aspect of it that I realized reading this stuff is that it’s a part of why this isn’t just immediately obvious is that what the processor is supposed to do is to find a certain way, but you have to actually test it to find out. And then you have to look for loopholes in what it’s supposed to do and whether it’s doing these things. It’s like this very intense QA process.

CHRISTIE: And not just loopholes but unintended side effects. Or in some cases, acknowledged side effects but may have a different degree of impact.

AUDREY: Yeah.

CHRISTIE: So, we’ve got these questions that we wanted to talk about at a level that I think most of our audience can understand how Meltdown and Spectre work, how the attacks could be delivered, how close is that happening today, what steps should people in the industry be taking, and what steps should users be taking. And I think there’s probably a level on hand that is like industry as everybody from the chip makers to SaaS vendors. If you’re a hosting provider, you’re part of this. If you’re a DevOps or system administrator, you probably need to have an understanding of this too.

With different researchers working on this kind of in parallel — that’s why we have the two things: Spectre and Meltdown. And my conception of it is that Spectre is really like the broad issue.

AUDREY: The generalized set of cases that rely on these characteristics.

CHRISTIE: Right. And that Meltdown is a specific application of it or a specific case of it that apply at least to Intel chips. I don’t know if it’s been ruled out, I don’t know that AMD and ARM have been completely ruled out. But with Intel, there’s a special case because the researchers were able to show a particular attack vector based on memory access.

AUDREY: Yeah, that’s how I understood it too.

CHRISTIE: So, you started off by saying that to understand this, you had to understand a lot about how processors work. Oh boy, is that almost an understatement! To the credit of the people that put these papers together, I think they actually did a pretty good job covering the basics or the building blocks. But wow! Did you know that processors had gotten this complicated?

AUDREY: No. I mean, this is really cool because I just generally understood that there were these speed up characteristics that we had acquired, like why do things get faster and faster, sometimes from fairly similar starting points for the architecture. And it turns out that it’s all these techniques that they’re using, that they’ve thrown in over the last 10 years. And they all seemed very clever. So, I could appreciate why they’ve done those sorts of things and like what is different from me using a Macintosh in 1990 where I can only have one application open at a time to what an Intel processor can do today. There’s just a huge, huge distance between those things.

CHRISTIE: I think a lot of people are sort of [inaudible] building blocks of a computer and they know that a computer has a thing called the CPU that is maybe they can centralize it like the brain or the part of the computer that does the math or does the processing. And I think that is all reasonable to say. But also CPUs have become incredibly complex systems in themselves and have their own memory caches and different parts that do different logic and make decisions about how to do the work the processor needs to do.

AUDREY: So, it isn’t just about the operating system dictating that there are these processes and these threads and things that they’re going to throw at it. The processor itself makes a lot of decisions, I guess for lack of a better word, about what to do what it’s being asked to do.

CHRISTIE: Yes. So you have the operating system and it runs programs and is told by programs to do things. And the operating system then tells the CPU to do things. And the CPU has its own set of things it does when it gets in an instruction.

And as a way of eking out maximum performance from chips, the chip makers have added all kinds of logic. And one of the things they’ve added is speculative execution. And that’s the title of the Spectre paper: Exploiting Speculative Execution. I’m going to try out my understanding, Audrey, and see how well it matches with yours.

We’ve both written code, and some of our audience has written code. So if you think of code like a recipe, you say, “Do this, then do this, then do this.” And you think of that as like happening in that order. But when a program gets sent to a CPU, the CPU may not do these things in order. It may do them in parallel. It may do 1, 2, and 3 all at once.

AUDREY: Cookie recipe is actually a good example for this because you have the wet ingredients and the dry ingredients. And so, you’d have two people making them at the same time. And then at some point, you would combine those results.

CHRISTIE: Right. The issue becomes what if one part of the code is conditional upon something and so the CPU is doing both. And what it does is it does both with the idea that, “Hey, if it turns out we didn’t need to do the second thing, we’ve just wasted time that we would have spent doing nothing anyway.” So, it’s worth it to do that thing and then just throw away the results if we don’t need it.

Using the cookie analogy, there’s the person doing the dry ingredients and the person doing the wet ingredients. If the person doing the wet ingredients realizes in the middle of it they’re missing an egg or the eggs are bad, then both things will be rolled back or the combining would be rolled back.

AUDREY: Yeah. You wouldn’t combine them. You would start over on the wet once you had a fresh egg.

CHRISTIE: Right. This is actually pretty ingenious, I think. And the rollback thing works, the direct effects are rolled back. That’s not the problem. The problem is that certain kinds of code execution, the speculative execution, can create side effects like changing the data that’s in the CPU cache. And that does not get rolled back.

AUDREY: I mean, that makes sense that it would need to put something into the cache because it’s flipping this stuff back and forth, right? That there would be some memory of what it was trying to do.

CHRISTIE: Right. And one of the main ways that processors get performance improvement is by using cache because memory access is very, very slow. So, if you weren’t using the cache, you wouldn’t get the performance.

That’s basically the heart of it right there. The specific ways in which you can then access this indirect fix, that’s the stuff I’m still dissecting [inaudible]. But I think for the purposes of our discussion, that’s a key thing.

AUDREY: In the descriptions of these, I saw somebody point out that the way that these processes go in is kind of a pipeline. And so, it’s trying to make sure that there are the fewest gaps in the pipeline possible. Some of this execution is determined by basically we have room to do this much. So, let’s shove that in there that the processor is trying to create just the smooth line of processing happening at any given time.

CHRISTIE: And the other thing that really surprised me and intrigued me was that the chip itself has predictive circuitry that makes decisions about the likelihood of a particular piece of code to actually need to be executed. And that part of utilizing this attack is actually training the CPU to take a particular branch and then using that to access something that you shouldn’t have access to that you want to get access to.

AUDREY: This is where the trial and error makes a lot of sense for the researchers because they would have to find out what sorts of requests of the CPU trigger that branching in certain ways. You would need something that reliably works the same way so that when you flip it and suddenly created it for branching effect, it still wants to guess the previous result.

CHRISTIE: Yes. Sorry, I’m looking through my highlights of the paper. They say, “From a security perspective, speculative execution involves executing a program in possibly incorrect ways. However as processors are designed to revert the results of an incorrect speculative execution on their prior state to maintain correctness, these errors were previously assumed not to have any security implications.” This particular thing is something that people have known about or this happens and is something that people have known about for a while. It’s this sort of realization that these indirect effects can actually be leveraged to leak information.

AUDREY: I think I do understand a little bit about that leaking that it isn’t that you can access the memory cache if you’re the wrong part of the process. It’s that how long it takes you to get the [inaudible] response, actually tells you something about what’s in the cache.

CHRISTIE: Yeah, the timing of the access is somehow important to this and that’s the part I’m still trying to figure out because there’s a handful of different mechanisms that they’ve discovered, and they say that there’s possibly other ones too.

AUDREY: The one that I saw described on Twitter used the library analogy, that you are asking a librarian to go pull books from the special collection and then sort of making guesses about what’s the first letter of that page and how long it takes the librarian to look and go, would tell you something about what was actually there.

CHRISTIE: Gotcha. Okay, so that’s deduction or whatever.

AUDREY: And it’s a sort of thing that if you try to do it manually, this would take forever. But the idea is that with code, you could try every letter in the alphabet, one after the other really fast. These aren’t actually difficult things to execute.

CHRISTIE: Meltdown doesn’t use branch prediction for achieving speculative execution. Instead, it relies on the observation that when an instruction causes a trap. It’s still using this out-of-order execution but just in a slightly different way. And I think this is a part that is very specific to the Intel chips is that it says it exploits a privilege escalation vulnerability specific to Intel processors due to which speculatively executed instructions can bypass memory protection. The operating systems have been expecting the CPU to be the gatekeeper in terms of memory access. If a process asks for kernel memory from user space, the operating system has been expecting the CPU to say no and using this speculative execution trick that is getting bypassed.

AUDREY: Great. So there’s the circumstance where the Intel CPUs will in fact hand you something out of the memory cache even when you should have access to it.

CHRISTIE: Yeah, basically. We’re simplifying it a little bit. Personally, I want to understand this on a deeper level but I think for the purpose of what we’re talking about here, that’s probably deep enough. What’s striking about this is because we have favored performance so heavily, this just basically affects all these different kinds of chips.

AUDREY: Everybody uses the same techniques because they’re all very fast and efficient.

CHRISTIE: Right. And it’s at the hardware architectural level, so it’s not a bug per se. It doesn’t create the same markers when it’s being used. It just looks like normal programming activity to take advantage of this. So, there’s no particular way to know if anyone has taken advantage of this on your system.

AUDREY: Right. It wouldn’t leave any traces other than what a program doing a correct thing would.

CHRISTIE: Right. And I suppose someone came up with one program that did this and it got widely spread, that would program would be recognizable.

AUDREY: It’s something the virus software would try to catch.

CHRISTIE: Because of the way it allows memory leakage kind of across the board, it means that our often used ways of isolating programming space doesn’t work with this. So it means that running a program to take advantage of this and one container can end up reading the memory of another container or of the host, and so it has huge impact for a Cloud computer.

AUDREY: So, anything that accesses the same CPU can potentially get at anything else accessing the same CPU, even though we’ve got these layers of software that contain them, in other words.

CHRISTIE: Yes, exactly. That’s a better way of putting it. And because of the optimizations that had been made to JavaScript and JavaScript engine’s tool to be very performant and work at a very low level, this can actually be executed with JavaScript which is something that we all [inaudible] not loading JavaScript. It means that you can be browsing the web and potentially execute [crosstalk]

AUDREY: And this is actually the part that was mind blowing for me because I’ve written JavaScript but not in a while, and I had no idea that JavaScript had been taken so far into that low level programming that this was possible. That was pretty amazing to me.

CHRISTIE: I had a sense of that just because my time at Mozilla, I had a sense that because both Mozilla and Chrome, there’s a vested interest in making JavaScript basically work like a low level language for speed and whatnot. So, it didn’t surprise me. I can’t fully explain how it works.

AUDREY: Yeah, I would love to see an explanation, like a breakdown of that, that it was aimed at programmers in general because I think it could be really educational about the ways the different programming languages work on different levels and kind of where they tie back into that operating system level. It would be pretty interesting.

CHRISTIE: Again, this came out Wednesday afternoon. We decided yesterday morning, we talked about it and then [inaudible] for hours, read through the papers. It’s like there’s just so much to get caught up on. So, I’ll keep looking for that. If someone listening has that, let us know. I think it’s a very complicated thing, so I’m not sure that there’s something already out there.

We’ve talked before a little bit about just how complex computing has become. We’re kind of in [inaudible] because even to use a computer or even to do one aspect of creating technology, you have to touch the entire complicated stack. You can’t possibly know everything about it. Basically, if you’re doing frontend development, you can actually go all the way down to the CPU because of how complicated the ecosystem is now. But most people probably have no sense…

AUDREY: Because again if it wasn’t required for your work or you weren’t looking for vulnerabilities yourself, you probably wouldn’t try this.

CHRISTIE: I don’t blame people. I mean, how could you do — to get up in the morning and do the things we have to that day, you have to put blinders on and ignore 98% of the things or it might crush your mind, right? Well, I don’t ignore them but like compartmentalize, I don’t know.

AUDREY: You can’t be aware of everything all the time. And it’s why we like to have separate security teams, if possible, to have another look at the code and see it through these different lenses.

CHRISTIE: It also, to me, shows — this is a thing that’s personally important to me but it also shows the importance of not passing the buck. Be clear about what the boundaries if you work hard but also don’t be like, “Ah, the other team can handle that.” Because there can be unintended…

AUDREY: It’s always worth asking pesky questions, if you’re in a work environment where you can get away with it anyhow. But it’s worth it for our work, for our projects to ask these pesky questions because sometimes the ‘what ifs’ turn out to have very different answers.

CHRISTIE: That’s right. So, the good news is that there’s already mitigation for Meltdown. I think some systems already have it and others are working on rolling it out. I don’t have a complete list of the status of that. I’m still trying to track it down. But the bit about the user space versus kernel memory space and all that, that was something that the Linux kernel team had already been working on. And there’s this patch called KAISER which basically changes the way that virtual memory is addressed and significantly restricts what user base has access to. It basically tries to limit it to only the things that are like required for the kernel to still work on the CPU. And so that’s being ruled out.

AUDREY: I mean, right now for most end users on most systems, if you apply your security patches, you’re going to be reasonably safe. Somebody can always come up with another variant of this.

CHRISTIE: You’ll be reasonably safe in the Meltdown variant. I just wanted to clear that those patches are still being rolled out. So, we’ll try to put together a list of them but if you apply the patch like yesterday, you still may need to — basically, if the operating system patches come out, apply that right away. It sounds like a bunch of the Cloud providers already applied patches and rebooted their VMs.

AUDREY: Yeah, and because again in order to avoid being vulnerable, you have to stop downloading software and stop allowing JavaScript in your web browser.

So, I looked at the Wikipedia page for Spectre and it’s got a pretty good description but somebody might have already edited it out. But there’s a line in there that says, “Alternately, browser based exploitation can be prevented by disabling JavaScript.” I don’t know, try it. I’d like to hear how it goes. But I think you’re not going to find it a very usable experience. It’s going to really limit what you can do.

CHRISTIE: There are two components to that. There’s how usable is the web without JavaScript and we don’t actually not like, yes it cuts off maybe one significant vector but it’s not a guarantee. I’m not going to go to the extent of turning off JavaScript, that will break too much of the web for me. I do think it’s worth having an ad blocker.

AUDREY: We talk about it all the time and I finally installed one.

CHRISTIE: Right. And I feel like 10 years ago, there was the one go-to and now, I don’t know what the go-to is. I asked on Twitter and got recommendations for uBlock Origin, Ghostery, Privacy Badger and the other uBlock which is not uBlock Origin which is confusing to me.

AUDREY: There’s also Adblock Pro or Ad-Blocker Pro or something or different.

CHRISTIE: Even though I was like at Mozilla when that happened, I don’t remember which is the one — so, I don’t have a recommendation.

AUDREY: I’m trying Ghostery. It had a distinct name. That’s a terrible way to pick, I guess, but the fact that it had a distinct name and logo made me feel like at least I wouldn’t be confused about what I was using. But I do like the way that it’s set up. It lets you kind of disable categories of things and really easily see what’s on the page and what it’s blocking, what’s not blocking. For now, I’m going to continue to use that.

CHRISTIE: Okay. I think technically I got the most votes for uBlock Origin but not by a lot. I’ll keep my eye out for recommendations on that. If people listening have one, let us know.

AUDREY: To go kind of back through the mitigation stack back the other way. I mean, for end users, we install ad blockers, we install our patches. For people who work in the virtualization software, they’re going to try to create systems that have better restrictions, less access to the things that allow these attacks including the accuracy of those timing checks which I thought was really interesting.

CHRISTIE: Right. That’s what the Mozilla statement talked about.

AUDREY: Chrome says that they’re kind of doing that too.

CHRISTIE: Yeah, they changed the interval. They made the interval less [inaudible].

AUDREY: My guess is that that means that any code that was trying to implement this attack would just get noise instead of the lines of your email or password or whatever.

CHRISTIE: There’s a bit in here about the granularity is important when you’re trying to encrypt information because the less granularity, the less likely you are to reconstruct.

AUDREY: Oh, I see. So, the way that you can kind of [inaudible] the sense and still make sense of it. That’s fine because our brains can be set together. But once that string is encrypted, every bit has to be accurate or else you really can’t decrypt it correctly. If there’s some error production built into that.

CHRISTIE: I’ll try to pull out some of the key parts of this for the show notes.

AUDREY: Okay. I don’t know. I think that’s an interesting detail.

CHRISTIE: I thought I had it but I didn’t. But I do think this bit in the conclusion says, “A great deal of work lies ahead. Software security fundamentally depends on having a clear common understanding between hardware and software developers as to what information CPU implementations are (and are not) permitted to expose from computations. As a result, long-term solutions will require that instruction set architectures be updated to include clear guidance about the security properties of the processor, and CPU implementations will need to be updated to conform. More broadly, there are trade-offs between security and performance.”

AUDREY: And this is the other thing that we really have to talk about, like how much are things going to slow down both for the medium mitigation and the longer-term CPU changes that need to happen.

CHRISTIE: It says, “The vulnerabilities in this paper, as well as many others, arise from a longstanding focus in the technology industry on maximizing performance. As a result, processors, compilers, device drivers, operating systems, and numerous other critical components have evolved compounding layers of complex optimizations that introduce security risks. As the costs of insecurity rise, these design choices need to be revisited, and in many cases alternate implementations optimized for security will be required.”

It’s interesting to me to think about what it looks like to start favoring security over performance, and especially if you think about the attention economy. I’m just now thinking about this, but is it possible that this need for performance is about capturing attention? Do we really need these really high performing processors to get the best for us out of technology or is this extra performance really just for sucking our attentions and causing us to be insecure?

AUDREY: I think that there are a couple of different parts to that. I guess it isn’t the primary reason I would think about but it matters. A lot of the software I use is on its 20th version or something and I don’t mean like Chrome where they release a new one every two weeks.

CHRISTIE: Meaning it’s been around for a while.

AUDREY: Yeah. And so, there’s cruft. And so, I can tell as I update things that part of what my intensely enhanced processor power is doing is basically allowing that cruft to not suffocate the program. Does that make sense?

CHRISTIE: There are inefficiencies because they’re just piling either bad or outdated code. They just keep piling on top of it rather than optimizing it.

AUDREY: Another part of this is that our expectations about the UI of what we use have increased as more things have been delivered. So, some of our processor power is going toward giving us a smoother interface and a more detailed interface and more 3D graphics and better rendering and being able to put all these pieces together. Or even allow you to have 200 browser tabs open and be able to switch between those correctly. Like there’s lots of things that make our software feel more usable.

CHRISTIE: Feel more usable. I’m not sure it always is…

AUDREY: Oh no, I mean, you get used to it, I get used to it. And so, I expect more and I push it further. I think that the way that our processors have sped up ties into that. My expectations can continue to increase because they’ve continued to deliver more abilities. I get back to that like, what did I do with the computer in 1990 and now? I used to have to close my word processor to be able to run a game and I couldn’t do both at the same time. We’ve just delivered a lot more interactive performance in a way.

CHRISTIE: Right. And surveillance capitalism.

AUDREY: That’s the other part, right? What does your web page do? Like people talk about these slow pages and heavy pages and all these different kinds of words they’re describing like the load and the capacity. What the web page does these days is enormous. It’s not like we’re just delivering some text and some hyperlinks.

CHRISTIE: When we were talking yesterday getting ready for the show talking about different ad blockers that could be used, you were looking a little bit about Ghostery’s business model and you pointed out that their business model is that they allow users to opt in to reporting the things that they block when they visit websites. And that they then go and sell that as a service to website owners for optimization. And I was like, it’s funny, scary to me that website owners don’t know what JavaScript [inaudible] and a lot of times they don’t because of these ad networks.

AUDREY: And also the other services that you make use of. Like I said, I’ve been really enjoying Ghostery’s interface because every time I open a new web page, it gives me a way to see what’s loading. I had no idea that my bank was using so many trackers. So, right now those little tracker pixels, I haven’t turned them off and it’s intriguing.

CHRISTIE: When I was at Mozilla, they had a policy of not loading third party JavaScript. I don’t know if this is still true or not. But it was a pain in the butt to integrate with anything because every web service expects you to load to a JavaScript. And in a lot of cases, that’s the only thing that they allow in their terms of service. So, it’s a multi focal problem, I think.

AUDREY: Yes. The attention economy stuff that you’re talking about is sort of a mix of a couple of those things that we get things faster, updated more, flashier, all of these things that keep us engaged.

CHRISTIE: And companies are all about like move fast, break things and part of moving fast involves possibly degrading quality or not thinking about performance, not optimizing [inaudible] code.

AUDREY: Every web developer that’s been told you don’t have to worry about scaling it. I mean, you don’t but at some point, you do. And so, all of these changes have allowed you to push that point off further and further and further, and let you go longer and longer without having to think about optimization.

CHRISTIE: I found a bit about how — and it’s in the Meltdown paper which is why I couldn’t find it earlier — about the granularity and why this thing that we already know about is suddenly more of a problem with Meltdown.

Meltdown fundamentally changes our perspective on the security of hardware optimizations that manipulate the state of microarchitectural elements like this accessing cache after an indirect operation. The fact that hardware optimizations can change the state of microarchitectural elements, and thereby imperil secure software implementations, is known since more than 20 years. Both industry and the scientific community so far accepted this as a necessary evil for efficient computing. Today it is considered a bug when a cryptographic algorithm is not protected against the microarchitectural leakage introduced by the hardware optimizations. Meltdown changes the situation entirely. Meltdown shifts the granularity from a comparably low spatial and temporal granularity, e.g., 64-bytes every few hundred cycles for cache attacks, to an arbitrary granularity, allowing an attacker to read every single bit. This is nothing any (cryptographic) algorithm can protect itself against.

AUDREY: Intriguing.

CHRISTIE: Yeah.

AUDREY: I mean, no wonder everyone saw this and went, “Ahhh…” because this is so big, so broad, so integral to how we’ve been doing things.

CHRISTIE: KAISER is a thing, there is a patch out there but it will slow down certain operations because of the way it changes and how memory is accessed.

AUDREY: Over time, we should see things kind of trickle a couple of directions. Even if the lower level operations have to change, software on top of it should be able to re-optimize based on that. In the short term, I would expect something stacked kind of weird.

CHRISTIE: Possibly, yeah. There’s going to be updates from Chrome and Firefox and I’m guessing Safari, I don’t know.

AUDREY: They packaged them with the operating system update sometimes.

CHRISTIE: I believe basically what they’re doing is disabling a certain low level function and then changing the interval at what that cache can be read, something like that. I don’t think those have come out yet. If you’re running Chrome, you can enable the site isolation which is an experimental — I don’t know if it’s still experimental. You have to go to a special URL and enable it. I’ll put a link to that in the show notes. And what that does is make every site run in its own isolated process. I’m not sure if that right now mitigates Meltdown, though.

AUDREY: I saw that and I wondered the same thing. I mean, it makes sense that the isolation could prevent a lot of things while also being a little slower because again, that pipeline is right where they’re trying to set all the processor instructions one after the other.

CHRISTIE: I enabled that but now that I said that, I want to go back and read that again. Also, I think that Chrome has been acting a little funny. So, I don’t if that’s because of it or not.

What can people do? Update your browsers as soon as those patches come out, don’t wait. Install an ad blocker. Turn off JavaScript [inaudible].

AUDREY: And report back.

CHRISTIE: To us or to the site owners?

AUDREY: Oh, geez. Anybody.

CHRISTIE: If you’re a site owner, I don’t know. Turn JavaScript off and see what your website looks like. I think of all those one-page React apps that aren’t just going to totally break if JavaScript goes off.

AUDREY: Yeah, my web page won’t, my personal web page. I don’t actually know if they — on The Recompiler, I don’t think I can do anything useful.

CHRISTIE: You can feel smart about that now but then we got to update, and you’re like, [inaudible]. There’s pros and cons to everything.

AUDREY: I’m not particularly smart about this. I give myself a lot more work than I need to.

CHRISTIE: Yeah. I like tinkering but I’m not into the static site generation. Operating system patches when they come out. If you are running any virtual machines for hosting stuff, make sure those get patched. The hosting providers that you’re on should be releasing patches. You should do both, I think. And then if you’re an electrical engineer that works on chips, good luck to you.

AUDREY: I think that there’s a very specialized skill set that’s going to have some good employment opportunities in the near future as a result of this.

CHRISTIE: Definitely. I think just in general if you work somewhere in the text stack like try not to overwhelm but also don’t necessarily take things for granted, they’re like something that’s taken care of.

AUDREY: Yeah. Again, it’s worth asking questions.

CHRISTIE: Did you see the bit about the stock that Intel CEO sold back in October?

AUDREY: I did, yeah. Sooner or later, we’re all going to find out.

CHRISTIE: Yes. The CEO of Intel sold $39 million worth of stocks back in October. Now Audrey, the CVE is from June. Do you think he knew? Something really weird would have to be happening in Intel for him not to know that.

AUDREY: Yeah. I mean, it’s like this quarter by quarter reporting thing where after the quarter that it was discovered in, do you know what I mean? There’s always this risk assessments and the things that can cause loss of value. If that’s getting reported back on a quarterly basis, then maybe he did it as soon as he heard.

CHRISTIE: I didn’t look into that because I know you can schedule these things and I know that it’s complicated. It also got me wondering like if I were Brian, “How much do the current administration and the brokenness of the government play into my decision?” If it’s me, I’m thinking, “After all, the government’s totally broken right now. The SEC probably isn’t going to enforce this.”

AUDREY: I don’t know. I think it’s [inaudible] to go after. Yeah, I do. I think it’s [inaudible] and they’re pretty obvious.

CHRISTIE: We’re talking insider trading, right? Like the thing Martha Stuart went to prison for, right?

AUDREY: Right. So, I don’t think that he’s going to get off easy. I think they’re going to look at it pretty thoroughly.

CHRISTIE: Your prediction is he’s going to get in trouble.

AUDREY: Yes, unless he has meant to do this in the most innocent way possible. But I have doubts.

CHRISTIE: He better have a reason.

AUDREY: You’d have to come up with some other rationale for your action that both show that you didn’t have this information, that you had other information that [inaudible] idea or something else going on that gave you a reasonable step to take.

CHRISTIE: Did you ever get why it was — because they were working on a coordinated release and it looked like it was pushed up at least a week. Did you ever track down why?

AUDREY: I didn’t check it, though, but I’d thought I read that The Register jumped.

CHRISTIE: Okay. So, it was a journalist that just wanted to have his scoop?

AUDREY: That was my impression. Embargos breakdown all the time over this stuff.

CHRISTIE: I feel pretty good about our discussion. There’s definitely more to dive into but I think sort of for the first pass, it’s really good. I’ll definitely pull out some of those quotes from the papers and I’ll look around for some kind of thing that explains how on earth JavaScript gets into those lower level things. That may take me a little while to find out.

AUDREY: Then we’ll maybe let us come back to some of that Bitcoin mining in the browser stuff and other sneaky uses of your web page.

CHRISTIE: Right. Do we have a favorite thing on the internet this week?

AUDREY: I did. It’s not like a short silly thing but I read this really interesting article or a blog post yesterday about Google maps. And what it was talking about is how Google maps and Apple maps have collected different data and over time, how this has been enhanced and how Google now has a capacity to show you basically where business districts are except it doesn’t appear that they did that by going out and asking or measuring exactly, like, “Oh, here’s the business cluster,” like having somebody manually draw a line around it. It looks like they were able to take one set of data and use that to create a second set of data. And eventually end up with those brown shaded areas that you see around shopping areas, like a street that’s got a lot of shops in a row. And it was just sort of really interesting breakdown of how that data collection works together and the choices that Google made and the choices that Apple made, how they all tied together into us having information that’s useful.

CHRISTIE: Wow! What info did they use to determine a business district?

AUDREY: So, it’s a combination of building shape and business type.

CHRISTIE: And like the certain concentrations or densities?

AUDREY: It’s more like the building shapes give them the outline and then the business types associated with these buildings allowed them to decide that that might be shopping and restaurants versus something else. I thought it was educational and did not scare me and didn’t have anything to do with melting my processor.

CHRISTIE: Yeah. It’s nice to have something fun on the internet that isn’t like, “Oh my God, computers!” I just have a few tweets that are fun, one of which is cat related. I’ll show this to you because it’s like an oil painting with this very fluffy tabby orange cat and then a fluffy orange tabby cat in front of it.

And then the other one is someone tweeted. The caption is ‘this is how much I’m striving to love myself this year’. There’s actually two cats in the picture.

AUDREY: Yeah, I see. There’s one in the pond and one on the bridge. And they are orange tabbies. It’s very cute.

CHRISTIE: Do you think the real cat is the cat in the photo?

AUDREY: Yeah, I think so because it’s got the same tail.

CHRISTIE: Okay. And then the other thing I appreciate is related to the Spectre thing. It says ‘That feeling when your 1979 VAX 11/750 is immune to the Intel kernel memory leak bug, and will suffer no performance impact as a result of the fix’. And this made me happy not just because [inaudible] but because my first job in tech which is at [inaudible] is not one of the machines that I was [inaudible] which is what we talked about last episode. So, it just gave me a happy memory. And I was like, “Hey, I’ve used one of those.”

AUDREY: Yeah, I’ve seen a couple of variants of these [inaudible]. Somebody else had built a system out of Raspberry Pi’s. People are just sort of pointing out like, “Well, this technology is not vulnerable.” Yes, there are some very creative ways to approach it.

CHRISTIE: Yes. Alright, I think that’s a wrap. Thanks everyone for listening live and thanks everyone listening to the show after the fact. We’ll talk to you all next week.

AUDREY: Thanks Christie.

CHRISTIE: And that’s a wrap. You’ve been listening to The Recompiler Podcast. You can find this and all previous episodes at recompilermag.com/podcast. There you’ll find links to individual episodes as well as the show notes. You’ll also find links to subscribe to The Recompiler Podcast using iTunes or your favorite podcatcher. If you’re already subscribed via iTunes, please take a moment to leave us a review. It really helps us out. Speaking of which, we love your feedback. What do you like? What do you not like? What do you want to hear more of? Let us know. You can send email feedback to podcast@recompilermag.com or send feedback via Twitter to @RecompilerMag or directly to me, @Christi3k. You can also leave us an audio comment by calling 503 489 9083 and leave in a message.

The Recompiler podcast is a project of Recompiler Media, founded and led by Audrey Eschright and is hosted and produced by yours truly, Christie Koehler. Thanks for listening.