 All right, morning, folks. Can you hear me on everything? All right, good stuff. OK, so virtualization, packed room. What does this always happen? You know, your moment to put that word in the talk, suddenly the room becomes full. Yeah, lots of attention. Everyone likes it. But no one's really thinking about it seriously. So we're going to think about a little bit more today. First of all, what we're going to talk about are mostly known issues. We don't really even have to get into the unknown stuff to find just tons of reasons why running it right now may not be the best idea. These are design flaws. These aren't just things that are bugs that are just easily fixable. Not all of them are just simple bugs. Not all of them are exploits. Some of them are just simply because the way they were designed. They weren't designed to perfectly virtualize. And because of that, we have security problems. And because of this, some of this is just documented behavior. And let's see. So slightly less testing because it's not like there's 20 new novel exploits here. This is very simple stuff for the most part. We didn't bother to test on all of the VMware products that I'm going to talk about. So really, the worst thing about why I'm here today is that I don't even need to find things that we don't know about to be up here today. There's just the stuff that we do know about and just the stuff that's sitting there in the documentation that no one bothers to read. Just that makes the position virtualization is in absolutely untenable. So now you're sitting here and I've just told you that I'm not releasing any new cool stuff. That this is all in the documentation. And then this is boring. And you've got this feeling of betrayal, right? Because there was this talk and it had virtualization in the title, so you knew it was going to be cool. And here I am, and I'm just going to give a boring talk. OK, so hold on to that feeling of betrayal and take it out whenever you hear the word virtualization from now on because we could use a little bit more skepticism. As it is, I don't think the talk's going to suck. There is some stuff, and we are bringing some new stuff into it. So stick with me. And it's just that each of these individual issues may be documented, but when you combine some of them, just create situations that just aren't right. So first we're going to start out with a little review of where we're at with virtualization, what types of technologies we're using, how everything's set up, categorize the different things, explain what features there are, all of the basic virtualization stuff. So in case you walked into a talk on virtualization without knowing anything about virtualization, you won't be completely behind. Unlikely, I know. Then we're going to explain why isolation just, so everyone claims that there's isolation. Yeah, it doesn't happen at all. And so when you talk about isolation, you've got to touch on covert channels just because the NSA loves to worry about covert channels. No one's saying worries about covert channels just because you can't eliminate them. There's just too many. But we're going to touch on them just because there's just so many fun new ones. Then we're going to look at how virtual machines on a network are different than physical machines on a network. And then we're going to look at how merely having a virtual machine server on your network is going to have to change the way that you architect your network. Because you just can't build it the same way anymore. You can't rely on the same firewalls you were using. You can't rely on the same switching infrastructure. It just isn't there. Then we're going to talk about live migration, plain text. I think you got the idea of where we're going with this section. And then this is actually going to be in the Q&A room. But you can go ahead and question, heckle, or propose grandiose things and accuse me of hating freedom. All right. So on to the technology overview. First, we've got the OS level virtualization stuff, which is your Solaris zones, your user mode Linux, your OpenVZ, they're basically glorified FreeBSD jails, which really descended from other stuff. They're just basically stricter partitionings of operating systems. They're not really incredibly revolutionary, but they're cool. The OpenVZ, for example, you can still do all the migration stuff, and you get all the features that you get with virtualization for less overhead. So that's pretty neat. Paravirtualization is basically what Zen's doing now. And there's a couple other minor tools that use it, and this is essentially where you cheat. And instead of actually just running the operating system, you modify the operating system and then run it. Good concept, lowers the overhead, but you have to be able to cheat to make this work. And of course, Zen, if you have hardware support, can do full virtualization. KVM works on that, too. That's in the mainline Linux kernel these days. It was just incorporated so quickly because all you needed was, as soon as you had this hardware virtualization support, it was only a little bit of code that you needed to add to the kernel before you could do full virtualization, which is pretty cool. It doesn't have quite all the features that the others have, but it is still full virtualization and a couple hundred lines of code. And then the full virtualization without hardware is what's been going on the longest, and that's VMware's products. Fabrice Belard seems to just kick out a new utility that rocks the world every six months, and one of his last ones was a module for QMU that does virtualization in a similar manner that VMware did. I don't know about this guy. He just sits there and writes things, and they're good. And then of course, full emulation, which isn't virtualization at all, but is really where it all came from. Originally, it was emulating, and this is the only thing that really allows you to run something that's compiled from one processor on another. So that's the basics. And the features that we're getting are the fact that we can freeze an instance, thought later, and snapshot an entire state. That's one of the big ones. It's one of the first ones anyone implements, and my notes here don't seem to be helping me at all. And you can also decouple it from the hardware. So now it doesn't really matter what hardware you're running on. Now this is a double-edged sword, and we'll get to that later, but the advantage is that if your servers aren't all the same, you can still have VMs that just don't care. And it's a big advantage in many ways, and it'll kill you and some others because you can't actually use your hardware. And then theoretically, it adds another layer of protection. You have another partitioning scheme that you have to bust through to compromise the entire data on the machine. And we'll talk more about that in a moment. And then there's live migration, and this is the big one that all the folks like to deal with now, because it's one of the more recentish features that you just take a VM running on one machine, and soon it's running over there. And so that's your basic live migration feature. People do it in different areas of real time, and some call it live migration, some call it hot migration, some call it cold migration, but generally it's all the same shit. Dynamic deployment and creation, this is where your marketing droids tell you that you absolutely can just dynamically send these VMs out and you have a completely scalable environment and you don't have to remember anything about hardware ever again. Sounds perfect, doesn't it? Yeah, so that's where the hype comes in. Reliability, hardware goes down, we just move it across, it's fine, it's great. Consolidation, we can just take as many machines as we want, use less of them, and better utilize the hardware we have. This is really, really the point that all the new Linux distros are selling their virtualization technologies on the most because it's the point that paying customers are most interested in, which is spending less money. We're gonna examine this. It doesn't really make a whole lot of sense because to me if your web servers are getting hit really hard, assuming that your database servers wouldn't is a little bit of a weird assumption. Your peak times would probably be your peak times across all of your hardware and not just one particular segment. But hey, these guys have a theory and they're right sometimes, but they're not always right. And then isolation is where you take different things and you just put them in their own little compartments and they can't talk to each other, it's great. You're never gonna have security problems ever again. Well, yeah, right. So let's attack that. First of all, you have the shared hardware attacks. You're sharing this hardware and you just are never gonna be able to get around that. Any point at which you are sharing hardware and you are not perfectly doing it, you have a problem. And right now we are not perfectly sharing a lot of things. One of the biggest things we're not perfectly sharing is video cards. That's gonna come up later. Basically, all the specialized hardware you have in your machine, you either have to share it or not worry about it at all. You can't hear? All right. Is that better? Yeah. Okay. All right, so the attacks on symmetric multithreading, which is more commonly known as hyperthreading, where the attacks that were basically compromising GPG keys based on the traces left in the L1 cache of Intel's processors. Now, this is old news. This is nothing we don't know. The only thing is now with virtualization, you're compromising something that should have been running on a completely separate machine. So the fix, and it was a very stupid fix, but the fix was to just put processes of the same privilege level running at the same time on the processors. Well, now with virtualization, you can't have any virtualization processes running together on the same process as either. So you've really got a mess when you have this symmetric multithreading stuff because to do it securely, you have all these contacts sitting on your processors and you can't use them. You can't use them effectively. Virtualization is supposed to provide higher utilization of hardware and you can't use the contacts on your chip just because the stuff left in the L1 cache, the stuff left in the L2 cache, it's gonna compromise data and you can't have that leak. And if we're only thinking that this happens in the trace cache, we're deluding ourselves. We've got video cards with caches. We've got disk IO. We've got all kinds of weird little timing attacks that are out there that you can quickly and easily just look at the timings and you can at least divine something about what some other machine is doing and whether you can divine in exactly what data they're passing or not is something that remains to be seen. But just the fact that you can divine that it's having some effect on the hardware is something you shouldn't be able to do. And that's easy to do. Actually pulling data out from it, it's not gonna be much farther. I mean, we thought the SMT attacks were just completely impossible until this guy wrote a paper and started sniffing GTPG keys and then it wasn't theoretical anymore. So there's this paper and it's, let me find it here. It's a fairly recent paper. It's a very good one about some of the vulnerabilities in the Linux scheduler. In particular, it has some interactive things. Basically you can trick the Linux scheduler into assuming a processor is interactive and giving it a higher priority. You can context switch mid tick and not get counted as part of the scheduler. The paper, by the way, is called secretly monopolizing the CPU without super user privileges. Good paper, you should check it out. But the point is, this can happen in VMs too. Now you have VMs. Anytime you ever get a compromised VM, that VM is stealing scheduler cycles and you're not going to be aware of it because the scheduler under the current Linux scheduler is not even going to be aware that this thing is taking the cycles it is. I know this is, without really going into the paper, this sounds like just black magic. But basically the scheduler is designed as, it measures on every tick. But it doesn't measure on every context switch. So if you context switch between each tick all the time, you never actually get shown on the scheduler as being run. This is problematic, especially when your VMs at the top level are just processes. So you can load a kernel module and spoof interactivity, and now your VM has more priority than it should. And then there's the actually using hardware. Zen has some nice functionality to allow you to actually use directly hardware inside one of the VMs. So you can pass it through a video card and you can get your full 3D games just right on your screen and it's beautiful. Except anytime you pass hardware, you pass a networking card, any of this hardware that you pass, any of those VMs can now wedge the box. If you have access to the PCI bus, you can wedge the box. You're done. It's over. So what has happened is there's been some advancements. VMware Fusion is a recent one that was really good at learning how to share these devices appropriately. So that's targeted towards sharing the graphics card and it's passing open GL messages back and forth and basically doing proper sharing of the graphics card. They also do a pretty good job with USB. But when you actually start to pass PCI devices, if you actually wanna use any of this specialized hardware that you have on your machine, you can't do it in a VM. And we keep on hitting our heads against a wall on this and passing PCI devices is not the solution because that just entirely ruins isolation. And now we're just gonna briefly cover covert channels because they're fun, even though no one really cares about them too much. The most common covert channel is simply to use a bunch of resources. You use memory, you release memory, you use memory, you release memory, coded pattern. And then you just detect it on another. So now your machines are talking to each other without you ever being able to tell. Unless you're looking very carefully at memory usage, network usage or obscure things, you're not going to be able to tell if your VMs are talking to each other and they've been hacked. Usually you try in with real hardware, they at least have to go out of the hardware somehow and there's only some narrowly defined avenues where that can happen. Usually it's a network card, usually it's some central service of some sort which usually runs across the network, but to some extent you can just monitor that one place and catch most of the covert channels that your machines can actually communicate between each other with. Soon as you have VMs, they can communicate all they want and it doesn't even matter. You can even pass data raw on ethernet frames. So you can, because right now, currently, with multiple boxes, you put a Cisco switch in the middle of it, you tell the Cisco switch don't route anything that isn't IP and you don't have IPX streams that you're not seeing going across your network. Now with virtualization, you've got a virtualized network. Doesn't quite have that feature. So you're sitting there and you've got IPX streams, Apple Talks streams, even Ducknet. All of this can be used and you can use all of this and have your own little secret communication network. IP tables isn't gonna catch it. And quickly, a show of hands for people who actually use EB tables anywhere. Okay, we got one, two, okay, a couple more, but generally the gist is not a whole lot of you do. How many people know what it is? Okay, more. EB tables is IP tables, but for layer two. It will actually set up rules on the ethernet level and this is really the only thing that you're going to be able to use to protect you from this kind of stuff. So you need to be making EB tables rules every time you deploy a VMware server or a Zen server or whatever and no one's doing it because no one even realizes, you know, IP is king. No one remembers the other protocols that were out that just don't get blocked by IP tables at all. So we need to be using EB tables and we're not. What's even worse is in some places you actually can't use EB tables to solve any of this stuff because you can bypass the host firewalls fairly easily. The most common way to do it with IP is you just pick a different IP. There go your carefully configured hardware firewall rules and you're carefully configured software firewall rules. They're just out the window because you just hop to a different IP and it's entirely different. So what are you going to do about that? I mean, are you going to block an entire IP range? Some of you might be shouting that VLANs are the way to go, right? We just put everything on its own VLAN and it all works out. Except to actually make the virtualization technology use VLANs, you have to extend VLAN taking into the virtualized network, which means you have to extend VLAN taking all the way into the host. So if you compromise the host, there goes your entire VLAN setup. You're done. So VLANs, maybe not the best place to fix this. You know, and that's assuming that it's even implemented. And the only place I've seen VLANs really implemented strongly, Zen 3 has them, but they're just internal to the server and VMware has them, but you have to import VLAN taking all the way out to the box. Now here's the ridiculous thing, is before I was talking about how you can use EB tables and you can save yourself from some of this stuff. Well, by default VMware server has three different modes for your networking device. You've got a bridge mode, which basically means you can use a real IP address. You've got a host only mode, which means it's useless. And you've got a NAT mode, which means it's useless for at least running servers. So bridge mode is pretty much what you want to use. And in that mode, by default, you do not go through IP tables and you do not go through EB tables. You just directly emit frames right out the device. Yeah, it's a good question. I really don't know why they designed it that way. I have a feeling they were just pushing things in and out of the tongue tab devices, and they weren't actually thinking about it in terms of filtering. You'll be glad to know that Zen does things a little differently. It actually uses the full-featured Linux bridging interfaces and the full-featured filtering interfaces. So that doesn't happen on a Zen server, yeah. It may have been developed before EB tables existed, but it wasn't developed before IP chains existed. And it bypasses those two. It bypasses the entire net filter setup of the kernel. So you can't filter anything. Even if you assume the IP addresses are right, your filtering is shot. So now the only thing you have to rely on is your hardware firewall. And seeing as your hardware firewall can't tell one virtualized interface from another, you haven't done much. It has gotten much better in ESX, and I'm really waiting for them to push that to the rest of their products, because that's the only place that they have this, is in ESX. Yeah, I know. This feature, it seems really bad to make money on actually bothering to create a release of your product that's secure. That just doesn't sit very well with me. You know, I'm fine with them making money on having some extra buttons and some extra snapshotting features. That's great, but actually ruining the security of your virtualization software and then advocating that people still use it. But if you want to be secure, you've got to buy an upgrade. It seems a little bit wrong. Right, because testing environments never get hacked. The question was basically that VMware only advocates use of VMware server in testing environments and not entirely for production servers. And I don't think that's legitimate. You know, testing environments get hacked just like the rest of everything else and passwords leak into those just as much as anything else and really those are very fertile grounds to find information and compromise production machines from. Well, there's a room devoted to questions, but where is this next one? Okay, shout it. So I forgot to mention this at the beginning. I've only really studied virtualization closely on Linux because that's the platform that I find the most serious use of it being on. The Windows guys have their own completely separate world. It is the same, okay. So yes, apparently it is the same. All right, so promiscuous mode is funny too. Even since VMware rewrote the networking stack, it still says in all their security documentation, don't use promiscuous mode. That doesn't seem like the proper response either. Just simply shouting don't use promiscuous mode is probably not the answer. The answer is making sure that when you do use promiscuous mode, it doesn't actually give you every packet on the device. Right now, again with the bridging in VMware, you sit, you pop the interface into promiscuous mode, you get your host traffic and you get every other VMs traffic sharing that same bridging mode. That just doesn't work very well. They can all read each other's traffic now. Exactly read each other's traffic. All the traffic coming in, all the traffic going out, and more importantly, you can read the host's traffic. Since you can take any IP you like in your hardware firewall or anyone on the other end doesn't know the difference, spoofing becomes pretty easy. You just look at the packets coming in and send your responses going out. So if you wanna compromise, say, I don't know, something on the host to crack into the host, but it's fairly easy if you own a VM. I mean, networking folks, you gotta be careful with it. There's, you know, people have analyzed virtualization technologies from going directly using very weird processor hacks and very weird operating system hacks, but the door's wide open in the networking. It's just all sitting there waiting to be compromised. And I'm being a little bit melodramatic there. It's not entirely, you know, just, you know, one shell script and you're there, but it's not too much far. If you can spoof any IP address coming from that server, you've got a problem. And, you know, I should also mention that you can impersonate whichever Mac address you'd like too, so I don't think Mac filtering's gonna help much by any standard. You've, the thing is ESX, again, did redesign their networking stack and did include some options to prevent Mac spoofing. Anyone wanna guess if they're on by default? Yeah. No, not at all. So, wow, that green looks different. Anyways, so here's our generic VMware model and this is really, you know, not to pick on VMware, but this is really, we're gonna go through the default VMware model, which it can be changed to a much better model and there's ways to do that. But this is really one of the worst ways you could set things up and we're gonna go through what's wrong with this and then we're gonna show the better virtualization model and then we're gonna explain what's wrong with that too. So, right now here you've got basically a bunch of VMs and each has to be trusted entirely to have their own entirely separate network firewall. You have to trust each VM to maintain its own and not get compromised. If any VM gets compromised, your hardware firewall can't help you and the host firewall can't help you because VMware's interface just bypasses it. And even if it doesn't bypass, you can have IPs and do all kinds of fun things and for the most part get around it. So your sphere of trust is really, you've got all kinds of them. You don't just have one place that you can go and filter everything, you have to make sure every single filter works or you have VMs running rampant across the network. Yeah, I think there was, anyways. So here's the models then uses and the model that you can convince VMware to use if you take all of your VMs, assign them a different VM adapter and put them all in a bridge and basically force VMware to do things exactly the same way as then does it by default. And here you have a nice model where you've got all your VMs and they all go to a central place and you can filter, you can examine and you can basically do anything with the packets there that you need to. And that goes for the host too. So you can look at all those interfaces. You can use EB tables with impunity. You can use IP tables with impunity. It's all right there. So that's pretty good. But now let's look at what happens when you stand back and even when this model, when you try and put it on a network, you actually have to end up redesigning the network. So here's our traditional network setup. You've got each computer going into a switch, hopefully with filtering capabilities. So you can't pass Layer 2 traffic. You can't just pass weird things between VMs. You can't just change IPs or change MAC addresses on your links without someone noticing. You can't just do whatever you want. You have to be a little bit more careful. Now, that's what it looks like with virtualization. So let's pretend we're trying to firewall these for a moment. And we've got our darkest green as our high security VMs and our lightest green as our low security VMs. And we wanna make sure that, say we're even doing malware analysis on one of these. Say we're doing malware analysis on the two light green ones in the upper right there. So those we know may be compromised. And we don't want it to touch the high security one there. We can do absolutely nothing to prevent it from doing that. In terms of networking, we have very few options. The host can't do a whole lot. You can do more with the Zen model than you can do with the VMware model, but you can still hop IP addresses and hop around enough where you're likely going to be able to subvert the host-based firewall. You need a hardware backup and you don't have one. You certainly don't have different VLANs without extending VLAN taking out to your hosts. And then any time one of your hosts gets compromised, which will happen quite a lot if all your VMs can read whatever the host is sending in and out and spoofed with impunity. You know, you have no VLANs. You have none of the traditional protections that we rely on every day to keep our network secure. Every network has a network firewall. Now, you could argue and you would probably be correct that none of these network firewalls are living to the capabilities that they should be and that they aren't doing as much as they should be and that they only repel attackers a little less brighter than a ham sandwich, but in the end, these are still a critical part of the infrastructure. And with virtualization, they're mostly gone because you have a virtualized network now. And you can talk within that virtualized network without ever touching hardware, at least switching hardware is what I'm talking about. And the virtualized network just isn't the same. So now let's touch on live migration, which given that we've established that you can spoof, that you can do whatever you want with the network, I think we've established fairly regularly that the network can never actually be trusted. So it would seem unwise then that all of the major VM virtualization manufacturers say in every single manual that they have, that you should never run live migration on an untrusted network, ever. And there's a good reason for that. And that's because Zen doesn't bother to encrypt anything. So your entire memory contents are flying across a network that I think we just established pretty firmly, isn't secure in the least. Not even a little bit. And your entire contents of the memory and the disk are flying across that same network. Just waiting for any compromised VM to snatch them out and go through the data just as you want. Now, I was gonna release a tool to make this easier, but then I just realized that this is basically, you know, IP dump and grep. So I didn't think we needed a tool for that. I think everyone has those two down pretty well if you're at DEF CON. And here's VMware. And it's surprising in that it has, you know, an optional hardware-based SSL, but they still stream in all their manuals that you shouldn't run it across untrusted networks. Why do you think that is? Do you think that the SSL is turned on by default? Do you think that the certificates are typed in and verified by hand? Do you think that they're verified at all? I don't know, good questions. Ask VMware. Yeah. No, I should have had a little bit more for you there. Sorry about that one. But from what I know, the SSL is not enabled by default and you do not type in certificates by hand, so there's not a whole lot of verification going on. And we've seen in the past how easy it is to, you know, get an SSL certificate and fake it. And, you know, actually asking people to go ahead and get real SSL certificates to move their VMs around. You think anyone's gonna go jump on that right away? I mean, how many SSL websites do we have around compared to the non-SSL websites? Probably not the best choice. So OpenVz, which is, again, one of those OS level virtualizers that is mostly targeted towards Linux is really at the top of its game here. It uses SSH, it does everything right. The authentication goes across an encryption, the contents go across encrypted, and you just have one little problem. And that is, is that each of these hosts have public key, no password, SSH keys to each other's root accounts. So, you know, defense in depth, right? You know, you've got the defense between any compromised host and then you just give them everything, right? I don't think that's actually how it works. And so then there's also IBM's VM stuff and their previous iteration was, yeah. So that's a very good question and I've loved the use of SSH force commands. They've helped me a lot in the past. What's the question? Oh, I'm sorry, right, no speakers, or microphones rather. Yeah, so the fellow on the front here was asking whether if you can use SSH forced commands to help aid the migration process so that if you compromise the key, it isn't completely a bad thing because it can only run that one command and it can only migrate anything it wants in and out of your system. Oh wait, right. So that's the problem with that. Even if you can use SSH force commands, the fact that you can completely control what the server is running is probably still enough of a problem where where you don't wanna do that and rely on that. But yes, you would wanna use force commands just to limit your scope and so that you're not necessarily directly compromising the hosts right away. That would help you if it works. I haven't been able to check into that. You should, it would be awesome. Let me know. But yeah, generally even if that does happen, you're still not really entirely secure. So IBM's VM stuff, their last iteration, the live migration features were in plain text. It wasn't as great as really we'd expect from IBM who's been doing virtualization for, oh what, 30 years now? You know, you think they provide a solid live migration and they're about to rewrite everything. So we'll see. We'll find out at the end of 07 whether they've done a good job. I have hope IBM does this usually pretty well and pretty right, you know, and their new power chips, this is their big thing now. So we'll see. Any IBM engineers in the audience? This is one thing I'd really like to see in your product. Like really like, yeah. Oh. So I don't have as much experience with IBM virtualization as I'd like to be correctly answered that question, but everything I have seen of their virtualization products, they do a pretty decent job. And I know that the people around me who do use those products are very happy with them. I was very disappointed to see that they didn't actually bother to encrypt live migration. And I think that that's a failing that I hope they'll remedy. They usually do a pretty good job and I think their logical partitioning from what I've seen is decent. And really, IBM does better than anyone else because they carry on the partitioning, not just in the CPU, but in every piece of hardware they produce. They really do a good job at doing virtualization correctly on all of the hardware, not just the processor. And that's a big bonus for them and that really helps them out a lot. Okay, so I had that stamp on my presentation that said I was gonna release a tool. So I can't get up here and not release a tool, although I wasn't exactly saying that I was going to release a very good tool in my CFP, but you know how these things happen. You get the stamp and so here it is. And basically what this does is it actually changes, it does all the necessary prodding and polling to pull apart VMware's networking model and fit it into the same ones then does. And it really, it applies some EB tables rules right there for you by default and it's a nice little script just to help you out in terms of those last details. You might wanna check the ordering and you might get a few error messages. The error messages should be fine, the ordering might not depending on how your interfaces are set up. So the thing that I do usually when I run this script is I set up a cron job to do the exact inverse five minutes later and if I can still contact the machine I delete the cron job after I run the script. Might be good for you. Anyways, I know, not a very good tool. Okay, so summary, wow, that was fast. I should have had my notes with me. We have this little OLPC here and it was supposed to carry my notes but somehow when I transferred them from this to that I got an old copy and so since there's some time at the end after I do the summary I'm just gonna, does anyone wanna see the OLPC? All right, that's what I thought. So that's what we're gonna do and you can ask the QA questions in the QA room. It's the track two QA room out there. Okay, so summary, VMs are still neat but the people that make them live in a world without attackers and yeah, it's just not gonna work. Tribule issues never become more trivial so even if you think those hyperthreading attacks are just way out there and no one's gonna be sniffing GPG keys, well, tomorrow they will probably be sniffing your Mozilla password cache and maybe you guys don't like your Mozilla password cache but some people do and it's becoming more important and folks, pushing VM technology really need to put security earlier in the design process and really incorporate the full virtualization aspect and consider exactly whenever they make a compromise on anything that they're not correctly virtualizing the security impacts of it. Okay, and so now for the old PC. All right. You hate freedom. I do hate freedom. I hate freedom with a passion because it's just so free, it bothers me. Actually, I don't hate freedom at all. Okay, so we've got this little thing here and I don't think that any of you can actually see it. I would plug it into the thing but there's no actual VGA port so I'm just gonna give you a rundown on the hardware seeing as that's probably the best thing that I can do in such a limited viewing space. So, this is your standard OLPC. Pretty light, pretty rugged. The first thing you'll notice if you ever get your hands on one and I hope you all will because they're cool machines is that the first thing you have to overcome is opening the OLPC. It's harder than you would think especially for a machine designed for children. So, now this isn't a terrible problem because you have to seal it somehow. This is why it's hard to open is because it actually has a tight seal. You just have to get used to it and then once you know how to open it it's actually pretty easy. So most people push on this right here, this little green thing in the center of the white stuff and that's the hinge so that's not a button. So what you gotta do is you gotta take this little thing and tweak it over here. You gotta take this little thing over here, tweak it over here and push it down and up comes the screen. So now you've opened the OLPC. Now what else can we do? Oh yeah. So now what else can we do with it? The hand crank has been moved from the OLPC to the power adapter in places where a hand crank would be needed. So in places with a pretty stable power supply you don't bother to buy the hand crank on the actual thing. And this was done to put a little bit more, the newer version is gonna have twice the memory that this one has. It's gonna have a faster processor. It's running a little AMD Geo processor and I think the final specs is it's gonna be 433 megahertz, fully x86. You can run all your games and programs on it. May not be very fast but you can run them. Anyways, isn't this nice? All of the features of a tablet and a smaller form factor. Yeah, no, not the actual tablet. But all that screen stuff, it's just so very neat. And these little things sticking out of the top, I don't know if you guys know that those are wireless antennas, not just some weird designers fantasy there. So now we've got our small, doesn't work very well when you rotate the screen with one hand. So we've got this keyboard here, which is your nice rubber keyboard with the outlines of the keys here. You have several things that you don't find on a normal keyboard like a view source key and a key to activate the webcam. Oh, did I mention the all PC has a webcam? My laptop doesn't have a webcam. It's this little thing right here. It's actually pretty good. I was sitting there taking pictures in a car at 60 miles an hour the other day, snapped a shot, crisp. Not the highest resolution camera naturally because you've got this little NAND flash in there and you don't want to store too much on it. But very nice and crisp. All right, what else do we have? We have this button here, which I don't know if you can see this clearly, but the screen just rotated about 90 degrees. And you can press it all you want and the screen will rotate. And if you're viewing a webpage, it'll resize appropriately. It'll do the reflowing of the CSS. It works very nicely. They did a very good job. And you've got this little pad on here that you can scroll up and down with. See. So, oh right, the input devices. So, when I said it didn't have a tablet, I wasn't completely accurate because you've got this small writing service here and you can write all the way across it. And then the central part is the mouse. You've got your standard two buttons down here. It has sound and everything. Surprising for $100 laptop, not surprising for anything better. And so, basically one of the parts everyone finds interesting is this interface here. And I know you can't see it very well. Basically what we've got is a white screen with a little round circle and a little triangle here. And this round circle is the mesh network that connects us to all the other OLPCs at DEF CON. I haven't seen one yet. Oh, there is. The newest. The newest stable. The newest stable. Oh, yeah, it isn't working too well. Apparently I suck. I'm gonna have to get together with this guy and see if we can mesh together later. Sorry, what? Oh, yeah. Yeah, well, EB tables and IP tables. Remember, you can't just go with one. It doesn't work. Okay, so you've got this mode here and this is all your wireless access points around. We've got the DEF CON wireless access point here. Anyone want to hack the OLPC? I can connect to the network. Anyone? No takers? All right. These are cool because you can just reflash all the OS images and they're just back to normal. And here's the network where I would hopefully be seeing that fellow over there, but I'm not. I've got this little green guy here and that's me. I know I don't look green, but I am here. I'm over time. Good. I'm done.