[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:18.01,Default,,0000,0000,0000,,{\i1}35C3 preroll music{\i0}
Dialogue: 0,0:00:18.01,0:00:29.24,Default,,0000,0000,0000,,Herald angel: OK. Our next speaker will be\Ntrying to tame the chaos. Peter Sewell
Dialogue: 0,0:00:29.24,0:00:34.12,Default,,0000,0000,0000,,from the University of Cambridge. A warm\Nround of applause please.
Dialogue: 0,0:00:34.12,0:00:37.91,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:00:37.91,0:00:48.74,Default,,0000,0000,0000,,Sewell: Thank you! Okay. So here we are.\NC3 again with a program full of
Dialogue: 0,0:00:48.74,0:00:56.71,Default,,0000,0000,0000,,fascinating and exciting and cool stuff.\NAnd if we look just at the security talks
Dialogue: 0,0:00:56.71,0:00:59.94,Default,,0000,0000,0000,,all manner of interesting things. I'm\Ngoing to go to a lot to these. You should
Dialogue: 0,0:00:59.94,0:01:06.83,Default,,0000,0000,0000,,too. Let's see though if we read some of\Nthe titles: exploiting kernel memory
Dialogue: 0,0:01:06.83,0:01:18.75,Default,,0000,0000,0000,,corruptions, attacking end to end e-mail\Nencryption. What else have we got: modern
Dialogue: 0,0:01:18.75,0:01:31.55,Default,,0000,0000,0000,,Windows user space exploitation,\Ncompromising online accounts. OK so a lot
Dialogue: 0,0:01:31.55,0:01:36.13,Default,,0000,0000,0000,,of these talks, as usual, they're\Nexplaining to us that our computers,
Dialogue: 0,0:01:36.13,0:01:42.95,Default,,0000,0000,0000,,they're not doing what we would like and\Nthis as usual is the merest tip of a tiny
Dialogue: 0,0:01:42.95,0:01:48.97,Default,,0000,0000,0000,,iceberg, alright. We have a hundreds of\Nthousands of known vulnerabilities and
Dialogue: 0,0:01:48.97,0:01:53.28,Default,,0000,0000,0000,,many unknown vulnerabilities. Let me do it\Na bit dark here, but let me try some
Dialogue: 0,0:01:53.28,0:01:59.49,Default,,0000,0000,0000,,audience participation. How many of you\Nhave in the last year written at least a
Dialogue: 0,0:01:59.49,0:02:09.02,Default,,0000,0000,0000,,hundred lines of code? And of those people\Nkeep your hands up if you are completely
Dialogue: 0,0:02:09.02,0:02:17.55,Default,,0000,0000,0000,,confident that code does the right thing.\N{\i1}laughter{\i0} I would like to talk to you
Dialogue: 0,0:02:17.55,0:02:23.20,Default,,0000,0000,0000,,later {\i1}laughter{\i0} and so would the people\Nin the self driving car that you're
Dialogue: 0,0:02:23.20,0:02:30.79,Default,,0000,0000,0000,,probably engineering. So, so how many\Nunknown vulnerabilities then. Well you can
Dialogue: 0,0:02:30.79,0:02:39.16,Default,,0000,0000,0000,,take what's in your mind right now and\Nmultiply it by - oh, this doesnt work very
Dialogue: 0,0:02:39.16,0:02:48.92,Default,,0000,0000,0000,,well. No. No, no. Computers, they do the\Nwrong thing again and again and again.
Dialogue: 0,0:02:48.92,0:02:54.42,Default,,0000,0000,0000,,{\i1}laughter and some applause{\i0} We can\Nmultiply by this estimate of about a 100
Dialogue: 0,0:02:54.42,0:03:00.63,Default,,0000,0000,0000,,billion lines of new code each year. So if\Nwe take all of this: these talks, these
Dialogue: 0,0:03:00.63,0:03:05.90,Default,,0000,0000,0000,,numbers, these should make us not happy\Nand excited, these should make us sad,
Dialogue: 0,0:03:05.90,0:03:16.07,Default,,0000,0000,0000,,very sad and frankly rather scared of what\Nis going on in the world. So what can we
Dialogue: 0,0:03:16.07,0:03:25.61,Default,,0000,0000,0000,,do? We can, option one, give up using\Ncomputers altogether. {\i1}applause{\i0} In most
Dialogue: 0,0:03:25.61,0:03:29.64,Default,,0000,0000,0000,,audiences this will be a hard sell but\Nhere I'm sure you're all happy to just
Dialogue: 0,0:03:29.64,0:03:40.18,Default,,0000,0000,0000,,turn them off now. Or we can throw up our\Nhands in the air and collapse in some kind
Dialogue: 0,0:03:40.18,0:03:54.83,Default,,0000,0000,0000,,of pit of despair. Well, maybe, maybe not.\NMy task today is to give you a tiny
Dialogue: 0,0:03:54.83,0:04:00.05,Default,,0000,0000,0000,,smidgen, a very tall, a very small amount\Nof hope that it may be possible to do
Dialogue: 0,0:04:00.05,0:04:04.10,Default,,0000,0000,0000,,slightly better. But if we want to do\Nbetter we first have to understand why
Dialogue: 0,0:04:04.10,0:04:10.56,Default,,0000,0000,0000,,things are so bad and if we look at our\Naeronautical engineering colleagues for
Dialogue: 0,0:04:10.56,0:04:15.74,Default,,0000,0000,0000,,example, they can make planes which very\Nrarely fall out of the sky. Why is it that
Dialogue: 0,0:04:15.74,0:04:22.88,Default,,0000,0000,0000,,they can do that and we are so shit at\Nmaking computers? Well, I'm going to reuse
Dialogue: 0,0:04:22.88,0:04:27.97,Default,,0000,0000,0000,,a picture that I used at 31C3, which is\Nstill the best description I can find of
Dialogue: 0,0:04:27.97,0:04:35.99,Default,,0000,0000,0000,,the stack of hardware and software that we\Nlive above. Here we go. It's, there's so
Dialogue: 0,0:04:35.99,0:04:40.16,Default,,0000,0000,0000,,much information in this, it's just ace.\NSo we see down here all of this
Dialogue: 0,0:04:40.16,0:04:45.43,Default,,0000,0000,0000,,transparent silicon, it's the hardware we\Nlive above. We see a stack of phases of a
Dialogue: 0,0:04:45.43,0:04:51.24,Default,,0000,0000,0000,,C compiler, we see all kinds of other\Nother bits and pieces. There might be a
Dialogue: 0,0:04:51.24,0:04:58.87,Default,,0000,0000,0000,,slightly hostile wireless environment in\Nthis room for some reason. If we look at
Dialogue: 0,0:04:58.87,0:05:03.23,Default,,0000,0000,0000,,this and think about the root causes for\Nwhy our systems are so bad we can see
Dialogue: 0,0:05:03.23,0:05:07.89,Default,,0000,0000,0000,,terrible things. So the first is,\Nobviously there's a lot of legacy
Dialogue: 0,0:05:07.89,0:05:12.81,Default,,0000,0000,0000,,complexity that we're really stuck with,\Nalright. If you pull out one of those
Dialogue: 0,0:05:12.81,0:05:16.24,Default,,0000,0000,0000,,pieces from the middle and try and replace\Nit with something which is not of exactly
Dialogue: 0,0:05:16.24,0:05:21.35,Default,,0000,0000,0000,,the same shape the whole pile will\Ncollapse. So we somehow need to find an
Dialogue: 0,0:05:21.35,0:05:27.97,Default,,0000,0000,0000,,incremental path to a better world. And\Nthen, this is the most fundamental reason
Dialogue: 0,0:05:27.97,0:05:33.22,Default,,0000,0000,0000,,that these are not like aeroplanes, these\Nsystems are discrete not continuous. If
Dialogue: 0,0:05:33.22,0:05:38.29,Default,,0000,0000,0000,,you take an honest good I made out of a\Npiece of steel and you push on it a little
Dialogue: 0,0:05:38.29,0:05:44.27,Default,,0000,0000,0000,,bit it moves a little bit, basically in\Nproportion. If it is 1 percent too strong,
Dialogue: 0,0:05:44.27,0:05:50.09,Default,,0000,0000,0000,,1 percent to weak, basically it doesn't\Nmatter. But in these things one line of
Dialogue: 0,0:05:50.09,0:05:56.49,Default,,0000,0000,0000,,code can mean you're open to a\Ncatastrophic exploit and one line in many,
Dialogue: 0,0:05:56.49,0:06:05.97,Default,,0000,0000,0000,,many million. OK. And next thing... this\Nreally doesn't work. They're very
Dialogue: 0,0:06:05.97,0:06:11.38,Default,,0000,0000,0000,,complicated. But the scary thing is not\Nthe static complexity of those lines of
Dialogue: 0,0:06:11.38,0:06:15.08,Default,,0000,0000,0000,,code and the number of components although\Nthat's pretty intimidating the really
Dialogue: 0,0:06:15.08,0:06:21.11,Default,,0000,0000,0000,,scary thing is that the exponential number\Nof states and execution paths. So these
Dialogue: 0,0:06:21.11,0:06:26.14,Default,,0000,0000,0000,,two together they mean that the testing\Nthat we rely on testing is the only way we
Dialogue: 0,0:06:26.14,0:06:30.71,Default,,0000,0000,0000,,have to build systems which are not\Ninstantly broken. Testing can never save
Dialogue: 0,0:06:30.71,0:06:40.55,Default,,0000,0000,0000,,us from these exploitable errors. And that\Nmeans ultimately we need to do proof.
Dialogue: 0,0:06:40.55,0:06:45.61,Default,,0000,0000,0000,,Honest machine checked mathematical proof.\NAnd this also tells us that we need to
Dialogue: 0,0:06:45.61,0:06:51.29,Default,,0000,0000,0000,,arrange for our systems to be secure for\Nsimple reasons that do not depend on the
Dialogue: 0,0:06:51.29,0:06:57.18,Default,,0000,0000,0000,,correctness of all of those hundred\Nbillion lines of code. Then another thing
Dialogue: 0,0:06:57.18,0:07:03.36,Default,,0000,0000,0000,,that we have here. All these interfaces:\Nthe architecture interface, the C language
Dialogue: 0,0:07:03.36,0:07:10.65,Default,,0000,0000,0000,,interface, the sockets API interface, the\NTCP interface. All of these we rely on to
Dialogue: 0,0:07:10.65,0:07:17.50,Default,,0000,0000,0000,,let different parts of the system be\Nengineered by different organizations. But
Dialogue: 0,0:07:17.50,0:07:24.87,Default,,0000,0000,0000,,they're all really badly described and\Nbadly defined. So what you find is, for
Dialogue: 0,0:07:24.87,0:07:30.13,Default,,0000,0000,0000,,each of these, typically a prose book\Nvarying in thickness between about that
Dialogue: 0,0:07:30.13,0:07:36.91,Default,,0000,0000,0000,,and about that, full of text. Well, we\Nstill rely on testing - limited though it
Dialogue: 0,0:07:36.91,0:07:44.00,Default,,0000,0000,0000,,is - but you can never test anything\Nagainst those books. So we need instead
Dialogue: 0,0:07:44.00,0:07:48.94,Default,,0000,0000,0000,,interface descriptions, definitions,\Nspecifications, that are more rigorous,
Dialogue: 0,0:07:48.94,0:07:54.42,Default,,0000,0000,0000,,mathematically rigorous and that are\Nexecutable - not in the normal sense of
Dialogue: 0,0:07:54.42,0:07:58.94,Default,,0000,0000,0000,,executable as an implementation but\Nexecutable as a test oracle. So you can
Dialogue: 0,0:07:58.94,0:08:03.88,Default,,0000,0000,0000,,compute whether some observed behaviour is\Nallowed or not and not have to read the
Dialogue: 0,0:08:03.88,0:08:07.70,Default,,0000,0000,0000,,book and argue on the Internet. And we\Nalso need interface definitions that
Dialogue: 0,0:08:07.70,0:08:19.82,Default,,0000,0000,0000,,support this proof that we need. And then\Nall of this stuff was made up in the 1970s
Dialogue: 0,0:08:19.82,0:08:25.64,Default,,0000,0000,0000,,or the sixties and in the 70s and the 60s\Nthe world was a happy place and people
Dialogue: 0,0:08:25.64,0:08:32.07,Default,,0000,0000,0000,,walked around with flowers in their hair\Nand nothing bad ever happened. And that is
Dialogue: 0,0:08:32.07,0:08:36.34,Default,,0000,0000,0000,,no longer the case. And so we need\Ndefensive design, but we need defensive
Dialogue: 0,0:08:36.34,0:08:41.15,Default,,0000,0000,0000,,design that is somehow compatible or can\Nbe made enough compatible with this legacy
Dialogue: 0,0:08:41.15,0:08:46.88,Default,,0000,0000,0000,,investment. That's quite hard. And then -\NI can't say very much about this, but we
Dialogue: 0,0:08:46.88,0:08:50.36,Default,,0000,0000,0000,,have at the moment very bad incentives,\Nbecause we have a very strong incentive to
Dialogue: 0,0:08:50.36,0:08:55.42,Default,,0000,0000,0000,,make things that are more complex than we\Ncan possibly handle or understand. We make
Dialogue: 0,0:08:55.42,0:09:00.41,Default,,0000,0000,0000,,things, we add features, we make a thing\Nwhich is just about shippable and then we
Dialogue: 0,0:09:00.41,0:09:06.55,Default,,0000,0000,0000,,ship it. And then we go on to the next\Nthing. So we need economic and legal
Dialogue: 0,0:09:06.55,0:09:11.30,Default,,0000,0000,0000,,incentives for simplicity and for security\Nthat we do not yet have. But it's hard to
Dialogue: 0,0:09:11.30,0:09:17.11,Default,,0000,0000,0000,,talk about those until we have the\Ntechnical means to react to those
Dialogue: 0,0:09:17.11,0:09:21.98,Default,,0000,0000,0000,,incentives. OK, so what I'm going to do\Nnow, I'm going to talk about two of these
Dialogue: 0,0:09:21.98,0:09:26.23,Default,,0000,0000,0000,,interfaces, the architect interface and\Nthe C language interface, and see what we
Dialogue: 0,0:09:26.23,0:09:32.82,Default,,0000,0000,0000,,can do to make things better. A lot of\Nthis has to do with memory. So whoever it
Dialogue: 0,0:09:32.82,0:09:38.21,Default,,0000,0000,0000,,was that picked the subtitle for this\Nmeeting "refreshing memories" thank you,
Dialogue: 0,0:09:38.21,0:09:45.43,Default,,0000,0000,0000,,because it's great, I love it. Let's\Nrefresh your memory quite a way. So I
Dialogue: 0,0:09:45.43,0:09:52.96,Default,,0000,0000,0000,,invite you to think back to when you were\Nvery very young in about 1837 when cool
Dialogue: 0,0:09:52.96,0:09:58.52,Default,,0000,0000,0000,,hacking was going on. Charles Babbage was\Ndesigning the Analytical Engine and even
Dialogue: 0,0:09:58.52,0:10:03.37,Default,,0000,0000,0000,,then you see there was this dichotomy\Nbetween a mill performing operations and a
Dialogue: 0,0:10:03.37,0:10:11.10,Default,,0000,0000,0000,,store holding numbers. This is a plan view\Nof the analytical engine, well, it was
Dialogue: 0,0:10:11.10,0:10:15.24,Default,,0000,0000,0000,,vaporware, but a design from the\Nanalytical engine, and you see here these
Dialogue: 0,0:10:15.24,0:10:21.69,Default,,0000,0000,0000,,circles these are columns of numbers each\Nmade out of a stack of cogs, maybe a 50
Dialogue: 0,0:10:21.69,0:10:28.34,Default,,0000,0000,0000,,digit decimal number in each of those\Ncolumns. And this array, really, he
Dialogue: 0,0:10:28.34,0:10:34.68,Default,,0000,0000,0000,,imagined it going on out to and over there\Nsomewhere, with about 1000 numbers. So
Dialogue: 0,0:10:34.68,0:10:42.85,Default,,0000,0000,0000,,even then you have a memory which is an\Narray of numbers. I think these were not-
Dialogue: 0,0:10:42.85,0:10:46.52,Default,,0000,0000,0000,,I don't think you could do address\Ncomputation on these things, I think
Dialogue: 0,0:10:46.52,0:10:53.65,Default,,0000,0000,0000,,addresses were only constants, but, still,\Nbasically an array of numbers. So okay
Dialogue: 0,0:10:53.65,0:10:59.37,Default,,0000,0000,0000,,what do we got now. Let's look a bit at C.\NHow many of those people who have
Dialogue: 0,0:10:59.37,0:11:06.98,Default,,0000,0000,0000,,programmed 100 lines of code, how many of\Nyou were C programmers? Quite a few. Or
Dialogue: 0,0:11:06.98,0:11:12.66,Default,,0000,0000,0000,,maybe you're just embarrassed. I forgot to\Nsay. Those that didn't put your hands up
Dialogue: 0,0:11:12.66,0:11:18.50,Default,,0000,0000,0000,,for that first question. You should feel\Nproud and you should glory in your
Dialogue: 0,0:11:18.50,0:11:26.46,Default,,0000,0000,0000,,innocence while you still have it. You are\Nnot yet complicit in this trainwreck. It
Dialogue: 0,0:11:26.46,0:11:31.68,Default,,0000,0000,0000,,worked then. Okay so here's a little piece\Nof C-code which I shall explain. I shall
Dialogue: 0,0:11:31.68,0:11:38.28,Default,,0000,0000,0000,,explain it in several different ways. So\Nwe start out. It creates two locations x
Dialogue: 0,0:11:38.28,0:11:52.67,Default,,0000,0000,0000,,and secret... Don't do that. This is so\Nbad. Creates x, storing one and secret_key
Dialogue: 0,0:11:52.67,0:11:58.98,Default,,0000,0000,0000,,which stores, I might get this wrong, your\Npin. And then there's some computation
Dialogue: 0,0:11:58.98,0:12:05.13,Default,,0000,0000,0000,,which is supposed to only operate on x but\Nmaybe it's a teensy bit buggy or corrupted
Dialogue: 0,0:12:05.13,0:12:13.62,Default,,0000,0000,0000,,by somebody and then we try and we make a\Npointer to x and in this execution x just
Dialogue: 0,0:12:13.62,0:12:21.21,Default,,0000,0000,0000,,happened to be allocated at 14. This\Npointer contains the number 14 and then we
Dialogue: 0,0:12:21.21,0:12:25.39,Default,,0000,0000,0000,,add one to that pointer. It's C so\Nactually that adding one to the pointer it
Dialogue: 0,0:12:25.39,0:12:32.60,Default,,0000,0000,0000,,really means add the four bytes which are\Nthe size of that thing. So we add 4 to 14
Dialogue: 0,0:12:32.60,0:12:40.06,Default,,0000,0000,0000,,and we get 18. And then we try and read\Nthe thing which is pointed to. What's
Dialogue: 0,0:12:40.06,0:12:48.55,Default,,0000,0000,0000,,going to happen. Let me compile this and\Nrun it in a conventional way. It printed a
Dialogue: 0,0:12:48.55,0:12:54.30,Default,,0000,0000,0000,,secret key. Bad. This program, rather\Ndistressingly, this is characteristic by
Dialogue: 0,0:12:54.30,0:12:58.83,Default,,0000,0000,0000,,no means of all security flaws but a very\Ndisturbingly large fraction of all the
Dialogue: 0,0:12:58.83,0:13:10.60,Default,,0000,0000,0000,,security flaws are basically doing this.\NSo does C really let you do that. Yes and
Dialogue: 0,0:13:10.60,0:13:17.91,Default,,0000,0000,0000,,no. So if you look at the C standard,\Nwhich is one of these beautiful books, it
Dialogue: 0,0:13:17.91,0:13:22.86,Default,,0000,0000,0000,,says you, have to read moderately\Ncarefully to understand this, but it says
Dialogue: 0,0:13:22.86,0:13:27.40,Default,,0000,0000,0000,,for this program has undefined behavior.\NAnd many of you will know what that means
Dialogue: 0,0:13:27.40,0:13:32.95,Default,,0000,0000,0000,,but others won't, but, so that means as\Nfar as the standard is concerned for
Dialogue: 0,0:13:32.95,0:13:39.33,Default,,0000,0000,0000,,programs like that there is no constraint\Non the behavior of the implementation at
Dialogue: 0,0:13:39.33,0:13:47.04,Default,,0000,0000,0000,,all. Or said another way and maybe a more\Nusefully way: The standard lets
Dialogue: 0,0:13:47.04,0:13:52.33,Default,,0000,0000,0000,,implementations, so C compilers, assume\Nthat programmers don't have this kind of
Dialogue: 0,0:13:52.33,0:13:59.57,Default,,0000,0000,0000,,stuff and it's the programmer's\Nresponsibility to ensure that. Now in
Dialogue: 0,0:13:59.57,0:14:04.78,Default,,0000,0000,0000,,about 1970, 75 maybe 1980, this was a\Nreally good idea, it gives compilers a lot
Dialogue: 0,0:14:04.78,0:14:14.00,Default,,0000,0000,0000,,of flexibility to do efficient\Nimplementation. Now not so much. How does
Dialogue: 0,0:14:14.00,0:14:19.20,Default,,0000,0000,0000,,this work in the definition? So the\Nstandard somehow has to be able to look at
Dialogue: 0,0:14:19.20,0:14:29.47,Default,,0000,0000,0000,,this program and identify it as having\Nthis undefined behavior. And indeed, well,
Dialogue: 0,0:14:29.47,0:14:37.09,Default,,0000,0000,0000,,if we just think about the numbers in\Nmemory this 18, it points to a perfectly
Dialogue: 0,0:14:37.09,0:14:42.19,Default,,0000,0000,0000,,legitimate storage location and that plus\None was also something that you're
Dialogue: 0,0:14:42.19,0:14:48.15,Default,,0000,0000,0000,,definitely allowed to do in C. So the only\Nway that we can know that this is
Dialogue: 0,0:14:48.15,0:14:54.42,Default,,0000,0000,0000,,undefined behavior is to keep track of the\Noriginal allocation of this pointer. And
Dialogue: 0,0:14:54.42,0:14:59.24,Default,,0000,0000,0000,,here I've got these allocation identifiers\Nat 3, at 4, at 5, and you see here I've
Dialogue: 0,0:14:59.24,0:15:03.69,Default,,0000,0000,0000,,still got this pointer despite the fact\Nthat I added 4 to it. I still remembered
Dialogue: 0,0:15:03.69,0:15:09.94,Default,,0000,0000,0000,,the allocation idea so I can check, or the\Nstandard can check, when we try and read
Dialogue: 0,0:15:09.94,0:15:15.29,Default,,0000,0000,0000,,from this whether that address is within\Nthe footprint of that original allocation,
Dialogue: 0,0:15:15.29,0:15:19.02,Default,,0000,0000,0000,,i.e. is within there and in fact it is\Nnot, it's over here, it is not within
Dialogue: 0,0:15:19.02,0:15:25.51,Default,,0000,0000,0000,,there at all. So this program is deemed to\Nhave undefined behavior. Just to clarify
Dialogue: 0,0:15:25.51,0:15:30.65,Default,,0000,0000,0000,,something people often get confused. So we\Ndetect undefined behavior here but it
Dialogue: 0,0:15:30.65,0:15:35.30,Default,,0000,0000,0000,,isn't really a temporal thing. The fact\Nthat there is undefined behavior anywhere
Dialogue: 0,0:15:35.30,0:15:41.79,Default,,0000,0000,0000,,in the execution means the whole program\Nis toast. Okay but this is really
Dialogue: 0,0:15:41.79,0:15:46.34,Default,,0000,0000,0000,,interesting because we're relying for this\Ncritical part of the standard onto
Dialogue: 0,0:15:46.34,0:15:52.32,Default,,0000,0000,0000,,information which is not there at run time\Nin a conventional implementation. So just
Dialogue: 0,0:15:52.32,0:15:59.05,Default,,0000,0000,0000,,to emphasize that point, if I compile this\Nprogram, let's say to ARM assembly
Dialogue: 0,0:15:59.05,0:16:04.85,Default,,0000,0000,0000,,language I get a sequence of store and\Nload and add instructions, store, load,
Dialogue: 0,0:16:04.85,0:16:12.09,Default,,0000,0000,0000,,add, store, load, load. And if I look at\Nwhat the ARM architecture says can happen
Dialogue: 0,0:16:12.09,0:16:17.14,Default,,0000,0000,0000,,these blue transitions... one thing to\Nnotice is that we can perfectly well do
Dialogue: 0,0:16:17.14,0:16:21.64,Default,,0000,0000,0000,,some things out of order. At this point we\Ncould either do this load or we could do
Dialogue: 0,0:16:21.64,0:16:27.24,Default,,0000,0000,0000,,that store. That would be a whole other\Ntalk. Let's stick with the sequential
Dialogue: 0,0:16:27.24,0:16:33.10,Default,,0000,0000,0000,,execution for now. What I want to\Nemphasize is that these, this load of this
Dialogue: 0,0:16:33.10,0:16:36.57,Default,,0000,0000,0000,,address, really was loading a 64 bit\Nnumber, which was the address of x and
Dialogue: 0,0:16:36.57,0:16:44.42,Default,,0000,0000,0000,,adding 4 to it and then loading from that\Naddress, the secret key. So there is no
Dialogue: 0,0:16:44.42,0:16:55.91,Default,,0000,0000,0000,,trace of these allocation ideas. No trace\Nat all. Okay, let me step back a little
Dialogue: 0,0:16:55.91,0:17:04.94,Default,,0000,0000,0000,,bit. I've been showing you some\Nscreenshots of C behaviour and ARM
Dialogue: 0,0:17:04.94,0:17:12.11,Default,,0000,0000,0000,,behaviour and I claim that these are\Nactually showing you all of the behaviours
Dialogue: 0,0:17:12.11,0:17:19.36,Default,,0000,0000,0000,,allowed by what one would like the\Nstandards to be for these two things. And
Dialogue: 0,0:17:19.36,0:17:26.53,Default,,0000,0000,0000,,really what I've been showing you are GUIs\Nattached to mathematical models that we've
Dialogue: 0,0:17:26.53,0:17:31.00,Default,,0000,0000,0000,,built in a big research project for the\Nlast many years. REMS: "Rigorous
Dialogue: 0,0:17:31.00,0:17:34.93,Default,,0000,0000,0000,,Engineering of Mainstream Systems" sounds\Ngood, aspirational title I think I would
Dialogue: 0,0:17:34.93,0:17:42.05,Default,,0000,0000,0000,,say. And in that we've built semantics, so\Nmathematical models defining the envelope
Dialogue: 0,0:17:42.05,0:17:47.58,Default,,0000,0000,0000,,of all allowed behaviour for a quite big\Nfragment of C and for the concurrency
Dialogue: 0,0:17:47.58,0:17:53.95,Default,,0000,0000,0000,,architecture of major processors ARM, and\Nx86, and RISC-V, and IBM POWER and also
Dialogue: 0,0:17:53.95,0:17:57.77,Default,,0000,0000,0000,,for the instruction set architecture of\Nthese processors, the details of how
Dialogue: 0,0:17:57.77,0:18:03.94,Default,,0000,0000,0000,,individual instructions are executed. And\Nin each case these are specs that are
Dialogue: 0,0:18:03.94,0:18:08.35,Default,,0000,0000,0000,,executable as test oracles, you can\Ncompare algorithmically some observed
Dialogue: 0,0:18:08.35,0:18:13.32,Default,,0000,0000,0000,,behaviour against whether spec says it's\Nallowed or not, which you can't do with
Dialogue: 0,0:18:13.32,0:18:19.03,Default,,0000,0000,0000,,those books. So is it just an idiot simple\Nidea but for some reason the industry has
Dialogue: 0,0:18:19.03,0:18:26.96,Default,,0000,0000,0000,,not taken it on board any time in the last\Nfive decades. It's not that hard to do.
Dialogue: 0,0:18:26.96,0:18:30.71,Default,,0000,0000,0000,,These are also mathematical models, I'll\Ncome back to that later. But another thing
Dialogue: 0,0:18:30.71,0:18:34.53,Default,,0000,0000,0000,,I want to emphasize here is that in each\Nof these cases, especially these first
Dialogue: 0,0:18:34.53,0:18:40.67,Default,,0000,0000,0000,,two, when you start looking really closely\Nthen you learn what you have to do is not
Dialogue: 0,0:18:40.67,0:18:44.40,Default,,0000,0000,0000,,build a nice clean mathematical model of\Nsomething which is well understood. What
Dialogue: 0,0:18:44.40,0:18:50.54,Default,,0000,0000,0000,,you learn is that there are real open\Nquestions. For example within the C
Dialogue: 0,0:18:50.54,0:18:55.76,Default,,0000,0000,0000,,standards committee and within ARM a few\Nyears ago about exactly what these things
Dialogue: 0,0:18:55.76,0:19:01.13,Default,,0000,0000,0000,,even were. And that is a bit disturbing\Ngiven that these are the foundations for
Dialogue: 0,0:19:01.13,0:19:06.01,Default,,0000,0000,0000,,all of our information infrastructure.\NThere is also a lot of other work going on
Dialogue: 0,0:19:06.01,0:19:11.01,Default,,0000,0000,0000,,with other people within this REMS project\Non web assembly and Javascript and file
Dialogue: 0,0:19:11.01,0:19:16.00,Default,,0000,0000,0000,,systems and other concurrency. I don't\Nhave time to talk about those but Hannes
Dialogue: 0,0:19:16.00,0:19:19.64,Default,,0000,0000,0000,,Mehnert it is going to talk us a little\Nbit about TCP later today. You should go
Dialogue: 0,0:19:19.64,0:19:22.76,Default,,0000,0000,0000,,to that talk too if you like this one. If\Nyou don't like this one you should still
Dialogue: 0,0:19:22.76,0:19:33.17,Default,,0000,0000,0000,,go to that talk. Okay so this is doing\Nsomewhat better. certainly more rigorous
Dialogue: 0,0:19:33.17,0:19:41.52,Default,,0000,0000,0000,,engineering of specifications, but so far\Nonly for existing infrastructure for this
Dialogue: 0,0:19:41.52,0:19:49.54,Default,,0000,0000,0000,,C language, ARM architecture, what have\Nyou. So what if we try and do better, what
Dialogue: 0,0:19:49.54,0:19:54.75,Default,,0000,0000,0000,,if we try and build better security in. So\Nthe architectures that we have, really
Dialogue: 0,0:19:54.75,0:20:00.25,Default,,0000,0000,0000,,they date back to the 1970s or even 60s\Nwith the idea of virtual memory. That
Dialogue: 0,0:20:00.25,0:20:04.76,Default,,0000,0000,0000,,gives you - I need to go into what it is -\Nbut that gives you very coarse grain
Dialogue: 0,0:20:04.76,0:20:10.27,Default,,0000,0000,0000,,protection. You can have your separate\Nprocesses isolated from each other and on
Dialogue: 0,0:20:10.27,0:20:15.35,Default,,0000,0000,0000,,a good day you might have separate browser\Ntabs isolated from each other in some
Dialogue: 0,0:20:15.35,0:20:22.43,Default,,0000,0000,0000,,browsers, sometimes, but it doesn't scale.\NIt's just too expensive. You have lots of
Dialogue: 0,0:20:22.43,0:20:27.09,Default,,0000,0000,0000,,little compartments. One thing we can do\Nwe can certainly design much better
Dialogue: 0,0:20:27.09,0:20:34.39,Default,,0000,0000,0000,,programming languages than C but all of\Nthat legacy code, that's got a massive
Dialogue: 0,0:20:34.39,0:20:40.52,Default,,0000,0000,0000,,inertia. So an obvious question is whether\Nwe can build in better security into the
Dialogue: 0,0:20:40.52,0:20:45.59,Default,,0000,0000,0000,,hardware that doesn't need some kind of\Nmassive pervasive change to all the
Dialogue: 0,0:20:45.59,0:20:51.41,Default,,0000,0000,0000,,software we ever wrote. And that's the\Nquestion that a different large project,
Dialogue: 0,0:20:51.41,0:20:55.63,Default,,0000,0000,0000,,the CHERI project has been addressing. So\Nthis is something that's been going on for
Dialogue: 0,0:20:55.63,0:21:01.53,Default,,0000,0000,0000,,the last 8 years or so, mostly at SRI and\Nat Cambridge funded by DARPA and the EPSRC
Dialogue: 0,0:21:01.53,0:21:06.57,Default,,0000,0000,0000,,and ARM and other people, mostly led by\NRobert Watson, Simon Moore, Peter Neumann
Dialogue: 0,0:21:06.57,0:21:14.66,Default,,0000,0000,0000,,and a cast of thousands. And me a tiny\Nbit. So... How, don't do that. I should
Dialogue: 0,0:21:14.66,0:21:20.89,Default,,0000,0000,0000,,learn to stop pushing this button. It's\Nvery hard to not push the button. So
Dialogue: 0,0:21:20.89,0:21:25.19,Default,,0000,0000,0000,,here's the question in a more focused way\Nthat CHERI is asking: Can we build
Dialogue: 0,0:21:25.19,0:21:33.33,Default,,0000,0000,0000,,hardware support which is both efficient\Nenough and deployable enough that gives us
Dialogue: 0,0:21:33.33,0:21:37.34,Default,,0000,0000,0000,,both fine grained memory protection to\Nprevent that kind of bug that we were
Dialogue: 0,0:21:37.34,0:21:42.09,Default,,0000,0000,0000,,talking about earlier, well that kind of\Nleak at least, and also scalable
Dialogue: 0,0:21:42.09,0:21:45.99,Default,,0000,0000,0000,,compartmentalization. So you can take bits\Nof untrusted code and put them in safe
Dialogue: 0,0:21:45.99,0:21:52.88,Default,,0000,0000,0000,,boxes and know that nothing bad is going\Nto get out. That's the question. The
Dialogue: 0,0:21:52.88,0:21:57.39,Default,,0000,0000,0000,,answer... The basic idea of the answer is\Npretty simple and it also dates back to
Dialogue: 0,0:21:57.39,0:22:02.80,Default,,0000,0000,0000,,the 70s is to add hardware support for\Nwhat people call capabilities, and we'll
Dialogue: 0,0:22:02.80,0:22:07.84,Default,,0000,0000,0000,,see that working in a few moments. The\Nidea is that this will let programmers
Dialogue: 0,0:22:07.84,0:22:12.46,Default,,0000,0000,0000,,exercise the principle of least privilege,\Nso with each little bit of code having
Dialogue: 0,0:22:12.46,0:22:17.81,Default,,0000,0000,0000,,only the permissions it needs to do its\Njob and also the principle of intentional
Dialogue: 0,0:22:17.81,0:22:25.79,Default,,0000,0000,0000,,use. So with each little bit of code when\Nit uses one of those capabilities, will
Dialogue: 0,0:22:25.79,0:22:30.42,Default,,0000,0000,0000,,require it to explicitly use it rather\Nthan implicitly. So the intention of the
Dialogue: 0,0:22:30.42,0:22:36.13,Default,,0000,0000,0000,,code has to be made plain. So let's see\Nhow this works. So these capabilities
Dialogue: 0,0:22:36.13,0:22:44.12,Default,,0000,0000,0000,,they're basically replacing some or maybe\Nall of the pointers in your code. So if we
Dialogue: 0,0:22:44.12,0:22:51.05,Default,,0000,0000,0000,,take this example again in ISO C we had an\Naddress and in the standard, well, the
Dialogue: 0,0:22:51.05,0:22:54.55,Default,,0000,0000,0000,,standard is not very clear about this but\Nwe're trying to make it more clear, an
Dialogue: 0,0:22:54.55,0:23:00.96,Default,,0000,0000,0000,,allocation ID, say something like it. Now\Nin Cherry C we can run the same code but
Dialogue: 0,0:23:00.96,0:23:05.53,Default,,0000,0000,0000,,we might represent this pointer not just\Nwith that number at runtime but with
Dialogue: 0,0:23:05.53,0:23:12.77,Default,,0000,0000,0000,,something that contains that number and\Nthe base of the original allocation and
Dialogue: 0,0:23:12.77,0:23:17.40,Default,,0000,0000,0000,,the length of the original allocation and\Nsome permissions. And having all of those
Dialogue: 0,0:23:17.40,0:23:23.02,Default,,0000,0000,0000,,in the pointer means that we can do.. the\Nhardware can do, at run time, at access
Dialogue: 0,0:23:23.02,0:23:29.53,Default,,0000,0000,0000,,time, a very efficient check that this is\Nwithin this region of memory. And if it's
Dialogue: 0,0:23:29.53,0:23:36.27,Default,,0000,0000,0000,,not it can fail stop and trap. No\Ninformation leak. I need a bit more
Dialogue: 0,0:23:36.27,0:23:41.09,Default,,0000,0000,0000,,machinery to make this actually work. So\Nit would be nice if all of these were 64
Dialogue: 0,0:23:41.09,0:23:45.94,Default,,0000,0000,0000,,bit numbers but then you get a 256 bit\Npointer, and that's a bit expensive so
Dialogue: 0,0:23:45.94,0:23:52.79,Default,,0000,0000,0000,,there's a clever compression scheme that\Nsqueezes all this down into 1 to 8 bits
Dialogue: 0,0:23:52.79,0:24:00.30,Default,,0000,0000,0000,,with enough accuracy. And then you need to\Ndesign the instruction set of the CPU
Dialogue: 0,0:24:00.30,0:24:07.39,Default,,0000,0000,0000,,carefully to ensure that you can never\Nforge one of these capabilities with a
Dialogue: 0,0:24:07.39,0:24:13.12,Default,,0000,0000,0000,,normal instruction. You can never just\Nmagic one up out of a bunch of bits that
Dialogue: 0,0:24:13.12,0:24:19.71,Default,,0000,0000,0000,,you happen to find lying around. So all\Nthe capability manipulating instructions,
Dialogue: 0,0:24:19.71,0:24:27.16,Default,,0000,0000,0000,,they're going to take a valid capability\Nand construct another, possibly smaller,
Dialogue: 0,0:24:27.16,0:24:32.02,Default,,0000,0000,0000,,in memory extent, or possibly with less\Npermissions, new capability. They're never
Dialogue: 0,0:24:32.02,0:24:38.61,Default,,0000,0000,0000,,going to grow the memory extent or add\Npermissions. And when the hardware starts,
Dialogue: 0,0:24:38.61,0:24:43.37,Default,,0000,0000,0000,,at hardware initialization time, the\Nhardware will hand the software a
Dialogue: 0,0:24:43.37,0:24:48.91,Default,,0000,0000,0000,,capability to everything and then as the\Noperating system works and the linker
Dialogue: 0,0:24:48.91,0:24:55.82,Default,,0000,0000,0000,,works and the C language allocator works,\Nthese capabilities will be chopped up into
Dialogue: 0,0:24:55.82,0:25:03.18,Default,,0000,0000,0000,,ever finer and smaller pieces like to be\Nhanded out the right places. And then need
Dialogue: 0,0:25:03.18,0:25:10.22,Default,,0000,0000,0000,,one more little thing. So this C language\Nworld we're living in here, or really a
Dialogue: 0,0:25:10.22,0:25:16.33,Default,,0000,0000,0000,,machine code language world so there's\Nnothing stopping code writing bytes of
Dialogue: 0,0:25:16.33,0:25:23.34,Default,,0000,0000,0000,,stuff. So you have to somehow protect\Nthese capabilities against being forged by
Dialogue: 0,0:25:23.34,0:25:28.21,Default,,0000,0000,0000,,the code, either on purpose or\Naccidentally writing bytes over the top.
Dialogue: 0,0:25:28.21,0:25:34.90,Default,,0000,0000,0000,,You need to preserve their integrity. So\Nthat's done by adding for each of these
Dialogue: 0,0:25:34.90,0:25:42.83,Default,,0000,0000,0000,,128 bit sized underlined units of memory\Njust a one extra bit. That holds a tag and
Dialogue: 0,0:25:42.83,0:25:55.16,Default,,0000,0000,0000,,that tag records whether this memory holds\Nare currently valid capability or not. So
Dialogue: 0,0:25:55.16,0:25:59.52,Default,,0000,0000,0000,,all the capability manipulating\Ninstructions, if they're given a valid
Dialogue: 0,0:25:59.52,0:26:06.10,Default,,0000,0000,0000,,capability with a tag set then the result\Nwill still have the tags set. But if you
Dialogue: 0,0:26:06.10,0:26:13.90,Default,,0000,0000,0000,,write, so you just wrote that byte there\Nwhich might change the base then the
Dialogue: 0,0:26:13.90,0:26:20.23,Default,,0000,0000,0000,,hardware will clear that tag and these\Ntags, they're not conventionally
Dialogue: 0,0:26:20.23,0:26:25.19,Default,,0000,0000,0000,,addressable, they don't have addresses.\NThey just stop there in the memory system
Dialogue: 0,0:26:25.19,0:26:30.47,Default,,0000,0000,0000,,of the hardware. So there is no way that soft-\Nware can {\i1}inaudible{\i0} through these. So this is
Dialogue: 0,0:26:30.47,0:26:39.24,Default,,0000,0000,0000,,really cool. We've taken, what in ISO was\Nundefined behavior, in the standard, and
Dialogue: 0,0:26:39.24,0:26:43.97,Default,,0000,0000,0000,,in implementations was a memory leak, and\Nwe've turned it into something that in
Dialogue: 0,0:26:43.97,0:26:49.20,Default,,0000,0000,0000,,CHERI C is in both the specification and\Nthe implementation, is guaranteed to trap,
Dialogue: 0,0:26:49.20,0:26:56.70,Default,,0000,0000,0000,,to fail stop, and not leak that\Ninformation. So another few things about
Dialogue: 0,0:26:56.70,0:27:01.50,Default,,0000,0000,0000,,the design that I should mention. I think\Nall these blue things I think I've talked
Dialogue: 0,0:27:01.50,0:27:07.61,Default,,0000,0000,0000,,about. But then a lot of care has gone in\Nto make this be very flexible to make it
Dialogue: 0,0:27:07.61,0:27:12.50,Default,,0000,0000,0000,,possible to adopt it. So you can use\Ncapabilities for all pointers, if you want
Dialogue: 0,0:27:12.50,0:27:18.100,Default,,0000,0000,0000,,to, or just at some interfaces. You might\Nfor example use them at the kernel
Dialogue: 0,0:27:18.100,0:27:24.83,Default,,0000,0000,0000,,userspace interface. It coexist very\Nnicely with existing C and C++. You don't
Dialogue: 0,0:27:24.83,0:27:29.14,Default,,0000,0000,0000,,need to change the source code very much\Nat all, and we'll see some a tiny bit of
Dialogue: 0,0:27:29.14,0:27:36.86,Default,,0000,0000,0000,,data about this, to make these to start\Nusing these. It coexists with the existing
Dialogue: 0,0:27:36.86,0:27:41.14,Default,,0000,0000,0000,,virtual memory machinery, so you can use\Nboth capabilities and virtual memory, if
Dialogue: 0,0:27:41.14,0:27:45.96,Default,,0000,0000,0000,,you want, or you can just use capabilities\Nif you want or just use virtual memory if
Dialogue: 0,0:27:45.96,0:27:50.94,Default,,0000,0000,0000,,you want. And then there's some more\Nmachinery, which I'm not going to talk
Dialogue: 0,0:27:50.94,0:27:54.100,Default,,0000,0000,0000,,about, for doing this secure encapsulation\Nstuff. What I've talked about so far is
Dialogue: 0,0:27:54.100,0:27:59.44,Default,,0000,0000,0000,,basically the the fine grained memory\Nprotection story. And I should say the
Dialogue: 0,0:27:59.44,0:28:05.38,Default,,0000,0000,0000,,focus so far is on spatial memory safety.\NSo that's not in the first instance
Dialogue: 0,0:28:05.38,0:28:11.45,Default,,0000,0000,0000,,protecting against reuse of an old\Ncapability in a bad way but there various
Dialogue: 0,0:28:11.45,0:28:17.71,Default,,0000,0000,0000,,schemes for supporting temporal memory\Nsafety with basically the same setup. Okay
Dialogue: 0,0:28:17.71,0:28:24.82,Default,,0000,0000,0000,,so. So how do we... Okay this is some kind\Nof a high level idea. How do we know that
Dialogue: 0,0:28:24.82,0:28:32.67,Default,,0000,0000,0000,,it can be made to work. Well the only way\Nis to actually build it and see. And this
Dialogue: 0,0:28:32.67,0:28:36.95,Default,,0000,0000,0000,,has been a really interesting process\Nbecause mostly when you're building
Dialogue: 0,0:28:36.95,0:28:40.98,Default,,0000,0000,0000,,something either in academia or an\Nindustry you have to keep most of the
Dialogue: 0,0:28:40.98,0:28:46.73,Default,,0000,0000,0000,,parts fixed, I mean you are not routinely\Nchanging both the processor and the
Dialogue: 0,0:28:46.73,0:28:51.15,Default,,0000,0000,0000,,operating system, because that would just\Nbe too scary. But here we have been doing
Dialogue: 0,0:28:51.15,0:28:57.85,Default,,0000,0000,0000,,that and indeed we've really been doing a\Nthree way, three way codesign of building
Dialogue: 0,0:28:57.85,0:29:02.81,Default,,0000,0000,0000,,hardware and building and adapting\Nsoftware to run above it and also building
Dialogue: 0,0:29:02.81,0:29:09.25,Default,,0000,0000,0000,,these mathematical models all at the same\Ntime. This is, well. A, it's all the fun
Dialogue: 0,0:29:09.25,0:29:13.22,Default,,0000,0000,0000,,because you can often get groups of people\Ntogether that can do all of those things
Dialogue: 0,0:29:13.22,0:29:20.27,Default,,0000,0000,0000,,but B, it's really effective. So what\Nwe've produced then is an architecture
Dialogue: 0,0:29:20.27,0:29:25.05,Default,,0000,0000,0000,,specification. In fact, extending MIPS\Nbecause it was conveniently free of IP
Dialogue: 0,0:29:25.05,0:29:32.19,Default,,0000,0000,0000,,concerns and that specification is one of\Nthese mathematically rigorous things
Dialogue: 0,0:29:32.19,0:29:36.35,Default,,0000,0000,0000,,expressed in a domain specific language\Nspecifically for writing instruction set
Dialogue: 0,0:29:36.35,0:29:40.14,Default,,0000,0000,0000,,architecture specifications, and we've\Ndesigned and implemented actually two of
Dialogue: 0,0:29:40.14,0:29:44.40,Default,,0000,0000,0000,,those. And then there are hardware\Nprocessor implementations that actually
Dialogue: 0,0:29:44.40,0:29:49.25,Default,,0000,0000,0000,,run an FPGAs. And a lot of hardware\Nresearch devoted to making this go fast
Dialogue: 0,0:29:49.25,0:29:54.38,Default,,0000,0000,0000,,and be efficient despite these extra tags\Nand whatnot. And then there's a big
Dialogue: 0,0:29:54.38,0:30:00.67,Default,,0000,0000,0000,,software stack adapted to run over this\Nstuff. Including Clang and a FreeBSD
Dialogue: 0,0:30:00.67,0:30:06.62,Default,,0000,0000,0000,,kernel and FreeBSD userspace and WebKit\Nand all kinds of pieces. So this is a very
Dialogue: 0,0:30:06.62,0:30:12.31,Default,,0000,0000,0000,,major evaluation effort. That one is not\Nnormally able to do. This is why, this
Dialogue: 0,0:30:12.31,0:30:18.05,Default,,0000,0000,0000,,combination of things is why that list of\Npeople up there was about 40 people. I say
Dialogue: 0,0:30:18.05,0:30:22.56,Default,,0000,0000,0000,,this is based on MIPS but the ideas are\Nnot specific to MIPS, there are ongoing
Dialogue: 0,0:30:22.56,0:30:28.19,Default,,0000,0000,0000,,research projects to see if this can be\Nadapted to the ARM application class
Dialogue: 0,0:30:28.19,0:30:32.58,Default,,0000,0000,0000,,architecture and the ARM microcontroller\Narchitecture and the RISC-V. We'll see how
Dialogue: 0,0:30:32.58,0:30:41.53,Default,,0000,0000,0000,,that goes, in due course. Okay so then\Nwith all of these pieces we can evaluate
Dialogue: 0,0:30:41.53,0:30:46.27,Default,,0000,0000,0000,,whether it actually works. And that's\Nstill kind of an ongoing process but the
Dialogue: 0,0:30:46.27,0:30:57.18,Default,,0000,0000,0000,,data that we've got so far is pretty\Nencouraging. So we see here first,
Dialogue: 0,0:30:57.18,0:31:08.23,Default,,0000,0000,0000,,performance. So you see, maybe a percent\Nor 2 in many cases of runtime overhead.
Dialogue: 0,0:31:08.23,0:31:11.50,Default,,0000,0000,0000,,There are workloads where it performs\Nbadly if you have something that's very
Dialogue: 0,0:31:11.50,0:31:17.27,Default,,0000,0000,0000,,pointer heavy, then the extra pressure\Nfrom those larger pointers will be a bit
Dialogue: 0,0:31:17.27,0:31:24.09,Default,,0000,0000,0000,,annoying, but really it seems to be\Nsurprisingly good. Then is it something
Dialogue: 0,0:31:24.09,0:31:31.42,Default,,0000,0000,0000,,that can work without massive adaption to\Nthe existing code. Well, in this port of
Dialogue: 0,0:31:31.42,0:31:38.25,Default,,0000,0000,0000,,the FreeBSD userspace, so all the programs\Nthat, all in all programs that run, they
Dialogue: 0,0:31:38.25,0:31:45.12,Default,,0000,0000,0000,,were something like 20000 files and only\N200 of those needed a change. And that's
Dialogue: 0,0:31:45.12,0:31:52.08,Default,,0000,0000,0000,,been done by one or two people in not all\Nthat large an amount of time. Some of the
Dialogue: 0,0:31:52.08,0:31:57.23,Default,,0000,0000,0000,,other code that's more and more like an\Noperating system needs a bit more invasive
Dialogue: 0,0:31:57.23,0:32:06.07,Default,,0000,0000,0000,,change but still, it seems to be viable.\NIs it actually more secure? How are you
Dialogue: 0,0:32:06.07,0:32:10.71,Default,,0000,0000,0000,,going to measure that. We like measuring\Nthings as a whole we try and do science
Dialogue: 0,0:32:10.71,0:32:17.44,Default,,0000,0000,0000,,where we can. Can we measure that? Not\Nreally. But it certainly does, the whole
Dialogue: 0,0:32:17.44,0:32:23.30,Default,,0000,0000,0000,,setup certainly does, mitigate against\Nquite a large family of known attacks. I
Dialogue: 0,0:32:23.30,0:32:28.26,Default,,0000,0000,0000,,mean if you try and run Heartbleed you'll\Nget a trap. It will say trap. I think he
Dialogue: 0,0:32:28.26,0:32:36.50,Default,,0000,0000,0000,,will say signal 34 in fact. So that's\Npretty good. And if you think about
Dialogue: 0,0:32:36.50,0:32:42.95,Default,,0000,0000,0000,,attacks, very many of them involve a chain\Nof multiple floors put together by an
Dialogue: 0,0:32:42.95,0:32:49.40,Default,,0000,0000,0000,,ingenious member of the C3 community or\Nsomebody else, and very often, at least
Dialogue: 0,0:32:49.40,0:33:00.12,Default,,0000,0000,0000,,one of those is some kind of memory access\Npermission flaw of some kind or other.
Dialogue: 0,0:33:00.12,0:33:03.54,Default,,0000,0000,0000,,Okay so this is nice, but I was talking a\Nlot in the first part of the talk, about
Dialogue: 0,0:33:03.54,0:33:11.92,Default,,0000,0000,0000,,rigorous engineering. So here we've got\Nformally defined definitions of the
Dialogue: 0,0:33:11.92,0:33:16.78,Default,,0000,0000,0000,,architecture and that's been really useful\Nfor testing against and for doing test
Dialogue: 0,0:33:16.78,0:33:22.89,Default,,0000,0000,0000,,generation on the basis of, and doing\Nspecification coverage in an automated
Dialogue: 0,0:33:22.89,0:33:28.81,Default,,0000,0000,0000,,way. But surely we should be able to do\Nmore than that. So this formal definition
Dialogue: 0,0:33:28.81,0:33:34.86,Default,,0000,0000,0000,,of the architecture, what does it look\Nlike. So for each instruction of this
Dialogue: 0,0:33:34.86,0:33:40.67,Default,,0000,0000,0000,,CHERI MIPS processor, there's a definition\Nand that definition, it looks a bit like
Dialogue: 0,0:33:40.67,0:33:47.98,Default,,0000,0000,0000,,normal code. So here's a definition of how\Nthe instruction for "capability increment
Dialogue: 0,0:33:47.98,0:33:54.16,Default,,0000,0000,0000,,cursor immediate" goes. So this is a thing\Nthat takes a capability register and an
Dialogue: 0,0:33:54.16,0:33:58.31,Default,,0000,0000,0000,,immediate value and it tries to add\Nsomething on to the cursor of that
Dialogue: 0,0:33:58.31,0:34:03.64,Default,,0000,0000,0000,,capability. And what you see here is some\Ncode, looks like code, that defines
Dialogue: 0,0:34:03.64,0:34:06.83,Default,,0000,0000,0000,,exactly what happens and also defines\Nexactly what happens if something goes
Dialogue: 0,0:34:06.83,0:34:13.14,Default,,0000,0000,0000,,wrong. You can see there's some kind of an\Nexception case there. That's a processor.
Dialogue: 0,0:34:13.14,0:34:19.14,Default,,0000,0000,0000,,No that's a... Yeah, that a "raising our\Nprocessor" exception. So it looks like
Dialogue: 0,0:34:19.14,0:34:25.27,Default,,0000,0000,0000,,code, but, from this, we can generate both\Nreasonably high performance emulators,
Dialogue: 0,0:34:25.27,0:34:30.78,Default,,0000,0000,0000,,reasonably in C and in OCaml, and also\Nmathematical models in the theorem
Dialogue: 0,0:34:30.78,0:34:34.77,Default,,0000,0000,0000,,provers. So three of the main theorem\Nprovers in the world are called Isabelle
Dialogue: 0,0:34:34.77,0:34:41.69,Default,,0000,0000,0000,,and HOL and Coq. And we generate\Ndefinitions in all of those. So then we
Dialogue: 0,0:34:41.69,0:34:46.49,Default,,0000,0000,0000,,got a mathematical definition of the\Narchitecture. Then finally, we can start
Dialogue: 0,0:34:46.49,0:34:51.53,Default,,0000,0000,0000,,stating some properties. So Cherrie's\Ndesign with some kind of vague security
Dialogue: 0,0:34:51.53,0:34:57.81,Default,,0000,0000,0000,,goals in mind from the beginning but now\Nwe can take, let'ssay one of those goals and
Dialogue: 0,0:34:57.81,0:35:06.57,Default,,0000,0000,0000,,make it into a precise thing. So this is a\Nkind of a secure encapsulation, kind of
Dialogue: 0,0:35:06.57,0:35:12.54,Default,,0000,0000,0000,,thing not exactly the memory leak that we\Nwere looking at before. Sorry, the secret
Dialogue: 0,0:35:12.54,0:35:17.82,Default,,0000,0000,0000,,leak that we were looking at. So let's\Ntake imagine some CHERI compartment.
Dialogue: 0,0:35:17.82,0:35:22.02,Default,,0000,0000,0000,,Haven't told you exactly what that means\Nbut let's suppose that that's understood
Dialogue: 0,0:35:22.02,0:35:27.49,Default,,0000,0000,0000,,and that inside that compartment there is\Na piece of software running. And that
Dialogue: 0,0:35:27.49,0:35:35.56,Default,,0000,0000,0000,,might be maybe a video codec or a web\Nbrowser or even a data structure
Dialogue: 0,0:35:35.56,0:35:44.41,Default,,0000,0000,0000,,implementation maybe, or a C++ class and\Nall of its objects maybe. So imagine that
Dialogue: 0,0:35:44.41,0:35:50.05,Default,,0000,0000,0000,,compartment running and imagine the\Ninitial capabilities that it has access to
Dialogue: 0,0:35:50.05,0:35:55.64,Default,,0000,0000,0000,,via registers and memory and via all the\Ncapabilities it has access to via the
Dialogue: 0,0:35:55.64,0:35:59.51,Default,,0000,0000,0000,,memory that it has access to and so on\Nrecursively. So imagine all of those
Dialogue: 0,0:35:59.51,0:36:06.36,Default,,0000,0000,0000,,capabilities. So the theorem says no\Nmatter how this code executes whatever it
Dialogue: 0,0:36:06.36,0:36:15.73,Default,,0000,0000,0000,,does however compromised or buggy it was\Nin an execution up until any point at
Dialogue: 0,0:36:15.73,0:36:24.02,Default,,0000,0000,0000,,which it raises an exception or makes an\Ninter compartment call it can't make any
Dialogue: 0,0:36:24.02,0:36:30.53,Default,,0000,0000,0000,,access which is not allowed by those\Ninitial capabilities. You have to exclude
Dialogue: 0,0:36:30.53,0:36:35.23,Default,,0000,0000,0000,,exceptions and into compartment calls\Nbecause by design they do introduce new
Dialogue: 0,0:36:35.23,0:36:42.69,Default,,0000,0000,0000,,capabilities into the execution. But until\Nthat point you get this guarantee. And
Dialogue: 0,0:36:42.69,0:36:48.85,Default,,0000,0000,0000,,this is something that we've proved\Nactually [...] has approved with a machine
Dialogue: 0,0:36:48.85,0:36:55.98,Default,,0000,0000,0000,,check proof in in fact the Isabelle\Ntheorem prover. So this is a fact which is
Dialogue: 0,0:36:55.98,0:37:03.59,Default,,0000,0000,0000,,about as solidly known as any fact the\Nhuman race knows. These provers they're
Dialogue: 0,0:37:03.59,0:37:10.45,Default,,0000,0000,0000,,checking a mathematical proof in\Nexceedingly great detail with great care
Dialogue: 0,0:37:10.45,0:37:14.23,Default,,0000,0000,0000,,and attention and they're structured in\Nsuch a way that the soundness of approver
Dialogue: 0,0:37:14.23,0:37:21.30,Default,,0000,0000,0000,,depends only on some tiny little kernel.\NSo conceivably cosmic rays hit the
Dialogue: 0,0:37:21.30,0:37:27.23,Default,,0000,0000,0000,,transistors at all the wrong points. But\Nbasically we know this for sure. I
Dialogue: 0,0:37:27.23,0:37:34.30,Default,,0000,0000,0000,,emphasize this is a security property we\Nhave not proved, we certainly wouldn't
Dialogue: 0,0:37:34.30,0:37:39.44,Default,,0000,0000,0000,,claim to have proved that CHERI is secure\Nand there are all kinds of other kinds of
Dialogue: 0,0:37:39.44,0:37:44.85,Default,,0000,0000,0000,,attack that this statement doesn't even\Naddress but at least this one property we
Dialogue: 0,0:37:44.85,0:37:49.88,Default,,0000,0000,0000,,know it for real. So that's kind of\Ncomforting and not a thing that
Dialogue: 0,0:37:49.88,0:38:01.42,Default,,0000,0000,0000,,conventional computer science engineering\Nhas been able to do on the whole. So, are
Dialogue: 0,0:38:01.42,0:38:10.75,Default,,0000,0000,0000,,we taming the chaos then. Well no. Sorry.\NBut I've shown you two kinds of things.
Dialogue: 0,0:38:10.75,0:38:15.98,Default,,0000,0000,0000,,The first was showing how we can do\Nsomewhat more rigorous engineering for
Dialogue: 0,0:38:15.98,0:38:21.64,Default,,0000,0000,0000,,that existing infrastructure. It's now\Nfeasible to do that and in fact I believe
Dialogue: 0,0:38:21.64,0:38:26.37,Default,,0000,0000,0000,,it has been feasible to build\Nspecifications which you can use as test
Dialogue: 0,0:38:26.37,0:38:31.46,Default,,0000,0000,0000,,oracles for many decades. We haven't\Nneeded any super fancy new tech for that.
Dialogue: 0,0:38:31.46,0:38:41.14,Default,,0000,0000,0000,,We've just needed to focus on that idea.\NSo that's for existing infrastructure and
Dialogue: 0,0:38:41.14,0:38:47.47,Default,,0000,0000,0000,,then CHERI is a relatively light weight\Nchange that does built-in improved
Dialogue: 0,0:38:47.47,0:38:53.52,Default,,0000,0000,0000,,security and we think it's demonstrably\Ndeployable at least in principle. Is it
Dialogue: 0,0:38:53.52,0:38:58.01,Default,,0000,0000,0000,,deployable in practice? Are we going to\Nhave in all of our phones five years from
Dialogue: 0,0:38:58.01,0:39:05.89,Default,,0000,0000,0000,,now? Will these all be CHERI enabled? I\Ncan't say. I think it is plausible that
Dialogue: 0,0:39:05.89,0:39:09.59,Default,,0000,0000,0000,,that should happen and we're exploring\Nvarious routes that might mean that there
Dialogue: 0,0:39:09.59,0:39:20.26,Default,,0000,0000,0000,,happens and we'll see how that goes. Okay\Nso with that I aiming to have given you at
Dialogue: 0,0:39:20.26,0:39:25.76,Default,,0000,0000,0000,,least not a whole lot of hope but just a\Nlittle bit of hope that the world can be
Dialogue: 0,0:39:25.76,0:39:30.67,Default,,0000,0000,0000,,made a better place and I encourage you to\Nthink about ways to do it because Lord
Dialogue: 0,0:39:30.67,0:39:38.29,Default,,0000,0000,0000,,knows we need it. But maybe you can at\Nleast dream for a few moments of living in
Dialogue: 0,0:39:38.29,0:39:46.01,Default,,0000,0000,0000,,a better world. And with that I thank you\Nfor your attention.
Dialogue: 0,0:39:46.01,0:39:57.00,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:39:57.00,0:40:06.42,Default,,0000,0000,0000,,Herald Angel: Thanks very much. And with\Nthat we'll head straight into the Q and A.
Dialogue: 0,0:40:06.42,0:40:10.21,Default,,0000,0000,0000,,We'll just start with mic number one which\NI can see right now.
Dialogue: 0,0:40:10.21,0:40:15.72,Default,,0000,0000,0000,,Q: Yes thanks for the very encouraging\Ntalk. I have a question about how to C
Dialogue: 0,0:40:15.72,0:40:21.50,Default,,0000,0000,0000,,code the part below that. The theorem that\Nyou stated assumes that the mentioned
Dialogue: 0,0:40:21.50,0:40:28.20,Default,,0000,0000,0000,,description matches the hardware at least\Nis describes the hardware accurately. But
Dialogue: 0,0:40:28.20,0:40:33.13,Default,,0000,0000,0000,,are there any attempts to check that the\Nhardware actually works like that? That
Dialogue: 0,0:40:33.13,0:40:37.17,Default,,0000,0000,0000,,there are no wholes in the hardware? That\Nsome combination of mentioned commands
Dialogue: 0,0:40:37.17,0:40:42.98,Default,,0000,0000,0000,,work differently or allow memory access\Nthere is not in the model? So, is it
Dialogue: 0,0:40:42.98,0:40:48.99,Default,,0000,0000,0000,,possible to use hardware designs and check\Nthat it matches the spec and will Intel or
Dialogue: 0,0:40:48.99,0:40:53.73,Default,,0000,0000,0000,,AMD try to check their model against that\Nspec?
Dialogue: 0,0:40:53.73,0:40:59.70,Default,,0000,0000,0000,,Sewell: OK. So the question is basically\Ncan we do provably correct hardware
Dialogue: 0,0:40:59.70,0:41:05.56,Default,,0000,0000,0000,,underneath this architectural abstraction.\NAnd the answer is... So it's a good
Dialogue: 0,0:41:05.56,0:41:12.70,Default,,0000,0000,0000,,question. People are working on that and\Nit can be done I think on at least a
Dialogue: 0,0:41:12.70,0:41:22.13,Default,,0000,0000,0000,,modest academic scale. Trying to do that\Nin its full glory for a industrial
Dialogue: 0,0:41:22.13,0:41:27.83,Default,,0000,0000,0000,,superscalar processor design, is right now\Nout of reach. But it's certainly something
Dialogue: 0,0:41:27.83,0:41:35.26,Default,,0000,0000,0000,,one would like to be able to do. I think\Nwe will get there maybe in a decade or so.
Dialogue: 0,0:41:35.26,0:41:41.91,Default,,0000,0000,0000,,A decade is quick.\NHerald Angel: Thanks. Mic number four is
Dialogue: 0,0:41:41.91,0:41:48.47,Default,,0000,0000,0000,,empty again. So we'll take the Internet.\NSewell: Where is the internet?
Dialogue: 0,0:41:48.47,0:41:53.36,Default,,0000,0000,0000,,Signal Angel: The internet is right here\Nand everywhere so ruminate would like to
Dialogue: 0,0:41:53.36,0:41:59.96,Default,,0000,0000,0000,,know is the effort and cost of building in security\Nto hardware as you've described in your
Dialogue: 0,0:41:59.96,0:42:05.88,Default,,0000,0000,0000,,talk significantly greater or less than\Nthe effort and cost of porting software to
Dialogue: 0,0:42:05.88,0:42:12.06,Default,,0000,0000,0000,,more secure languages.\NSewell: So, is the effort of building new
Dialogue: 0,0:42:12.06,0:42:17.35,Default,,0000,0000,0000,,hardware more or less than the cost of\Nporting existing software to better
Dialogue: 0,0:42:17.35,0:42:26.28,Default,,0000,0000,0000,,languages? I think the answer has to be\Nyes. It is less. The difficulty with
Dialogue: 0,0:42:26.28,0:42:30.70,Default,,0000,0000,0000,,porting software is all of you and all\Nyour colleagues and all of your friends
Dialogue: 0,0:42:30.70,0:42:36.01,Default,,0000,0000,0000,,and all your enemies have been beavering\Naway writing lines of code for 50 years.
Dialogue: 0,0:42:36.01,0:42:42.41,Default,,0000,0000,0000,,Really, I don't know what to say,\Neffectively. Really numerously. There's an
Dialogue: 0,0:42:42.41,0:42:46.28,Default,,0000,0000,0000,,awful lot of it. It's a really terrifying\Namount of code out there. It's very hard
Dialogue: 0,0:42:46.28,0:42:54.39,Default,,0000,0000,0000,,to get people to rewrite it.\NSignal Angel: OK, mic two.
Dialogue: 0,0:42:54.39,0:43:03.03,Default,,0000,0000,0000,,Q: OK, given that cost of ... of today on the\Nsoftware level not on the hardware level, is it
Dialogue: 0,0:43:03.03,0:43:11.94,Default,,0000,0000,0000,,possible to go half way using an entire\Nsystem as an oracle. So during development
Dialogue: 0,0:43:11.94,0:43:19.28,Default,,0000,0000,0000,,there are code based with the secure\Nhardware but then essentially ship the
Dialogue: 0,0:43:19.28,0:43:28.86,Default,,0000,0000,0000,,same software to unsecure hardware and {\i1}inaudible{\i0}\NSewell: So this question, if I paraphrase
Dialogue: 0,0:43:28.86,0:43:35.82,Default,,0000,0000,0000,,it is can we use this hardware\Nimplementation really as the perfect
Dialogue: 0,0:43:35.82,0:43:45.02,Default,,0000,0000,0000,,sanitiser? And I think there is scope for\Ndoing that. And you can even imagine
Dialogue: 0,0:43:45.02,0:43:49.75,Default,,0000,0000,0000,,running this not on actual silicon\Nhardware but in like a QEMU implementation
Dialogue: 0,0:43:49.75,0:43:54.82,Default,,0000,0000,0000,,which we have in order to do that. And I\Nthink for for that purpose it could
Dialogue: 0,0:43:54.82,0:44:00.72,Default,,0000,0000,0000,,already be a pretty effective bug finding\Ntool. It would be worth doing. But you
Dialogue: 0,0:44:00.72,0:44:06.25,Default,,0000,0000,0000,,would like as for any testing it will only\Nexplore a very tiny fraction of the
Dialogue: 0,0:44:06.25,0:44:13.54,Default,,0000,0000,0000,,possible paths. So we would like to have\Nit always on if we possibly can.
Dialogue: 0,0:44:13.54,0:44:19.69,Default,,0000,0000,0000,,Herald Angel: OK. The internet again.\NSignal Angel: OK someone would like to
Dialogue: 0,0:44:19.69,0:44:26.13,Default,,0000,0000,0000,,know how does your technique compare to\NIntel MPX which failed miserably with a {\i1}inaudible{\i0}
Dialogue: 0,0:44:26.13,0:44:33.82,Default,,0000,0000,0000,,ignoring it. Will it better or faster?\NCould you talk a little bit about that.
Dialogue: 0,0:44:33.82,0:44:38.40,Default,,0000,0000,0000,,Sewell: I think for that question, for a\Nreal answer to that question, you would
Dialogue: 0,0:44:38.40,0:44:45.55,Default,,0000,0000,0000,,need one of my more hardware colleagues.\NWhat I can say is they make nasty faces
Dialogue: 0,0:44:45.55,0:44:53.45,Default,,0000,0000,0000,,when you say MPX.\NHerald Angel: Well that's that. Mic number
Dialogue: 0,0:44:53.45,0:44:56.88,Default,,0000,0000,0000,,one.\NQ: Somewhat inherent to your whole
Dialogue: 0,0:44:56.88,0:45:02.46,Default,,0000,0000,0000,,construction was this idea of having an\Nunchangeable bit which described whether
Dialogue: 0,0:45:02.46,0:45:08.54,Default,,0000,0000,0000,,your pointer contents have been changed.\NIs this even something that can be done in
Dialogue: 0,0:45:08.54,0:45:12.85,Default,,0000,0000,0000,,software? Or do you have to construct a\Nwhole extra RAM or something?
Dialogue: 0,0:45:12.85,0:45:21.31,Default,,0000,0000,0000,,Sewell: So you can't do it exclusively in\Nsoftware because you need to protect it.
Dialogue: 0,0:45:21.31,0:45:25.55,Default,,0000,0000,0000,,In the hardware implementations that my\Ncolleagues have built it's done in a
Dialogue: 0,0:45:25.55,0:45:32.70,Default,,0000,0000,0000,,reasonably efficient way. So it's cached\Nand managed in clever ways to ensure that
Dialogue: 0,0:45:32.70,0:45:38.73,Default,,0000,0000,0000,,it's not terribly expensive to do. But you\Ndo need slightly wider data paths in your
Dialogue: 0,0:45:38.73,0:45:45.46,Default,,0000,0000,0000,,cache protocol and things like that to\Nmanage it.
Dialogue: 0,0:45:45.46,0:45:51.53,Default,,0000,0000,0000,,Herald Angel: OK. Mic seven.\NQ: How good does this system help securing
Dialogue: 0,0:45:51.53,0:45:56.85,Default,,0000,0000,0000,,the control flow integrity compared to\Ncompared to other systems, like hardware
Dialogue: 0,0:45:56.85,0:46:03.87,Default,,0000,0000,0000,,systems data flow isolation or code\Npointer integrity in ARM {\i1}inaudible{\i0}?
Dialogue: 0,0:46:03.87,0:46:09.31,Default,,0000,0000,0000,,Sewell: Ah well, that's another question\Nwhich is a bit hard to answer because then
Dialogue: 0,0:46:09.31,0:46:18.18,Default,,0000,0000,0000,,it depends somewhat on how you're using\Nthe capabilities. So you can arrange here
Dialogue: 0,0:46:18.18,0:46:25.55,Default,,0000,0000,0000,,that each state each C language allocation\Nis independently protected and indeed you
Dialogue: 0,0:46:25.55,0:46:30.47,Default,,0000,0000,0000,,can also arrange that each way - this is\Nsensible - that each subobject is
Dialogue: 0,0:46:30.47,0:46:34.92,Default,,0000,0000,0000,,independent protected. And those\Nprotections are going to give you
Dialogue: 0,0:46:34.92,0:46:39.31,Default,,0000,0000,0000,,protection against trashing bits of the\Nstack because they'll restrict the
Dialogue: 0,0:46:39.31,0:46:50.67,Default,,0000,0000,0000,,capability to just those objects.\NHerald Angel: OK the internet again.
Dialogue: 0,0:46:50.67,0:46:57.74,Default,,0000,0000,0000,,Signal Angel: Twitter would like to know\Nis it possible to is it possible to run
Dialogue: 0,0:46:57.74,0:47:04.29,Default,,0000,0000,0000,,CHERI C without custom hardware?\NSewell: Can you run CHERI C without custom
Dialogue: 0,0:47:04.29,0:47:12.95,Default,,0000,0000,0000,,hardware? And the answer is you can run it\Nin emulation above this QEMU. That works
Dialogue: 0,0:47:12.95,0:47:18.04,Default,,0000,0000,0000,,pretty fast, I mean fast enough for\Ndebugging as the earlier question was
Dialogue: 0,0:47:18.04,0:47:28.61,Default,,0000,0000,0000,,talking about. You can imagine you know\Nsomewhat faster emulations of that. It's
Dialogue: 0,0:47:28.61,0:47:34.34,Default,,0000,0000,0000,,not clear how much it's worth going down\Nthat route. The real potential big win is
Dialogue: 0,0:47:34.34,0:47:41.24,Default,,0000,0000,0000,,to have this be always on and that's what\Nwe would like to have.
Dialogue: 0,0:47:41.24,0:47:47.39,Default,,0000,0000,0000,,Herald Angel: OK. Mic one.\NQ: Do you have some examples of the kinds
Dialogue: 0,0:47:47.39,0:47:51.90,Default,,0000,0000,0000,,of code changes that you need to the\Noperating system and userland that you
Dialogue: 0,0:47:51.90,0:47:55.86,Default,,0000,0000,0000,,mentioned?\NSewell: So, okay so what kind of changes
Dialogue: 0,0:47:55.86,0:48:07.14,Default,,0000,0000,0000,,do you need to to adapt code to CHERI? So,\Nif you look at C-code there is the C
Dialogue: 0,0:48:07.14,0:48:12.52,Default,,0000,0000,0000,,standard that deems a whole lot of things\Nto be undefined behavior and then if you
Dialogue: 0,0:48:12.52,0:48:19.94,Default,,0000,0000,0000,,look at actual C code you find that very\Nvery much of it does depend on some idiom
Dialogue: 0,0:48:19.94,0:48:28.65,Default,,0000,0000,0000,,that the C standard does not approve of.\NSo there is for example, {\i1}pause{\i0} there are
Dialogue: 0,0:48:28.65,0:48:34.74,Default,,0000,0000,0000,,quite a lot of instances of code that\Nconstructs a pointer by doing more than
Dialogue: 0,0:48:34.74,0:48:42.38,Default,,0000,0000,0000,,one more than plus one offset and then\Nbrings it back within range before you use
Dialogue: 0,0:48:42.38,0:48:49.45,Default,,0000,0000,0000,,it. So in fact in CHERI C many of those\Ncases are allowed but not all of them.
Dialogue: 0,0:48:49.45,0:48:58.20,Default,,0000,0000,0000,,More exotic cases where there's really\Nsome crazy into object stuff going on or
Dialogue: 0,0:48:58.20,0:49:03.34,Default,,0000,0000,0000,,where pointer arithmetic between objects -\Nwhich the C standard is certainly quite
Dialogue: 0,0:49:03.34,0:49:09.29,Default,,0000,0000,0000,,down on but which does happen - and code\Nwhich is, say manipulating the low order
Dialogue: 0,0:49:09.29,0:49:13.55,Default,,0000,0000,0000,,bits of a pointer to store some data in\Nit. That's pretty common. You can do it in
Dialogue: 0,0:49:13.55,0:49:18.17,Default,,0000,0000,0000,,CHERI C but you might have to adapt the\Ncode a little bit. Other cases are more
Dialogue: 0,0:49:18.17,0:49:22.85,Default,,0000,0000,0000,,fundamental. So say, in operating system\Ncode if you swap out a page to disk and
Dialogue: 0,0:49:22.85,0:49:28.46,Default,,0000,0000,0000,,then you swap it back in then somehow the\Noperating system has to reconstruct new
Dialogue: 0,0:49:28.46,0:49:35.20,Default,,0000,0000,0000,,capabilities from a large capability which\Nit kept for the purpose. So that needs a
Dialogue: 0,0:49:35.20,0:49:41.87,Default,,0000,0000,0000,,bit more work. Though it's kind of a\Ncombination. Some things you would regard
Dialogue: 0,0:49:41.87,0:49:48.32,Default,,0000,0000,0000,,as good changes to the code anyway and\Nothers are more radical.
Dialogue: 0,0:49:48.32,0:49:51.60,Default,,0000,0000,0000,,Herald Angel: OK, another one from the\Ninternet.
Dialogue: 0,0:49:51.60,0:50:00.00,Default,,0000,0000,0000,,Signal Angel: I lost one {\i1}pause{\i0}\NSewell: The Internet has gone quiet. Yes.
Dialogue: 0,0:50:00.00,0:50:04.42,Default,,0000,0000,0000,,Signal Angel: Last question from the\Ninternet. Are there any plans to impact
Dialogue: 0,0:50:04.42,0:50:11.95,Default,,0000,0000,0000,,test on Linux or just FreeBSD?\NSewell: If anyone has a good number of
Dialogue: 0,0:50:11.95,0:50:19.98,Default,,0000,0000,0000,,spare minutes then that would be lovely to\Ntry. The impact on Linux not just
Dialogue: 0,0:50:19.98,0:50:26.40,Default,,0000,0000,0000,,previously the BSD code base is simpler\Nand maybe cleaner and my systemsy
Dialogue: 0,0:50:26.40,0:50:30.23,Default,,0000,0000,0000,,colleagues are already familiar with it.\NIt's the obvious target for an academic
Dialogue: 0,0:50:30.23,0:50:35.26,Default,,0000,0000,0000,,project doing it already a humungous\Namount of work. So I think we would love
Dialogue: 0,0:50:35.26,0:50:40.91,Default,,0000,0000,0000,,to know how Linux and especially how\NAndroid could be adapted but it's not
Dialogue: 0,0:50:40.91,0:50:46.26,Default,,0000,0000,0000,,something that we have the resource to do\Nat the moment.
Dialogue: 0,0:50:46.26,0:50:50.71,Default,,0000,0000,0000,,Herald Angel: Mic number on again.\NQ: How likely or dangerous.
Dialogue: 0,0:50:50.71,0:50:55.46,Default,,0000,0000,0000,,Herald Angel: Mic number one is not\Nworking.
Dialogue: 0,0:50:55.46,0:50:59.54,Default,,0000,0000,0000,,Q: How likely or dangerous you think it is\Nfor a programmer to screw up their
Dialogue: 0,0:50:59.54,0:51:05.33,Default,,0000,0000,0000,,capabilities he specifies?\NSewell: So how often will the programmer
Dialogue: 0,0:51:05.33,0:51:10.75,Default,,0000,0000,0000,,screw up the capabilities? So in many\Ncases the programmer is just doing an
Dialogue: 0,0:51:10.75,0:51:17.37,Default,,0000,0000,0000,,access with a C or C++ pointer or C++\Nobject in a normal way. They're not
Dialogue: 0,0:51:17.37,0:51:23.56,Default,,0000,0000,0000,,manually constructing these things. So a\Nlot of that is going to just work. If
Dialogue: 0,0:51:23.56,0:51:28.17,Default,,0000,0000,0000,,you're building some particular secure\Nencapsulation setup you have to be a bit
Dialogue: 0,0:51:28.17,0:51:34.28,Default,,0000,0000,0000,,careful. But on the whole I think this is\Na small risk compared to the state of
Dialogue: 0,0:51:34.28,0:51:40.96,Default,,0000,0000,0000,,software as we have it now.\NHerald Angel: OK. Mic eight.
Dialogue: 0,0:51:40.96,0:51:49.22,Default,,0000,0000,0000,,Q: So existing memory protection\Ntechniques are quite patch-worky, like
Dialogue: 0,0:51:49.22,0:52:06.16,Default,,0000,0000,0000,,canaries and address layout randomisation.\NIs this a system designed to replace or
Dialogue: 0,0:52:06.16,0:52:17.92,Default,,0000,0000,0000,,supplement these measures?\NSewell: I think if you {\i1}pause{\i0} So again it
Dialogue: 0,0:52:17.92,0:52:24.48,Default,,0000,0000,0000,,depends a bit how you use it. So if you\Nhave capabilities really everywhere then
Dialogue: 0,0:52:24.48,0:52:33.24,Default,,0000,0000,0000,,there's not much need for address space\Nlayout randomization or canaries to
Dialogue: 0,0:52:33.24,0:52:41.83,Default,,0000,0000,0000,,protect against explicit information\Nleaks. I imagine that you might still want
Dialogue: 0,0:52:41.83,0:52:48.50,Default,,0000,0000,0000,,randomisation to protect against some side\Nchannel flows but canaries is not so much
Dialogue: 0,0:52:48.50,0:52:51.54,Default,,0000,0000,0000,,on whether you actually do for side-\Nchannel flows - I don't know. That's a
Dialogue: 0,0:52:51.54,0:52:56.50,Default,,0000,0000,0000,,good question.\NHerald Angel: Mic four please.
Dialogue: 0,0:52:56.50,0:53:02.58,Default,,0000,0000,0000,,Q: Thanks for the very interesting talk\Nyou presented with CHERI, a system of
Dialogue: 0,0:53:02.58,0:53:07.53,Default,,0000,0000,0000,,veryfying existing C-software, sort of\Npost hoc and improving its security via
Dialogue: 0,0:53:07.53,0:53:12.45,Default,,0000,0000,0000,,run-time mechanism...?\NA: Improving or Proving? Improving yes,
Dialogue: 0,0:53:12.45,0:53:18.56,Default,,0000,0000,0000,,proving no, yes.\NQ: So what's your opinion on the viability
Dialogue: 0,0:53:18.56,0:53:23.02,Default,,0000,0000,0000,,of using a static analysis and static\Nverification for that. Would it be
Dialogue: 0,0:53:23.02,0:53:29.58,Default,,0000,0000,0000,,possible to somehow analyse software that\Nalready exist and as written in these
Dialogue: 0,0:53:29.58,0:53:34.09,Default,,0000,0000,0000,,unsafe languages and show that it\Nnevertheless has some security properties
Dialogue: 0,0:53:34.09,0:53:40.83,Default,,0000,0000,0000,,without writing all the proofs manually in\Nlike HOL or Isabelle?
Dialogue: 0,0:53:40.83,0:53:47.05,Default,,0000,0000,0000,,A: Well so if you want to analyse existing\Nsoftware... So, static analysis is already
Dialogue: 0,0:53:47.05,0:53:53.03,Default,,0000,0000,0000,,useful for finding bugs in existing\Nsoftware. If you want to have assurance
Dialogue: 0,0:53:53.03,0:53:58.87,Default,,0000,0000,0000,,from static analysis, that's really very\Ntough. So you certainly wouldn't want to
Dialogue: 0,0:53:58.87,0:54:07.43,Default,,0000,0000,0000,,manually write proofs in terms of the\Ndefinitional C semantics, you would need
Dialogue: 0,0:54:07.43,0:54:10.85,Default,,0000,0000,0000,,intermediate infrastructure. And if you\Nlook at the people, who have done verified
Dialogue: 0,0:54:10.85,0:54:15.75,Default,,0000,0000,0000,,software, so verified compilers and\Nverified hypervisor, and verified
Dialogue: 0,0:54:15.75,0:54:25.03,Default,,0000,0000,0000,,operating systems, all of those are now\Npossible on significant scales, but they
Dialogue: 0,0:54:25.03,0:54:30.51,Default,,0000,0000,0000,,use whole layers of proof and verification\Ninfrastructure for doing that. They're not
Dialogue: 0,0:54:30.51,0:54:35.83,Default,,0000,0000,0000,,writing proofs by hand for every little\Ndetail. And some of those verification
Dialogue: 0,0:54:35.83,0:54:42.18,Default,,0000,0000,0000,,methods either are, you can imagine them\Nbeing basically like static analysis, you
Dialogue: 0,0:54:42.18,0:54:47.69,Default,,0000,0000,0000,,know, you might use a static analysis to\Nprove some relatively simple facts about
Dialogue: 0,0:54:47.69,0:54:54.82,Default,,0000,0000,0000,,the code and then stitch those together\Ninto a larger assembly. I think any kind
Dialogue: 0,0:54:54.82,0:54:59.17,Default,,0000,0000,0000,,of more complete thing I think is hard to\Nimagine. I mean these analysis tools
Dialogue: 0,0:54:59.17,0:55:03.34,Default,,0000,0000,0000,,mostly, they rely on making some\Napproximation in order to be able to do
Dialogue: 0,0:55:03.34,0:55:09.75,Default,,0000,0000,0000,,their thing at all. So it's hard to get\Nassurance out of them.
Dialogue: 0,0:55:09.75,0:55:16.87,Default,,0000,0000,0000,,Herald Angel: Okay, Mic one.\NQ: You said you modified an MIPS
Dialogue: 0,0:55:16.87,0:55:22.74,Default,,0000,0000,0000,,architecture to add some logic to check their\Ncapabilities. Do you know what the cost of
Dialogue: 0,0:55:22.74,0:55:30.22,Default,,0000,0000,0000,,this regarding computational power,\Nan energetic power supply?
Dialogue: 0,0:55:30.22,0:55:33.03,Default,,0000,0000,0000,,A: Sorry, can you repeat the last part of\Nthat?
Dialogue: 0,0:55:33.03,0:55:39.19,Default,,0000,0000,0000,,Q: What the cost of this modification\Nregarding computational power, and power
Dialogue: 0,0:55:39.19,0:55:42.30,Default,,0000,0000,0000,,consumption.\NA: Ah, so what's the energy cost? So I
Dialogue: 0,0:55:42.30,0:55:46.61,Default,,0000,0000,0000,,gave you a performance cost. I didn't give\Nyou, I carefully didn't give you an energy
Dialogue: 0,0:55:46.61,0:55:52.60,Default,,0000,0000,0000,,cost estimate, because it's really hard to\Ndo in a scientifically credible way,
Dialogue: 0,0:55:52.60,0:55:59.25,Default,,0000,0000,0000,,without making a more or less production\Nsuperscalar implementation. And we are
Dialogue: 0,0:55:59.25,0:56:03.50,Default,,0000,0000,0000,,sadly not in a position to do that,\Nalthough if you have 10 or 20 million
Dialogue: 0,0:56:03.50,0:56:09.25,Default,,0000,0000,0000,,pounds, then I would be happy to accept\Nit.
Dialogue: 0,0:56:09.25,0:56:15.22,Default,,0000,0000,0000,,Herald Angel: Mic number 7, please.\NQ: How does the class of problems that you
Dialogue: 0,0:56:15.22,0:56:21.44,Default,,0000,0000,0000,,can address with CHERI compare to the\Nclass of problems that are excluded by,
Dialogue: 0,0:56:21.44,0:56:26.68,Default,,0000,0000,0000,,for example, the Rust programming\Nlanguage?
Dialogue: 0,0:56:26.68,0:56:30.46,Default,,0000,0000,0000,,A: So how does the problems of CHERI\Nrelate to the problems, sorry the problems
Dialogue: 0,0:56:30.46,0:56:39.53,Default,,0000,0000,0000,,excluded by CHERI, relate to the problems\Nexcluded by Rust. So if you are happy to
Dialogue: 0,0:56:39.53,0:56:50.86,Default,,0000,0000,0000,,write all of your code in Rust without\Never using the word "unsafe", then maybe
Dialogue: 0,0:56:50.86,0:56:56.24,Default,,0000,0000,0000,,there would be no point in CHERI, at all.\NAre you happy to do that?
Dialogue: 0,0:56:56.24,0:57:00.75,Default,,0000,0000,0000,,Q: Probably not, no.\NA: I think someone shakes their head
Dialogue: 0,0:57:00.75,0:57:10.00,Default,,0000,0000,0000,,sideways, yeah.\NHerald Angel: Mic number 1.
Dialogue: 0,0:57:10.00,0:57:14.64,Default,,0000,0000,0000,,Q: What do you think about the following\Nthesis: We are building a whole system of
Dialogue: 0,0:57:14.64,0:57:21.11,Default,,0000,0000,0000,,things, with artificial intelligence and\Nsomething like that. That is above this
Dialogue: 0,0:57:21.11,0:57:29.76,Default,,0000,0000,0000,,technical level and it's building another\Nchaos that isn't healing with those
Dialogue: 0,0:57:29.76,0:57:34.01,Default,,0000,0000,0000,,things.\NA: It's dreadful, isn't it.
Dialogue: 0,0:57:34.01,0:57:45.70,Default,,0000,0000,0000,,{\i1}Laughter{\i0}\NA: There are, so you might, in fact some
Dialogue: 0,0:57:45.70,0:57:50.32,Default,,0000,0000,0000,,of my colleagues are interested in this\Nquestion, if you, you might well want to
Dialogue: 0,0:57:50.32,0:57:58.82,Default,,0000,0000,0000,,bound what your artificial intelligence\Ncan access or touch and for that you might
Dialogue: 0,0:57:58.82,0:58:03.72,Default,,0000,0000,0000,,want this kind of technology. But this is\Nnot, we are, with machine learning systems
Dialogue: 0,0:58:03.72,0:58:07.41,Default,,0000,0000,0000,,we are intrinsically building things that\Nwe, on the whole, don't understand and
Dialogue: 0,0:58:07.41,0:58:11.96,Default,,0000,0000,0000,,that will have edge cases that go wrong.\NAnd this is not speaking to that in any
Dialogue: 0,0:58:11.96,0:58:17.24,Default,,0000,0000,0000,,way.\NHerald Angel: OK. Does the internet have a
Dialogue: 0,0:58:17.24,0:58:24.79,Default,,0000,0000,0000,,question? No, good. I don't see anyone\Nelse, so let's conclude this. Thank you
Dialogue: 0,0:58:24.79,0:58:28.93,Default,,0000,0000,0000,,very much.\NA: Thank you.
Dialogue: 0,0:58:28.93,0:58:30.29,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:58:30.29,0:58:35.93,Default,,0000,0000,0000,,{\i1}35c3 postroll music{\i0}
Dialogue: 0,0:58:35.93,0:58:53.00,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2019. Join, and help us!