 So hallo, maenai Simon Glass, maenai tawak ti about verified boot in Chrome OS. Little bit about how it works and also how you can do this yourself. So here's a bit of a rough agenda. There's quite a bit of material, quite a few slides. I'm going to go at a reasonable pace. I believe that a lot of it will be familiar. So I'm going to be mostly focusing on the new things. I'm sure you'll ask me questions. I'll leave some time at the end if there's something that's confusing. So I'm going to talk about Chrome OS, how verified boot works in Chrome OS, and then I'm going to step back a bit and talk about the requirements of why we want secure boot at all and also some of the technology that makes it work. I'm then going to introduce a verified boot which is upstream and new boot and the Linux components of that and do a couple of demos. All goes well and then we'll finish off with some resources. I hope you're all enjoying your time in Edinburgh. My first time in Edinburgh I walked into a pub and I said, please can I have a whisky? I haven't had a whisky before so I want the mildest possible whisky you can give me and the barman gave me a LeFrog. I've since learnt that not all Scottish people are liars. Anyway, it's good to be back. So a little bit about me. I've been working with ARM technology for many, many years. I used to work at ARM in the 90s. I had an electronics company for about nine, ten years in the same field and more recently Google Chrome OS working on ARM laptop. So let's start with what is Chrome OS? Chrome OS came about from two forces, the migration to the cloud that we're seeing and computing all over the place and the fact that HTML5 has more and more support for the types of computing things you want to be able to do. So for example you didn't used to be able to do 3D graphics in a web browser, you didn't used to be able to do canvas, you didn't used to be able to do video and audio and so on and now there are frameworks for all of those things. Chromebook is about speed, simplicity and security. Some of you may have seen a Chromebook and you've got a bit more familiar about this material. Chromebook is a normal computer but we've tried to integrate the components of it so that everything streamlined and works together and fits together nicely. And the only thing you get when you start up a Chromebook is a web browser. So there's no applications or anything like that, native applications. We don't want people who have to worry about maintaining their computer. We want it to just work for them and we don't want it to rot over time. Now interestingly about ChromeOS, interesting thing is that the security was built in from the start. It was not put in afterwards and the idea with the security model is essentially that we don't trust any of the applications. Even Chrome, the web browser, we don't trust that. Everything runs in a sandbox and the OS keeps everything isolated. So that's essentially the security model. And there are a number of interesting things that help make ChromeOS more secure. One is that there is a read-only root file system which is cryptographically signed and we know that it cannot change out in the field. And we also have the ability to update it so when we do discover a problem we can update ChromeOS or the firmware. So how many of you have seen a ChromeOS machine? OK, so about half of you. Well, now the other half of you know what it's all about. So why do we do verified boot? Well, a number of reasons. One thing is that by verifying what actually runs we can presumably protect against malware because the user can't install accidentally or otherwise software which can compromise the machine. So it helps to keep users safe. It allows us, it gives us the confidence to send a software update out knowing that it will, that that's the software that will actually be running on the machine that won't be attacked and modified. Now it doesn't mean that the user has to be locked out. It's possible to install keys on the machine, for example. And in fact in the case of ChromeOS you can put it into dev mode which will run whatever software you want. So we're not trying here to have the user buy a machine that they can't actually do what they want with. It's not the intent. What are some of the things we need for verified boot? Well, let's go through them. I'm going to talk about some of these in a bit more detail later. So the first thing is a route of trust. The way this works is that we have to boot something when we start up. When we first start the machine it's not, we're not necessarily in a position where we can check anything with our crypto or otherwise. So we kind of load some software that we pretty much trust. I'll talk about that in a minute. From then on, from that route of trust onwards, every byte of code and data that we load needs to be verified to make sure that it's what we actually set we were going to run. And when we can't do that, when we have software is doing unpredictable things, maybe we can put it in a sandbox so that as Chrome does, for example, with the Flash Player or with PDF and so on. If there's user state on the machine, we have to validate it. So if the user can change any settings when we load them, we must check them to make sure they don't cause strange things to happen. We have to be very diligent to protect against security holes. We have to fix bugs when we find them, that sort of thing. There's no point in having a really wonderful, secure system with lots of bugs in it that somebody can drive through and break it. We want to be able to upgrade the software. The reason for that is if we find a problem, a security problem, we need to be able to do an upgrade to fix the problem. And related to that, we need to make sure the machine can't go back to the old version. So we have to have rollback protection because once we decide that version one is compromised, we don't want to allow any machine in the field to run that ever again. So that's sort of a rough overview of the requirements. So I'm going to talk a little bit about some of these a little later. So I'm assuming that the material I'm going to talk about now is relatively familiar. Most of you know about hashing. What a hash is? Pretty much everyone. Good. Excellent. So very briefly, the idea is to reduce the image into a very small size, maybe 32 bytes. It has to be secure. Now the key thing about the hashing algorithm here is that changing one bit in the image should completely change this digest, the actual hash, if you like. And it can't be possible to modify an image to obtain a certain digest. That's really important because if somebody can change the software and then make it have the same hash as what you said, what there's a software you sent out, then your protection is gone. So that's a really important part of hashing. That's why hashing algorithms are actually quite complicated to devise and why most people use ones that are well-known and known to be pretty good, like these two down the bottom here. And how many of you know about public key cryptography? Great. Excellent. So I can be very brief there as well. So in brief, we have two keys that are mathematically related. If we sign with one, we can verify with the other. And we use this technology to allow us to sign any image we want, to get it out there knowing that the device will only boot images that we sign. So this is kind of everything I'm talking about here relies on this. And a really common algorithm is RSA, and 2048 bits is considered fairly strong. Chrome OS actually uses 8K bits for the initial key bit. That's extremely strong. And the other thing I mentioned briefly is a trusted platform module. So TPM. This is a security chip with lots and lots of features. So it can generate keys, random numbers, it can store keys, that sort of thing. So for verified boot, what I'm talking about here, we don't need all of those things. The main thing we're interested in is rollback protection. And that is where we have a version number for the firmware or for the kernel, or both, that sits in the TPM. And when we start up, we compare the version number that's in the TPM and we don't allow it to boot if the version we're trying to boot is older. So that essentially provides that rollback protection. Once you've ever booted version three, you'll never be allowed to boot version two again. So, as I say, there's lots of other features of the TPM which we don't need to concern ourselves with. So I mentioned about the route of trust. So I'll just talk a little bit more in detail about that. When you turn on a machine in a better system or something like that, it has to boot some code. Now, I'm ignoring for the moment that the SOC has maybe some crypto features that you can use to help here. Let's ignore that and I'll talk about that briefly later. But the initial code that you run comes from memory and has to be assumed to be correct and to be trusted. Now, that's what I call the static route of trust model. It might be the boot ROM, it might be U-boot. Now that could be stored in read-only memory. It needs to be stored somewhere that cannot change after manufacture. And it could also possibly be signed so that the SOC can verify it. So what you do is you put into that root stage keys which verify software you load after that. So having loaded the initial software which you assume to be correct, you then can load further stages. And each one that you load, you verify to make sure that it matches the keys and so on. OK, so those are the concepts out of the way, most of which you already knew. It seems like. So here's how Verify Boot runs in Chrome OS. I'm just going to take you through some of the stages that we have. There are a number of different parts to it. We have firmware, we have kernel, we have user space, and we have some other things as well. I'm going to talk about each of those in turn. So here's the firmware flow. So over here we have the read-only firmware. And you can see there's some various bits and pieces. It's a read-only U-boot sitting here. We have a device tree and what's called a Google binary block which has some data in it. It has recovery mode screens, it has keys and things like that inside it. This is all in read-only memory. So if you've got a Chromebook, maybe you've taken the screw out so that you can reflash the spy flash. Has anyone done that? OK. Of course you have. Everything works on the firmware, so we'd expect that. But there's at least one other person that's done that. So it is possible to do that and then you can do what you like. But once the machine's been manufactured, unless you do that, unless you take that physical step of physically removing the screw, this cannot be changed. The software can't be changed. So what we have here is essentially our route of trust. The firmware may be compromised. We may discover a bug. We may want to fix something. For example, with Snow, the ARM laptop, we wanted to fix a keyboard debounce problem soon after release that was actually not in the firmware, it was in the EC. So we had to rev the firmware. So we want to push out a new firmware for the device. And that lives over here. So the read-write firmware is verified by the read-only firmware using the keys that are sitting in the GBB. And we have the confidence that it was signed by Google and we can boot it. So we jump to that and run it. Having got that far, we now want to boot a kernel. And similarly, with the idea of a chain, we load some keys that this time are in a V block, verified boot block, sitting here. And we use those keys to verify the kernel image here and the command line and things like that. And now we know that the kernel was signed by Google, so it's okay to boot that. And in addition, we want to, once we boot the kernel, we want to make sure that the root disk is valid. I'll talk about that in more detail later, but essentially we have a hash that we store in here, that we store in here and in that same place and once we have that hash, we pass it through to the kernel and it can do that verification. Life is very difficult. Yeah, that's the answer. So, yeah, there's a trade-off here. We would like to be able to update the read-only firmware. On the other hand, we don't want people to be update. We don't want a virus or some problem to update the read-only firmware. So the decision we made was you can't. So we don't have any bugs in our read-only firmware. It's perfect. Yeah, I recommend you do the same approach. Bugs are bad. Okay. So here are the components of firmware. I'm particularly talking about snow, but the same applies this year's Chromebooks, I think, except for one of the x86 ones. So we have Uboot 2013.06. We use the... We're very close to upstream in ChromeOS. There's a Vboot integration layer which connects to what I call the Vboot library and the source code for that is all there. But all of the ChromeOS stuff is kind of in its own sub-directory. The Vboot library was originally written three years ago to work with UEFI, which is what ChromeOS initially was going to use. And it includes hashing functions, RSA, and all sorts of things. Much of which we've been able to upstream into Uboot now. So Uboot has support for TPMs, RSA, hashing, and so on. Not all of it done by ChromeOS, of course. And anyway, we're still using the Vboot library. It's still there, and the source code is available for that as well at that link. The key thing that the Vboot library has that we will never upstream is the verified boot flow. So this is something I'll show you a little bit later, but essentially it's the business of deciding how to boot, whether you're in developer mode or not, whether you can, if you can't boot, how you're going to recovery and things like that. OK. So I mentioned before about the root disk, and some of you may have heard of DMVarity. It's upstream in the kernel. It's essentially a way of verifying a root file system. If you imagine you have a file system and you break it up into blocks, let's say 4k blocks, and you hash each block. And then you pass that great big list of hashes to the kernel. Then every time it loads a block from the disk, it can check it against the hash, right? So it's a very simple concept. Unfortunately, we don't really want to send a huge chunk of hashes down to the kernel. What we want to do is send one hash. So we hash the hashes, and then we hash the hashes, and so on and up to a tree, and we end up with essentially this hierarchical structure here. And at the very top level, there is a single hash value, and that's the only thing that firmware needs to pass to the kernel. From there, we can verify the entire tree of hashes, and therefore the entire root file system. So that's essentially how DMVarity works. So if you're willing to have a read-only root file system, you can use a similar approach and completely verify all the code that runs from the root of trust all the way through to user space. There's also a thing called crypto-home, which I'm not really going to talk about because it's not really directly related to verified boot. Talking about user space, in Cromwell West there are a number of utilities. There's a thing called cross-system, and a cross-system allows you to see what state the firmware is in. So did we boot in developer mode? Are we in recovery mode, to reinstall things like that so we can look up that information? It also allows us to send signals for the next boot. So we can say, please next time you boot, go into recovery because I just had a disk error or something like that. So it's essentially, think of it as a way of communicating between the firmware and the rest of the system. You don't always need it, but Cromwell West has got quite a sophisticated mechanism for recovering from errors and so on, so we do need it there. It's a thing called an update engine which updates the root disk and updates Cromwell West and a firmware updateer as well. And we have a signer which can sign images, as you might imagine. It's a thing called cross-bundle firmware which produces firmware bundles containing the U-boots, the EC images, device trees, Google binary blocks and all that stuff and packaging it all together, compressing some of it maybe and signing it and all that sort of thing. So you can imagine it's a fairly complicated setup. That bit of it. And there are a few utilities to do with images as well. So that's essentially the way Cromwell West operates. Very brief, I understand, very brief overview. There's loads of material available at the website, the chromium.org website if you're interested in more detail on any of these topics. In fact the original design docs for Cromwell West are still there from when it started up. And of course there's a source code that you can dive into the source code and have a look at how any of these things work. Although I have to say that we've been pretty good at trying to upstream most of the stuff and get it into the kernel or U-boot or whatever. OK, so that's all very interesting. How can we do this with U-boot and with the kernel without running Cromwell West? So that's what I'm going to talk about for the remainder of the time. Essentially it's possible to implement a verified boot on your own platform using U-boot and Linux and it can run on pretty much any device. I think the requirements are not that demanding. If for U-boot, if you're not already using fit, do you want to watch fit is? No, OK, some of you? All right, so it's not the Intel firmware fit. It's U-boot thing. So I will explain that in a minute. It's basically an image container format. If you're already using make-image, you can continue to use that because that's what's used for sign-in. If you're already using the boot-m command in U-boot, you can keep using that because it's all plumbed in there. So that's what I'm going to talk about in some detail. De-inverity is upstream, as I mentioned. It's in the Linux kernel, so you can use that without any trouble. And in terms of the firmware user space layer, there isn't really anything that I'm aware of there that specifically helps with this. Certainly you can pass things from U-boot to the kernel using the device tree or ACPI or something like that. Going back the other way, you probably have to roll something yourself, put it into memory somewhere like that. So actually Chrome OS stores has 16 bytes in the EC. That's where it stores the information that flows back from user space to the firmware. So since you don't know what fit is, this is what fit is. It's essentially a, think of it as a device tree which contains images inside it. So if you look up here, we've got a kernel image. We have an FDT, a device tree image. Here's the kernel binary. Here's the device tree binary. We have some metadata and so on. The kernel is being hashed with the sha1 algorithm and the hash will land up in that place there. And down the bottom, we have a list of configurations. Here's a configuration that boots kernel 1 and FDT 1. So once we have that information, U-boot can load that. It can decide it's going to select configuration 1. And once it's decided that, it knows as to go and get this particular kernel and this particular device tree. It's a very simple format, but you can see it's very flexible. We can have multiple configurations, multiple images and so on. So if you're using U-boot and you're not using fit, you should probably have a look at it. So having decided we're going to use fit, how do we add a signature to it? Well, you saw the hash before. We just replaced the hash with this little bit here, signature. And essentially here, we're saying here's the signature that we want to use. Here's the signature algorithm we want to use. When you run bootM to boot the thing, it boots as normal. You'll notice these new things here where it says we're verifying hash integrity and SHA-1 and RSA 2048. So you get these extra lines in the output, but otherwise bootM was working as before. How do you sign an image? Well, we currently use makeImage to make images, to make fit images and other types of images. We can do the same thing. We just use makeImage. We have to tell up the key directory and some other things which I'll talk about in a bit more detail, but essentially we're using the same tool. So let's have a look at how the signing works. So we have our device tree source, our fit source, if you like, that file I was showing you with the config, the kernel, the FTT and so on. We have our binaries that we want to chuck in there. We run makeImage and it produces the fit image over here. That works today. That's what everyone's doing today, if they're using fit. So what's been added essentially is a new signing flow. Having produced this image, you can now start using keys from over here to sign the images that are inside that fit. We're just modifying the fit, adding a few more properties, information that Uber can then use to verify it. And the outputs of that are a signed image, signed fit image, and somewhere we have to put the public keys, which we put into the Uber device tree. So the public keys, remember if you've signed something with the private keys, you have to verify with the public keys. They have to be made available. So what does it look like? Well, this is what you end up with when you sign a fit. The makeImage will put some additional stuff in here. Here's the actual signature here, bit of information about the algorithm and the signer and so on is here. So here we've got two signatures. We've signed both of these images and we've produced two 2048-bit signatures that get stuffed in there. What about the public keys? Well, the public keys get put into the Uber device tree file. That's going to have to go in your route of trust so that it can't be changed because if someone can change the public key, of course all bets are off, right? So this is a bit weird. It's going to look a bit unusual because it's in a kind of internal format. The reason for that is that we didn't want U-boot to have to spend a lot of time taking apart encapsulated keys and bringing in the open SSL library into U-boot. So here it's preprocessed. We're only providing the parameters that are actually needed and all U-boot has to do is exponentiation, which is pretty quick and requires very little code. So I guess you've picked this up but we're using what's called in-place signing. So when we take a fit, we sign it and we still have a fit. We're not required to have separate signature files. There's quite a nice property because you can still just send somebody a kernel image or whatever you want to call it and they can use it. It might have signatures in it, it might not. You're not even to send them multiple files. And of course, I should also say that there was a little bit of a drawback with this which is that we've signed the images. If somebody creates a new configuration and says, hmm, actually I didn't like that image in that device tree, I want to use this image in this device tree. Now both of them have been signed by you but you have no way of protecting against them mixing and matching them and using them in the wrong order. So that's a bit of a problem. So how do we actually fix that? Well, we fix that with configuration signing. So some of you looking at this before were probably thinking, why are you signing the images? You should just sign the configuration. Was anyone thinking that? OK, anyway. So the reason for doing this is because the configuration is what we've actually decided is valid. It's this kernel here in this device tree and this is valid for our platform. If we can just sign that, then all will be well. And essentially this is what's provided. There is an additional option in the verify boot to allow you to do this. And the way it works is it just hashes the yellow bits of the fit. So we're not now hashing the entire image but we're just hashing this metadata, if you like, here. So because the kernel has its own hash we don't need to even hash the data here. We know that that must be valid because of the hash here. So we can actually hash maybe 400, 500 bytes of data and that's enough to protect the entire configuration. Which is quite a nice property and on the right-hand side you'll see there are a list of things that actually need to be hashed. So when you use boot in with configuration signing, this is what you get. As soon as you select the configuration that you want to boot, COMPF1 you get this verifying hash integrity business here. And it will verify essentially that everything looks good so far. And then when you load each of the images the kernel and the FTT it will then check the hashes to make sure that it still looks good and you're done. So now we've got essentially 100% protection. There's nothing anyone can do or change in that fit that would not be detected by the signature arrangement. On the other hand we still have a flexibility to want to sign with a different key later on. You can do that. So how many of you are worried about the code size of this arrangement? Surely it's going to bloat the code size of your boot. Must be horrendous. It's actually partly because of the way that it's been implemented in terms of having all the preprocessing done by make image. It's pretty efficient. It's about 2K bytes for RSA and it's a higher verification code including the RSA fit stuff is about 6K on thumb 2. So it's a very small amount of additional code. If you're not using fit then there's an additional 20K there. Much of which is strings and error messages and some of which you can turn off. But yeah, the overhead of verify boot in your boot is very, very small. And in terms of performance it could verify a configuration on a beagle bone in about 6ms. So it really isn't noticeable on the boot time front either. Chrome OS on a modern SOC will boot through one new boot, a second new boot load a kernel and be ready to boot it in, I'm trying to think, 700ms, something like that. 710ms. So it's not necessarily a slow thing to be able to do. So in summary some of the nice properties of your boots, I'm nowhere near finished sorry, if you're hoping that the nice properties are that it's a very small amount of code in terms of what it adds to your boot it's pretty fast 6ms as I said it uses existing fit format, there's nothing really new there and it uses the existing make image tool existing boot image boot end flow, so it's fully plumbed into what you're currently using with UBoot. And it does support this multiple stage idea so that you can load an image and then it in turn can load an image and so on. So you've already seen the way boot end works but there's really no change in syntax everything kind of, it already has UBoot already had the facility for checking hashes now that it can check signatures there's really not a lot of difference there the main thing that's slightly odd is the configuration checking which happens right at the start of boot end but it's no big deal it's all automatic. So now I'm just going to do a quick demo I'm going to show you two things first of all I'm going to show you sorry can we switch to the camera sorry so here's Chrome OS booting up on a little laptop so if some of you have got a machine you've seen it doing that and it comes up with the screen what you may not have seen is that if I boot it into recovery mode the machine will come up in this state where unfortunately it's not really legible that looks like Japanese but it's in fact English but essentially we're on a screen here where we can flip between different languages and it's saying we're in recovery mode please insert an SD card to get a new operating system so we're sitting here in new boot and what's called recovery mode waiting for the user to install a card and when they do we will boot that and copy over the new operating system and similarly if I want to I can change into developer mode again in Japanese this is actually honestly is Japanese and from there I can select developer mode and from then on for all time until I change it again I will be booting in developer mode so that's kind of the firmware interface when I talked about cross system cross system sees all this information once you boot through the user space it can see it, it can adjust it and change it and so on and still on the camera I'll just show you this little thing here actually I need to to show what's going on there sorry let me just try this so can we see that oh that's the camera um yeah okay can we go back to the computer please see if I can play this video or not doesn't look like I can oh yeah okay so that's it booting oops sorry I don't know what is wrong here but it just might just be my very small screen I'm not really sure this is it booting on a beagle bone which I have here um and when the machine when the thing starts up it will um boot normally with the thing and you can just see my high life up there the sha one verifying the hash integrity that means it's running happily and it boots some of you maybe can see this screen here um if I boot with the key held down the enter key in this case it's going to boot the second configuration unfortunately that doesn't boot and the little light will flash and it sits there forever flashing the light you can see the GPIO perhaps on the screen flashing so that's just showing it running on a beagle bone it really has no effect on the standard operation of the device it's just normal u-boot and normal scripts and everything else I didn't have to change anything other than I took a fit and added some signatures to it so it was pretty straight forward okay I'm just going to go back to my slides so um some other things you can do many SACs have accelerated hashing so they allow you to do hashing very quickly using built-in hardware you can use that they even some have public key crypto which is also can be used um you can do an auto update feature useful if you think you're going to make a mistake and want to update in the field or even to add new features this is the recovery mode that I was trying to show you with Chrome OS a little bit hard to see but if you've got a Chromebook you know how to go into recovery escape refresh power it's perfectly harmless go in there and never look around some SACs have on-chip crypto very much but if they do then perhaps you can have your route of trust be in read write memory but be verified by the on-chip crypto you probably need to talk to the SAC vendors to make that work um you can see that you can make it go fast there's really no issue there and you can use a TPM for rollback a new boot that's support for there's a TPM library and you can use that to define a rollback space that is in there and you can even implement a trusted boot where you tell the TPM every time you load new data or new code and it can verify that that's good so in summary verify boot you can enable it in an embedded system with very little code or execution time penalty and you've got a lot of features in there for hashing and all the different things that you need and if you can put up with having a read-only root file system you can use de-inverity essentially to completely protect the user and that's the end I've just got some links there if some of you are interested in looking up some of this material in a bit more detail I realise this is very much of an overview but hopefully it's given you some way to look and if you like you can ask some questions does anyone have any questions in a branch yes yes so here's the way that Chromebook development firmware development works obviously we have a very limited time to get the product out and particularly towards the end of the project we have bugs to fix so we end up on a branch we then work hard to upstream the code and get it into mainline they are quite different they are quite different so the branch I mentioned 2013.06 really bears no relationship to the one 18 months earlier so for the Chromebook this year we threw all that code away we took and taken the upstream U-boot from June and we started adding patches for the new SoC and so on so for Snow for the last year's Chromebook you've got to use the branch it is actually possible it does boot on mainline I don't think it's sort of there's a couple of errors and problems and it's just not quite polished that's for sure there's quite a bit of stuff going upstream if you watch the mainlist in fact there's 5420 stuff going into U-boot now so there's an effort to do it it's kind of tricky because I don't know once the product ships you kind of take a breath and you can start looking at these things while it's happening it's kind of tricky so the root hash essentially if you think about the root hash it's the hash of 50 hashes below it on the level below now we provide that root hash from firmware yeah it's actually that root hash is signed and protected against being changed no one can change that so having made that protected it's impossible for anyone to change the ones underneath and so on and so forth I mean one of the nice properties of hashes is with sha256 or sha1 you can say well I'll hash this and it's just as protected to say that I'll hash this and hash this you can have a chain of them and it's perfectly safe it's considered quite reasonable to chain the hashes yeah essentially so okay well there's two reasons one is that if you wanted to so let's say you just had one 32 bit hash for the entire file system there's an increased risk of collision let's ignore that for the moment but you then have to read the entire file system in to verify it because you can't calculate the hash until you've got all the data so with the hierarchical method you don't have to do that you can just read in the first the small number of rows of hashes and verify from there so yeah it would take a long time to read a gigabyte of memory just to verify your hash and the second reason is that because it's not directly related to verify boot but the auto update works on blocks the auto update comes in it doesn't update every single block in the XT2 file system only the ones that it wants to change it essentially sends a delta down to the Chromebook and of course if you're updating only some of the blocks then it's nice to only update some of the hashes as well so that's why that is the way it works is that here's your partition here's your file system here's your hash, that's it at the end and yeah they're stored in the same partition but separate from the file yes, every time you read a block you compare it against the hash so the de-inverity essentially does that it reads a block then it reads the hash and then it hashes the block and it compares the two and if it fails it reboots yeah you're up at the start of the root well you kind of do you have to read the root you have to get the root hash you then have to go down a level and read all of those and then from then on whichever blocks you read you're going to have to read the hashes that lead up to it you know what I mean yeah it's sort of a separate issue though if you want to squeeze it up that's fine I think we don't no I mean on the ARM Chromebook it loads about 90 megabytes to get up to the login prompt and I think it's about 1800 hash blocks so 1890 hash blocks so it's fine it takes about a second to read that on a fast MMC you had a question why why so thinking about the objectives of Chrome OS there is a there is the idea of being able to remote attestation where you're saying I promise that I'm running this code and there is we have a little bit of that to do with Netflix and so on but for the purposes of Chrome OS trying to verify what actually gets booted this scheme works perfectly fine we don't use the TPM I agree we could use the TPM a lot more mind you the TPM is a dog you know 550 milliseconds of boot time on snow is due to the TPM so it's not it's not necessarily something we want to use more unless there's a good reason and at the moment there really isn't someone at the back yeah well GPL refers to the source code and the you mean ah yeah well it's not actually encrypted it's verified yeah yeah I mean the interesting thing is when you flip to developer mode it doesn't have to rewrite the image or change any of the software on the disk it's the same software it's just now not being verified so previously if you changed something on the disk boot it would die and tell you you've got a problem and go to recovery mode if you're in developer mode it doesn't there's certainly nothing the encryption I mentioned if that's what you're talking about is to do with the home directories we didn't want obviously user data to be visible to other users so yes there was encryption for the user data but that's ephemeral anyway on a Chromebook you could blow all that away create a new user login and all the data comes back down from the cloud so half of this the second half of this talk about uboot and linux and how you could implement it yourself that's all using upstream uboot code and that's gpl2 plus that stuff so you should be fine obviously I'm not giving illegal advice but that's certainly the intention of what I've been showing here everybody else happy? well thank you very much