CPU Kernel Mode - Computerphile

Key Takeaways

We are continuing our journey uh taking our robot living in his little room with his abacus and all the things that we've talked about before and we're slowly getting him up to what modern CPUs do. And specifically today, I'd like to talk about the kinds of things that the CPU does to protect us from ourselves. I'm a terrible programmer. I don't know uh why people seem to think that I'm, you know, maybe okay at this, but I I'm an awful programmer and I need every single help of protection that I can get. And if you sort of cast your mind back to that first Fibonacci routine we wrote, we know that it was just adding numbers and writing them in the next box and then kind of going back two boxes, adding the next two, and then so on and so forth, right? And then we sort of revealed that actually the program itself is stored in those boxes. And so if we put the program in the wrong place then the the output of the program would overwrite it. And we talked about the security cons parts to that. Well, we also recently said that those boxes um also represent hardware in a way. So when we write to memory, we don't always go into the boxes. We don't always go to the pigeon holes. Maybe one magic number that we write read and write to could be the keyboard. And we said, you know, if you're pressing the X key down, if I read box 10 million, then maybe I can see that there's an X in there or not. And that's great. It works the other way, though. So maybe I have a floppy disc drive attached to my computer. And maybe the way that I control that is I say, well, if I write the value one to this location, then the motor starts and this thing starts spinning. And then I can read values to sort of see what numbers are on the disc as they're flying past the head. head. That's a lot more complicated than that. But then similarly, if I write to it, maybe that turns the arrays head on and it starts wiping the data. Okay. Now, you have to be really careful if you're going to do that. Danger, danger, danger. Exactly. Right. And so hopefully you've got some piece of code that can do that exactly right for you when you need to read and write to the disc drive. Right. I mean, that's a device driver or it's the operating system or anything like that. And that's great. But Muggin here isn't a very good programmer. What happens if I accidentally write to location 20 million, which happens to control the array's head? Whoops. Suddenly, my Fibonacci program is inadvertently wiping the disc drive that that it's on, which you know, and to be fair, in the 8-bit era when, you know, the the robot was born in my mind when I was in the 80s and and reading these Osborne books, if you remember back, that was just the case. It was like, just don't do that. be careful, don't do that. But nowadays, thankfully, we get a bit more protection. And so, I'd like to talk a bit about how the CPU protects us from our self. So, we described before that the robot lives in his little room and then when he wants to read and write to memory, he kind of holds up a card with the address out the window and then essentially everybody outside looks and sees if it's for them. And most of those numbers will correspond to memory and the pigeon holes and somebody will fetch the number and hold it back up to him, but some of them are keyboard or whatever. uh that's not exactly what's happening. So in between the address that the CPU wants to read and write to there is sort of a bodyguard stroke I suppose bouncer and so that bouncer will check and say are you allowed to read and write to this address and for our very simple machine we're going to say that there is a single security pass that you can get and if you have the security pass then the bouncer will let you read and write to anything you like right he just says fine it's you VIP right off you do whatever you like. If you don't have the VIP pass, on the other hand, he'll look and see if your name's down on the list. Right. Your name's not down. You're not coming in. Right. So, and what we'll do is we'll arrange for it so that unless you have the VIP pass, all say addresses above 10 million where I decided to put all of these hardware peripherals are strictly off limits. And therefore I as a a Fibonacci program without the VIP pass I can write with gay abandon and nothing horrible will happen except that if I try to write to those locations what happens the bouncer just says does he ignore it? Does he do whatever? No. So he actually calls the supervisor and says hey somebody tried to do something naughty here. And in this instance that's very similar if you remember to the episode that we did on interrupts. It's similar to an interrupt. It's a sort of forced jump to a particular location in memory where the supervisor is going to kind of check and say, "What should we do?" Right? Um and it again it's like a an interrupt in as much as it's it's taken for us automatically. Um we're moved to a particular well-known location. And now this is the extra caveat. When that happens, the VIP pass is given to the CPU. So now suddenly we've reached a piece of code that has got a VIP pass and it can choose to do something a bit more special than we can. Typically this VIP pass is called supervisor mode or kernel mode. On x86 it's ring zero. They've got three four rings but no one ever uses ring one and two. So there's a ring three which is you don't have security access and ring zero which you don't. Then there's ring minus one and ring minus two which is also d. Never number things right. if you think there's ever ever going to be things lower than or higher than. Um, so yeah, we've got um so if we try and read and write to an area of the address space that we're not allowed to, the supervisor program is called with the VIP pass and it can choose to do whatever it likes. In in in our case, it would probably print a message to the screen saying, "Whoops, you made a mistake." And it would terminate the program, whatever that means. We haven't really talked about how that kind of stuff would work, but that's what it does. Now, that's cool. Um, but what if I did actually want to read or write to the the disc drive, right? Maybe I needed to load my my data in um for for my Fibonacci program. I don't know that doesn't have data, but you know what I mean. Or maybe you wanted to save the results. Hey, you know, I'd need to be able to call the operating system and say, "Hey, can you use the the carefully written driver routine to read and write data to the disc drive doing the right thing?" But I don't have that VIP pass. And if I call that routine, it won't either. it'll just continue to have um the same privileges that the caller has. So, how do I acquire this VIP pass in the first place? Now, I could just say, you know, a bit like our do not disturb flag that we talked about before or a bit like the um carry flags and things like that that we also discussed, I could add an instruction which lets me just get the VIP pass. But then, you know, I've kind of I could easily make a mistake and accidentally acquire it. It's probably easier to to to sorry, it's probably harder to make that kind of a mistake than it is to get the memory addresses wrong. But if we're going to use this for more than just protecting me from myself, then we don't want anyone to just be able to become the supervisor and the the operating system. And so we have something called a software interrupt. And this is actually the same process, a similar process, sorry, to both the external interrupts that coming in and also that kind of fault when the bouncer says you can't do what you want to do. except that we can choose to do it. There'll be a special instruction that says, "Hey, I would like you to do an interrupt now." And then atomically in inseparably, we both get the VIP pass and we jump to a known good location in memory where the operating system lives. And so suddenly we can transfer into a place in the code in the operating system which has got the privileges to do the disc drive activity. So presumably it would then read and write to the disk, do the right thing, control the hardware in the correct way, and then once it's finished, it has to give up the VIP pass before it returns back to me. Otherwise, you know, I'm left with special permissions. And so this is, as I say, it's a software interrupt. Um on on the ARM CPU, it was uh the instruction was called SUI or SWY. People would call it for software interrupt. And uh it would allow you to jump to the operating system and gain these sort of special privileges. And this is sort of what gives us this distinction between user code and operating system code. This ability to jump to a particular place in the operating system and gain this extra special privilege that's part of the CPU's design. Now how how do we tell the bouncer which addresses are good and which ones are okay and which ones are not? That's a whole other topic which I think we can talk about another time. But this gives us all of the pieces that allow us to give ourselves separation between user code that can only do certain things and operating system code that can do uh all the things that you need to do to make the machine work. You know, of the millions and billions of programs out there, this must still go wrong at times. You know what what what is it that's happening maybe when we see those error messages pop up? because this this can't be perfect right that's absolutely right so yeah um I mean so operating systems these days try their level best to work with the minimum possible privileges at all times because while you have got these high privileges then you the kind of things you can that can go wrong are very very unbounded so even inside the operating system itself there are large sways of code that don't have the privilege and they can kind of carefully you know pop in and out of the the privilege mode as they as they need it. So um in particular things like um so an interrupt happens that effectively gives you um privileges as well kind of on purpose because you know the only reason interrupts happening is some hardware devices wants your attention and so the operating system very quickly usually does the things it needs to do to just acknowledge that the device has data and then it puts the work to be done somewhere else and then it immediately drops privileges and goes back to doing whatever it was doing before and then later on it kind of gets back to the work and so that kind of that clear separation of concern concerns um helps a little bit. Now, what you're kind of alluding to, I think, is like the the notorious blue screen of death kind of thing, right? So, when the bouncer or something equivalent to the bouncer triggers inside the operating system itself because some mistake in the operating system caused it to try and do something it wasn't didn't have the privileges for. That's one of the ways that a blue screen of death can happen where effectively you got an unexpected memory read or write that was uh um was not allowed for this this particular part of the code. Um and that's a mistake. That's a programming mistake on the part of the device drivers. And that's one of the things that makes writing these kinds of pieces of code, the things that control your graphics card, your sounds card, and whatever so difficult to get right is you've got to get all these things right. And you kind of have no safety net of a of a sort. No, I was just Yeah, I was just thinking, yeah, obviously they've got to be right for all those different circumstances, for all those possible different combinations of bits of hardware and all, you know, there's so much that can go wrong, I suppose, right? I mean, they they try and sort of separate them out as much as possible. And, you know, nowadays, commodity hardware is fairly similar. You know, everyone's sound card looks the same these days. It's not like the the wild west of the the 1990s with moving jumpers on on on on the board and having to load very specific drivers in your uh config.is or whatever. But but you know um yeah and and operating systems have kind of gotten much better at this. They've sort of modularized them so that the drivers now aren't part of the core operating system itself. They're usually a separate little program that installs and has is signed so that that the operating system can be sure it came from the manufacturer and it isn't just somebody trying to get into the uh the privileged mode because of course in privileged mode you can read all the memory on the whole system and that's issues there as well. Obviously, no one just wants to hand out all the RAM to their computer to some random piece of code. And I'm guessing the other thing is that you've got to be aware of if you're involved in any of this is that obviously the people will exploit this. Yeah, exactly. Um, actually it reminds me so in the naive old days of the late ' 90s or mid '9s I suppose when I was hacking around on the Acorn Archimedes and it's like which was like the first ARM based computer. Um it had this separation between supervisor mode and user mode and that was used for privilege um separation but it had one software interrupt routine that on purpose returned with the privileges left and it was called sui o enter o and it was like you know hey become the operating system and you could just call it and then you're like sure now I can poke around with the hardware and these were the simpler times obviously um that was a specific thing in the there wasn't a CPU specific thing that was part of the operating system is a convenience to you know hobbyist programmers and whatever. It's like hey you want to do this thing it's a pain unless you can actually talk to the hardware. So just call this and now you can do everything you like which you know simpler times and it's going to be lots of clever instructions that I don't know how to write off off the top of my head that actually calculate the square root of whatever is in T2 as it happens and we'll come back to that in a sec. And so this instruction at line 103 wouldn't be a square root. It would be something like