- This is a panel where we're gonna be talking about the Spectre vulnerability that Chandler has just
been informing us all about for the last hour and a half. He did a fantastic job,
I think you'll all agree, so hopefully this will
be an opportunity for us to fill in any of the
details that were missing, not that I think that there was much that could've been missing, and we also have some other members here who'll give different perspectives on the issue and how we
might go about solving it. So, I'm gonna reiterate
Chandler's ground rules, which is that there is
a lot of things here that are sensitive. We don't want you to be
afraid to ask any question, but do be aware that
there are certain reasons why things may not be able to be answered. There may be legal or
just general security, good practices, that we can sorry, we'll have to take it
offline or not at all. We would also ask that you don't try and invent a new speculation attack while you're here, on
this stage, or sorry, while you're on a microphone
in this public area. If you think you've thought of a, "Ah, I've got a great crack for this," keep it to yourself for now, and then speak to somebody
in a responsible way. But first of all let's meet our panel, so I'm gonna hand over
to Matt Miller here, who will introduce himself,
and then we'll work down and then we'll start taking questions. - All right, thank you very much Matt. As he said, my name's Matt Miller. I work for Microsoft. I'm actually in the Microsoft
Security Response Center. So, if you're familiar
with, or you run Windows, for those of you who do,
when your computer reboots, second Tuesday of every
month, that's our team. We're making sure that
vulnerabilities are getting fixed and that things are getting patched. I have one of the distinguished jobs of actually being able to
see all the vulnerabilities that come in through our door and try to look for the trends in the types of vulnerabilities
that we're seeing, so that we can go and try to
systematically deal with those versus doing the hand to
hand combat type of thing, so when Spectre and Meltdown, these other things, came in our door, I was one of the security
engineers that took point on a response to architect
our mitigation strategy. I work with my distinguished
peers on the right over here and try to actually design the mitigations for these types of issues and ship them, once
again, on Update Tuesday. So, that's a little about me. - I'm Chandler Carruth,
as you may have guessed, and, well, I work at Google. I was just gonna give
you a little bit more understanding of how I got
involved with this at all, because a lot of people
here know me from working on Sequels Plus, and LOBM, and
compilers, and performance, and, oddly enough, that had very little to do with what I just presented. I got roped into all of this last year, when they realized they might need to change the compiler
for some of the things that they were working
on to mitigate Spectre. I had no idea what they were
talking about, but I was game, and, as I got more involved,
I started to end up, like, tripping a little bit more. We started to find interesting news ways of using compilers to
help with security things, so that's kind of how I got
roped into all of this stuff. - Hi everyone, I'm John Masters, and I have a role inside Red Hat as the chief microarchitecture
lead guy I guess, these days. I started out running various alternative architecture
efforts that we had, and we needed someone
who knew a little bit about the internals of processors, so that was how I got dragged
into Speccy and Melty, and that's been the gift
that keeps on giving. I'm gonna give a shout
out to my girlfriend who got me the most awesome
Valentine's Day present ever. She got me a Spectre, Meltdown
vulnerability fighting cape, (audience laughs)
which is awesome. - [Miller] Why aren't
you wearing it right now? - I know, I forgot to pack it, it's awful. - [Chandler] I'm kind of
disappointed, come on. - I am, I know.
- Terrible. - So, I guess, if you've got questions, or you're starting to think about things you might wanna ask the panel, please start queuing up
at the two microphones. I get first dibs though, as I'm up here. I write Performance C++ code for a living, and I would like to know, how is this gonna effect me down the line? What might I expect down the line? As maybe I'm in a luxurious
situation I believe, from Chandler's sort
of threat vector thing, of not having to worry too much about it, but I'm worried my CPU's
gonna go really slowly, just for other peoples problems. Anyone wanna take that? - Meh, okay, well I'll give you some thoughts I have on this, right. It depends on your threat model. We have some folks who run,
in HPC Lab environments, they build their own code, and they don't want
some of the mitigations, because they have a different
security environment. They have guys with guns outside, and the network is unplugged
from the outside world, so there are some times where you say, "Well, I've got to fix Metldown, "because that's awful and
very easily exploitable," but you know, some contrived
branch predictor attack, or something like this, that maybe I don't need
everything turned on all the time. One of the concerns has been making sure, for those who want to
turn these things off, that that's possible, if it's appropriate to their environment, and I would say that that
ability is getting better, but some folks who are
seeing performance hits, who don't want mitigations, well, you need to go in
and asses what makes sense for your environment, but you can do that. Beyond that, I would say there's really two different tracks. It's things that are
painful in the short term and things that are
painful in the longer term. Things that are painful in the short term include things like OS level fixes, that Chandler talked about,
or didn't talk about, that alluded to for
Meltdown, variant three, where there is a cost
there, but, over time, you're gonna get new,
"They're all fixed now," processors, right, in future machines, and, your existing code,
you won't have to change it, it will just magically be okay. There are some things,
like Spectre variant one, that will live with us a very long time, and that will have a performance
hit over a longer period. - The other thing I wanna say is, I think the performance impact of this is something that people
have a lot of control over, so you can really customize the degree to which you take a performance hit. There's a certain base
line of performance hit for the operating system to
remain secure, in a basic sense, but past that, your
application can opt out of almost all of these kinds of things, and I think that's going to give people, who are not super subject
to this kind of risk, a lot of freedom. - Yeah, just to dovetail
with that you've said, it basically ends up being a
security performance trade-off, so evaluating your threat model, trying to understand
what risks you're willing to accept or are willing to tolerate, and that's gonna control
and dictate how much of a performance trade-off
you're willing to accept, at the end of the day. - That's cool, so there's no time soon am I gonna see an announcement
from Intel Alarm saying, "We're turning of speculation. "We couldn't solve it. "You're on your own, twenty times slower." - If you never branch, then
you won't have any problems. (audience laughs)
(Matt laughs) - That's a good plan.
- Awesome. All right, we'll start
taking some questions from the audience now. We're gonna start on the
left hand side there. - Hi, in his talk, Chandler mentioned that browsers are especially vulnerable, and I'd realized they were,
in JavaScript and WebAssembly, but they do it in different
pages, or different tabs, and even, in the different processes, which don't have the same address space, so how does this make browsers
especially vulnerable? They are like operating systems, right? - This is an interesting question. It might seem like, from looking at some of the discussions around Chrome and, historically,
Firefox's security model, that use a process level isolation, that they're not going
to be vulnerable to this, but there's actually a lot of shared work and shared processes in
even Chrome and Firefox, unless you enable a
special feature of Chrome called site isolation. That shared state typically
involves the JavaScript VM, so you do actually have different sites running JavaScript in your DM, and you cam imagine how this happens. You have a tab, and it's
got a webpage up there, but the author of that
webpage isn't the only author of JavaScript running in that tab. You also have advertisements in that tab. You have lots of other
code running in that tab, and code that you may never
know the author of, right? You didn't pick the advertisements, right? Some ad vending system did, and it picked a random
set of advertisements. If I want to do, you
know, have a lot of people that get a lot of information
from a lot of people, I can just buy ad space. - [John] Spectreads.com. - Yeah, right? And I can just put
JavaScript into that tab, and, if that tab happens
to be your email tab, or it happens to share a
process with your email tab, which, for example,
you might share between a search and an email tab, if they're vended by a similar company, then you're going to have
some overt risk there. - [Man] Then it's all compilation in fact? - No, I was just gonna add. Ultimately, the browser is
an example of multitenancy, right, where you have multiple tenants. In this case site origins
in the same process, and one of the reasons that
I think Chandler touched on, in his talk, is that these, in essence, are more of a challenge, because
you're allowing attackers to provide your JavaScript, that we are then going to turn around and, just-in-time, compile. So, you can just-in-time
compile your gadgets, that can create these sequences
that give you the ability to speculatively access portions of memory that you otherwise
shouldn't be able to access, and that's why, ultimately,
with site isolation, you actually start to
partition your tenancy into different address spaces, so that, even if you do
get one of those gadgets, you're not able to read sensitive content. That's the notion. - [Man] Right, but,
since it is JIT compiled, I have no way of knowing which address the instructions will get. How will I know which branch prediction's poisoned in this way? - I totally understand. I really did not understand this, when I first heard about
it from people like Matt. They were trying to explain
how the browser exploits work. The browser people that I
work with had to, you know, really work to get me to understand this. Part of the problem is, you can do more than you think you can. For example, you don't have to know the address at which
your branch needs to be in order to collide in
that hash table, right? Instead, you can just put
branches in a lot of places, and see which one causes
the branch that's supposed to be using that slot to get slower. You can just find collisions, and then they ended up going after gadgets that are even easier to build
out of JIT compiled code. For example, variant four, it turns out, is just incredibly easy to hit, if you're doing JIT compiled code. They tried a bunch of things, to actually change the
JIT to mitigate this, and I mean a bunch of things. People on V8 team did. People on the JavaScriptCore
team did, for WebKit. People at Microsoft did. Tons of the browser vendors worked on trying to just change the JIT, so that you didn't have
enough information, and, ultimately, nothing worked. Everything would end up failing on some interesting,
exciting code pattern, so that's why they're moving
towards an isolation model. - And Linux has, you
take the browser example, but not a browser, but
anything involving JITs, you have similar kind of abuse. There's something in Linux I like to call a Spectre accelerator, BPF. - Oh, BPF. - So people are like, "Oh
put BPF programs everywhere. "These are little code that I give you "that you'll run inside the
kernel very handily for me, "that's safe, because it's bi-compiled "and it's definitely safe, so thanks. "We checked it, we made sure
it didn't do anything bad." Anyway, I call BPF a Spectre accelerator, because it's just wonderful. You hand me that, I run it,
and I leak results, it's great. - [Man] Thanks. - [Matt] Good one. We'll take a question
over on the, that side. - Stand.
- I would like to know, what is the impact of
Spectre family of problems on the cloud providers? Should we expect some
continuous VM reboots happening from now on, forever,
until they find mitigation? (audience laughs)
And another thing is, should we expect some more
legalese in the agreements, saying, "Oh your data can
be breached, so sorry." - I don't really think you
should expect this stuff. Here's the thing. The cloud vendors, their
fundamental business model is protecting your data. They're going to go to the mat to try and beat these
kinds of vulnerabilities and find ways to protect your data, and all the cloud vendors are
doing a phenomenal job here. I do mean, literally,
every single cloud vendor has been the most impressive
response I've seen to these kinds of issues. The one which has the
most impact has been L1TI, and, if you look at any
of the cloud vendors, they have documentation
about what their changing in order to mitigate L1TI. That's the most visible
change that we've seen. I don't wanna try and repeat it here. I don't have it right in front of me, but all the cloud vendors, you can go in, find their documentation about it. But it's not gonna be constant reboots, it's not gonna be somethin' like that. The only thing you do wanna realize is we are seeing a stream of vulnerabilities. I mean, related to
operating systems and cloud, but related to all of Spectre. You need to have a good policy for updating your kernel in
your cloud VM, right, which is going to require a
reboot on a regular basis, okay, and, if you don't
have a plan in place, that's going to be a problem. There's a whole talk
about, in an earlier talk, from one of the Scribd people, Patricia, I think she might still be here, about how you have to have a plan to roll these fixes out. So all of the operating
system and cloud vendors are going to have the fixes in place. That doesn't help, if
you can't roll them out, so that's what I would really focus on. - Yeah, I agree with that. I mean, ultimately,
vulnerabilities are not a new issue that cloud providers have to deal with, so it's already been the case
that we have to response. These vulnerabilities may
be different in nature, from the the other types
we've always had to deal with, but that doesn't really
change the fact that you've gotta have your response
planned, your capabilities, and the ability to actually go and control and mitigate for your customers. - I don't run a cloud, so a quick one. I have a bit of buyer's remorse, I kind of wish we did, but... In the last year,
working with these teams, the thing that I've become convinced of is if I'm running an
environment, in many ways, I'm gonna trust my data more
in a cloud than an environment, because I've seen some
very professional people, these companies employ
some of the brightest folks in the industry, these guys included, and I would trust my
data more there, frankly, than I would, in some
cases, in an environment with a system with firmware that hasn't been updated in ten years. Just because it's in the
cloud doesn't mean it's bad. In fact, it could be very good. - [Matt] Thank you for your question. Over here on stage left. - I have asked this question
in the previous talk. To me it looks like this
is a architecture failure on the processors, the whole, "I will try to figure out what's going "to happen in the future, "but I don't have enough information," seems like a broken thing, so is there a way of
fixing the architecture, instead of trying to put bandaids on it? - Can I start this one?
- Yeah, please start. - It's one of my favorite topics. Anything involving
architecture, I'll explain it. - That's why I had him.
- Yeah, yeah, yeah. You see, someone asked
before about how big, how many instructions
can you have in flight, as well on that, really
depends, it varies heavily. But look, hands up here, if a year ago, someone had come to you and said, "I'd like to make your
computer much slower, "but I'm gonna promise you
it's gonna be more secure," would anyone have done that? - And they won't tell
you how much more secure, but somewhat more secure.
- Right. You know, more secure, but it's gonna get, you know, 30, 50%,
hundreds of percent slower. None of you would have taken it, right? Every year, we buy processors, or every couple of years, or whatever, and the processor companies have been beating each other over the heads, for the past few decades,
around spec numbers. Now I hate spec, I think
spec is a stupid thing. - What's spec? - Specant, sorry. - What's specant? I'm making you explain things. - Ah, okay.
(audience laughs) - Doing my job. - Industry standard bench marks, so I'll just leave it at that. There are some, quote unquote,
industry standard benchmarks that people use, they're very contrived, but processor vendors will beat each other over the head using them, and every year, you have to get, you
know, X percent faster at running these contrived benchmarks, and, in order to do that,
you've gotta do something. You can't just get faster, so speculation has been the magic wand that they've used for a very long time in order to make these
machines faster and faster, and no consumer, until
fairly recently, has said, "How did you do that?" It's really been this world of us guys, in the software space
traditionally, kind of ignoring everything that's been going
on in the hardware space, except we just told
them, "We hate you guys, "we don't wanna ever talk to you, "and we need our computer to get faster. "What's wrong with you?" (audience laughs) So this has been a
fabulous opportunity for us to have these conversations, finally, and start communicating
more, and also saying, "I'd like my machine to be faster, but I'd also like to prioritize security," and, now that we tell them that, now they can legitimately
prioritize that trade-off, I think you you will
see interesting results. - But I don't think we know
what they're gonna be yet. I think we're really
still trying to figure out how to make processors more secure. My call to action was to lobby
with the processor vendors to invest in this space, but right now, that's essentially research. It's not even in development. That's where we have to start. - [Matt] Thanks. - [Man] Okay. - [Matt] Thank you very much. Over here, please. - All right, so far we've learned that, if we've got software
that handles confidential, valuable data, we should
run it in the cloud, rather than in the wild west, I get that, but I wanna take that one step further and see how you respond to this. Imagine, here's the CTO of a
medium size software company, and he's learning about this stuff, and he asks about this application, and they say, "Well that one's all right, "because it's written in Java, "and the Java virtual machine has been "updated to have mitigations in it." And then he asks about
this other application, and they say, "Well that's okay, "because it runs in a .Net environment. "It's a C# application, and
it's fine, because Microsoft "has got stuff into the .Net execution," whatever it's called. "And what about this one over here?" "Well we've got big problems there." "Why is that?" "It's written in C++, so
there's no virtual machine "sitting between our
code and the machine," which means that, instead of relying on all
the experts at Microsoft and other places to fix this for us, we're kind of on our own here. Why would the CTO or president,
or whatever executive of any software company ever want to have an application that
handles sensitive data, written in C++, or any other
native language ever again? - That's a great question.
(someone applauds) - Fortunately I do think there's a good answer to it as well. You talk about the virtual machine, and how you have experts
working on this virtual machine, or this environment,
help to make it secure. I think it's a mistake to think you don't have an analogous situation in C++. How many folks here have written their own C++ compiler, that they
use for all their software? (many laughing) Right?
- Maybe about two hands. - But that's my job, in many ways. - But now you're telling me I
have to do a binary release. - Well hold on, but
like no one has, right? Everyone's relying on their
compiler as their tool chains to, essentially, provide
that same kind of expertise. Now, there is still an
update problem, right? You're going to have to do an update, but, again, you have to have a plan for updating for security generally. You also are going to have
security bugs in your code that you're going to have to update with. You're also going to have bugs in your VM, that you're going to have
to update the VM with. Okay, it's not clear that updating the VM, versus updating the application, is going to be a dramatically
different experience. What we've found, at least at Google, where we use a lot of Java code, we also use a lot of C++ code, is it the difference in complexity
of updating these things, that is updating a compiler
and doing a binary release, versus updating a VM, that's running all of our Java
services, is very comparable. In many cases, we can't
do the VM update globally. We actually have to let applications pick the update when they're ready, and that's essentially the
same as a binary update. - [Man] Yeah, but there's
a huge important thing, that I believe that answer misses. You work for Google, which is essentially a
form of SaaS provider. I happen to program on a
SaaS application as well. Other parts of my company's products are delivered to our clients. Those parts of those
companies are supporting releases that were done
five to ten years ago, because the clients have
not taken the upgrades. - Absolutely. - [Man] And I think, maybe,
where your answer is going, and I would tend to
agree with this, is that, if you're a software company, you better start delivering
your software on the cloud, or you're never gonna be
able to solve these problems. - I wanna make a different comment. It's not about delivering
the software on the cloud, it's about delivering updates. Spectre is not interesting here. If you have five year old software, it has vulnerabilities in it. It has five years of
vulnerabilities in it. You need an update plan,
and that's not gonna change because of speculative execution. Now there is some challenges here. The interesting thing
is, we have more tools in our tool chains right
now, to mitigate Spectre, than we do in the JVM, that I'm aware of. I don't know about .Net, but I think, actually if anything, C++ is at the leading edge here, and some of that's because of the risk. The risk is, in some ways, greatest when you have native code, but it's also just because
experts are working to make sure that the
environment is prepared, and, unfortunately, it's all on you, to then make sure that
your update strategy is in place and followed. One way is to move it to the cloud, but there are other ways
that are just as fine. The key is to update. - To build on your point there, and I agree with everything you
just said, Chandler, really. The point about deployed
binaries out there, right? I work, primarily, in
traditional enterprise, and Matt has a lot of experience
with this as well, right? So I'll let you speak in a moment to that. When technologies like
Retpoline's came along We have, to them, said,
"Well that's great, " if you can rebuild the whole world." I love Google so much. I wish I had some of the fun
toys they have and so on, and I said, "How do we
make that work for us," because we've got all these
existing binaries out there, so sometimes the answer
is a little bit different, and we have to take
more steps to get there, if we don't control our
entire destiny ourselves, but we can take steps. You know, why do you wanna run native code as opposed to Java? Very simply, for performance, for the same reason that
everyone has always wanted to. I mean, it'd be very sad
if the industry said, "We're gonna use more of these runtimes "as an answer to deal
with security issues." This is one set of security problems, where we have some unique challenges that might require some
people to ship new binaries, but there are tons of
vulnerabilities out there every day that require people to ship new software, or make tweaks to their environment, or update their CPU microcode,
or, you know, whatever. It's only gonna be a
couple of specific cases where you might have to
release a software update. I don't see this fundamentally changing the way the entire industry
operates, other than, hopefully, we all get
better at releasing updates. - Yeah, and the element
that I would add to this is that the calculus of evaluating
which, like the language, in which the application
that your picking uses, Spectre and the other issues don't. It's just a new wrinkle
in that existing equation that we already had out there to evaluate which is the most suitable language for the scenario in which you're using, so, if a big part of
your calculus was safety, in the application you're looking for, you might not wanna use C++, right? You might not wanna go that route, and Spectre adds a new dimension to that, and it applies kind of
horizontally across all of this, so that'd be one way
that I'd look at it too, but the update story
is another huge thing, How you actually control for updates. - [Man] Let me just add, and
I appreciate those answers, and they're very helpful, however, let me just cite one interesting, kind of historical, counter example. For many years, large
numbers of corporations, in the business world, preferred to use Microsoft
windows than Linux, because they were afraid of safety issues. Now that was a period, during which, the number of vulnerabilities that were affecting Microsoft Windows was probably two orders of magnitude greater than those that were affecting Linux. In other words, this isn't
always about reality. Sometimes it's about perceptions, and I just hope that we
can publicize the fact that C++ is in the forefront,
and it'll stay there. - Absolutely, I mean, that's why I wanted to come here and give the talk. - Thank you for the question. We'll go over to the left, please. - I have a pretty good
handle on x86 mitigations, but ARM has similar problems. They also do speculative execution. I see that we're having microcode changes and hardware changes for, like Intel CPUS, but what's ARM's story right now? - Do you want me to? (chuckles) - Please. - I have the distinct
pleasure of dealing with this for I think seven, no, nine
different microarchitectures, across a number of
different product families. The total set that we dealt with, on the Red Hat side, was very small. It was x86, Intel, and A and D. It was all of the ARM server vendors, was IBM Power and IBM Z,
so it was a very small set, and I certainly enjoyed,
over the holidays last year, testing mainframe assembly code. That was something I was looking
forward to all year long. - Poor life choices,
Bro, poor life choices. - Yeah, and we got to
December, and I'm like, "Oh man, this is great, that's
all I ever wanted to do." (some audience laughing) - I'll walk you through just
a very quick summary of those. Different architectures have
different knobs and dials. I'll try to explain the terms, right. x86 has a fundamental design choice, where, a number of years
ago, they had some problems, and, as a result, they introduced this
concept called microcode, which basically means
you can get this blob, that you load, assigned blob,
you cant's see inside it, but it will change the
CPU's configuration, and it will change how
certain operations execute. It can also change what
I call chicken bits, inside the processor,
it'll turn things off, so, when you build an x86 processor today, there's about 10,000
chicken bits in there, and that's because the engineers say, "Man, we're the best, we never screw up, "but just in case we did." (laughs) "This little thing I've been
working on for the last year, "I know I'm perfect, but I
might have gotten it wrong, "and my job's not worth it, "so I'm gonna put all
these knobs and dials, "and let you turn these things off." There's about 10,000 of them
in average x86 processor alone, where you can turn all kinds
of very specific things off, so microcode can do that,
in addition to changing exactly how certain instructions work. Not everything. But that's what x86 can do. That's how you implement things like IBRS and IBPB and so on. When it comes to ARM, they
have trusted firmware, so they have something that runs at a lower level than
the operating system, and they can provide new interfaces that the OS can call
into in secure firmware. We have IBRS on x86 to effect
branch predictor behavior. We have similar interfaces
on ARM that we can call into in trusted firmware to do similar stuff. On Power and Z, we have
something called millicode, because IBM invented it, because IBM, and it does very similar
things to microcode, so, if you're running
an IBM mainframe system, you probably already got a call from IBM. In fact, it probably,
this is a true story. Apparently, mainframes,
when they have a problem, they actually, automatically,
put service calls in, 'cause why not, right? So it probably already called home, and they already sent you
an engineer to fix this. - Wait, mainframe can make phone calls? (audience laughs)
- Yeah. This is why I'm convinced
the Skynet will be a Z, because, when you get one, they
put a phone line in as well, so it literally can call and say, "I've got a problem,
I need you to fix me," so I'm pretty sure that they already called all of their customers and said, "Hey, we'd like you to
deploy all these updates," so, I mean, they've
been fabulous with that. I know we sneakily
deployed a mainframe update over the holidays, that none of our engineers
were aware of, to address this. Then for Power it's very
similar, they have millicode. You will find it's a bit different, but it's very similar
across the architectures. - [Man] Are there any
hardware mitigations yet, because Intel's starting. You're starting to see a few
patches in hardware with Intel. - I'd say very similar. It's the start. I know that ARM has some
initial firmware updates that expose similar interfaces, to the ones that Intel's
exposing, or that IBM's exposing. I do think that it's
early days on hardware. You have to realize that
fixing this in hardware, one of the reasons we did
so much in software is, because fixing this in
hardware has very high latency, and it's very challenging to do. Some of the things are easy, like when it was a CPU but,
and there's a chicken bit, or something like that, it's much easier, but, when it's something
much more fundamental, it's just really hard to
crack the hardware updates, so I don't think you should
expect those hardware updates to roll out really fast, but they're definitely working on them. - Similarly, like the guidance from ARM for conditional branch
misprediction, which was, I think, what Chandler mostly
talked about, in his talk, is still around the concept of, "Please add data dependencies
and serializing instructions "to the code paths that
are susceptible to this." It's not a categorical thing. - [Man] Okay, thank you. - Thank you for the question. I've seen the documentary film, War Games. I'm not surprised at all that there's a phone
line right into the IBM. (audience laughs) - You'd think maybe, after watching that, they would have taken it out. - Oh.
- To be clear, I love IBM, and I'm having a bit of fun
there, but I actually think the way they handled this was amazing. - It really is impressive.
- Yeah. - Look, I make fun of the phone line, but it is really impressive. - Comes in a really expensive bag. - Just for the recording, we
had a really good experience. - (laughs) Okay, we'll take a question
from he right, please. - The impression I got was that the mitigation in software,
for the most part, is about isolating as much as possible, isolating code that handles passwords, code that handles
confidential information, code that runs untrusted other code, but I'm not actually
sure how'd you do that. Suppose I have an application that needs to create a SH link to something else. Somewhere along the way,
the programmer's gonna have to type in the password
to get their SH key in. SH key will be read
into memory, decrypted, re-encrypted and sent over the wire. What would need to be
done in that program, that, you know, is all
running in one memory space, to prevent that password
from being leaked. - There are a couple of things here that are kind of gettin' tied up together. I'm gonna try and separate them out. First thing is passwords. Passwords aren't that scary, because passwords can be very ephemeral. They don't stay in memory
for a very long time. Using these kinds of attacks
would be really challenging. You'd have to time it so carefully. I mean, maybe. I know that L1TF was
able to be used for that, but most of these have
much lower bandwidths, and are much harder to use in that way. I think the key data is
the interesting case here, but it's important to think about how the cryptography works. It's not sending the
private key anywhere, okay, and it doesn't need for
the user interaction with the private key
to actually be exposed. You could have a separate system that handles all of the
private key operations, all of the operations that
really involve a private key, and has a very controlled, very rigorously enforced interface, then some other trusted component, and then only that component gets actually exposed user interactions,
and that component can kind of isolate damage
away from private key material. That's the kind of cryptographic
system that I'm suggesting. You look at something like a TLS1.3, which I'm not a super expert on. You may have to take over at some point, but the idea is that you
can use ephemeral keys that are only used for
symmetric encryption of a single session, right,
they don't keep getting used, and you have to create
them with a long-lived key, but you can off-load that
creation if you want. You can separate the active
process of encrypting data from the thing that
creates a one-time use key. Now, the thing that's exposed to attacks has a very short shelf
life, has very low value. The thing that has high value never got to interact with the attacker, and I think that kind of separation is what you're looking for,
but I also want to emphasize there are going to be places where you cannot build that level of separation, and that's where you see people working to deploy kind of manual
mitigations of variant one, 'cause they need at least one
piece of their infrastructure to be hardened, because it
both has to have a secret and interact with untrusted entities. - Yeah, I'm by no means
a cryptography expert, but I'll give you a
concrete example of how address based isolation can
work concretely in practice. Windows has a technology called Virtualization-based Security, and basically it's leveraging
hardware virtualization to allow you to create a separate trusted execution context in which your normal operating system
can't read or write memory that executes in this other
separate, virtualized context. That's the easiest way to think about it, and one of the ways that
we've actually applied that is a technology called Credential Guard. It used to be the case, on Windows, that we have a trusted
process called LSASS. It's the local security authority. It is what contains the thing that implements challenge response for communicating with other machines on the network, for NTLM and what not, and it used to be the case that people would try to poke in there, to actually go extract your caches, so they could impersonate
you on the network, and do things of that sort. Instead, what we've done is, we've moved that challenge
response protocol into one of these isolated contexts, such that, the secrets
that are used in there, to complete that challenge response, aren't actually available
to the normal world. So, if you extend that concept to other types of key exchange protocols, it's an example of applying
address-based isolation, where you're keeping your
secrets in a separate place, that isn't normally
available to everything else, so that's just one concrete
example of how you could do it. - Did that actually answer a question? - [Man] Yeah, I think it did. The impression I get, also, is that this is something that there's
a silver lining to this. The technology to, and
the interfaces to do these kind of isolation that
are going to get easier to use and more taught, they're
gonna be taught more commonly, because you're gonna have to
write your software this way, and it's gonna help with all
kinds of vulnerabilities, not just the Spectre
family of vulnerabilities. - That's right, if anything in security, outside of even Spectre,
and all the other issues, we've already been moving into this world of pervasive isolation, where we have more granular compartmentalization
and isolation of components, and this is yet another good
reason to move to that model. - And to Chandler's point
earlier in his talk, about, well he didn't say
it yet, but re-keying. So, if you have a long-lived session, most of these protocols support re-keying. Very few people use that. - It's really rare right now, but this is, essentially we've got to push on the cryptograph community, to really embrace these
kinds of techniques, and to prioritize them when
they're building systems. - Thank you for the question. We're starting to run out
of time, unfortunately, so, if we can try and get this done. I wanna let everyone to have a chance to answer there question. - The three of us have to
actually be like brief, now you're saying. - I'm afraid so, yeah. I should have probably told
you this a bit earlier. - You should have picked
a different panel. - Over on this side, a quick question, and exclude what we've had and divide , and we'll see if we can have a turbo three minute back and forth. - Sound good.
- Go. - Are these mitigations that we're getting gonna be opt-in or opt-out? I mean, they won't be by default. We're gonna be paying for
these along somewhere. - If they're fast, they'll be defaulted. If they're not, they'll be opt-in. - [Man] Thank you. - Oh, excellent.
(some laughing) Anyone, no, right, this side. - One of the things that
I've been noticing is that some of the mitigations
that you've shown were almost as contrived
as the original one with the vulnerabilities. Like the Retpoline, that
is pretty crazy, right? Even the LFENCE, the fact that the LFENCE blocks the branch prediction is just a side effect, that is not the original
intent of the fence. It's a full fledged... - It's a retroactively
documented as doing that now. (audience laughs) - It's in the spec now. - So they've added it to the spec. It's also more fundamental
to how LFENCE works. On Intel processors,
LFENCE has always been what they call dispatch serializing, so it actually does have strict semantics. They didn't document it. Now they do; A and D is following suit. - [Man] My question was, actually, at the moment, if the hardware vendors are to fix all of this on their own, this is going to be very hard
for the hardware vendors, or it will have immense
performance penalty. What I could imagine happening is that the hardware vendors say, "Okay, we will give
you a special contract. "if you want the speculative execution, "get these special opt
codes to put in your code," then similar to how memory
model works, but differently. It'd keep with the contract, then we still can guarantee
that nothing bad happens. Is that the direction that
anyone is currently working? - If you would, answer please. - We won't go into the details here today, but certainly people have though about it. Sorry, you're gonna have to suffer. Other architectures in the past tried having speculative instructions, so I'll say one word,
and I don't want anyone to take anything bad, 'cause
it was a good architecture. It didn't work out, but Itanium did implement
speculative instructions, and that required you to
modify a lot of software. If you tell people, "You have to modify your
code to do speculation," then they won't do it. - Cool, thank you. All right, here on this side, please. - Since there's no mitigation, and everybody knows about Spectre, how come they won't send a viralist? - It's so hard. - I'll give you an analogy for this one. Go back 20 years. 20 years ago, some people
knew about buffer overruns, but not very many people, and then, more and more people started to learn about them, and understand them, and get better at thinking about how you can actually
leverage a buffer overrun to, "Oh, I can hijack
the instruction pointer," and, "Oh, I can do and do this and that," and the same sort of evolution happened for other types of
memory corruption issues such that now we're at a place where you look at a modern
memory corruption exploit, and they're phenomenal. They're works of art, in
terms of how people do this, so think of speculative execution as being where buffer overruns
were 20 years ago, right? People just don't understand it yet, and it's gonna take time. - But people are smart,
and they'll work out a way. - They will, and there's also
lower hanging fruit right now. - Lots of lower hanging fruit. - Thank you. Over on this side, please, - Hello, I would first want to thank you for all the hard work and
money that you are saving me. I know this is crazy for a minute, because, yeah, thank you because you work for all of us, actually. The question itself,
from the presentation, and understood there, that
Spectre kind of a combination of the speculative execution
and the side channel that can leverage to
actually get information. Is it possible to better this issue from the other side as
well, so the side channels? Yeah, this is a very long. You'd have to have a
very long answer to this, but you can break down
these speculative issues into the speculation primitive, the thing that allows you to speculate, and the disclosure primitive, and the channel through which
you disclose information, and there are mitigations on either side of that equation that you can pursue. - I would just add, again,
there's a very long answer there. Some great videos out
there explaining that, but we focused a lot,
not necessarily channel, but the industry's focused
a lot on one side channel, cache based side channels. Let's not make the mistake of focusing only on the ones that we see. New ones will be found and, you know, it's a general class of
problem to think about. - The brief thing that I wanna say is I've taken a particular
stance in the response here to not focus on side channels, and the reason is, we don't think we will ever finish finding new ones. Whereas, we think we can actually attack the speculative execution problem in a much more tractable way. There are so many
microarchitectural states that are available to
store information in. - At the risk of...
- Go on Miller. One more thing. Another way to think about this, just adding on to what Chandler said is, with any type of vulnerability, you ideally wanna mitigate
it at the root cause, not further down the chain, and, if you go to the side channels,
the communication channels, that's further down the chain, and you might get yourself into trouble. - Okay, thank you. - You're not gonna turn my cache off and my branch predictor off then? - Yeah, they're definitely secure. (laughing) - Okay, very quickly, very, very quickly. - Quickly, most computers
in the world are phones. You never talk with phones
as you talk to the servers, and how you beg them, but
phones have operations that are running parallel
on the same computer. - Haiku answer this. - The phone vendors are looking at this. (some laughing)
- That's good. - Last one. - Is there any sense how
widely this is actually exploited into the whole world? - Nope. - Even better than a haiku answer, okay? Well thank you very much
to the panel here for that. Thank you all for participating. (audience applauds)
Yes, thank you.
So cppcon is slowly becoming like any other "tech" conferences. Who is so sensitive that required to block comments on this video? Why not just block all comments and likes on all videos if you are afraid someone will not like what some people might say?