 Okay, it's me again. That's where you get the slides. This is about the Kernel Self-Protection Project. I mentioned this earlier. We're protecting the kernel from user space, not user space from user space. But we are interested in all of those areas. So, you know, development is welcome even in those areas too. A lot of people are involved in this. But please help us and not anyone else you heard today. We need the help. This is mostly about bug lifetime. I've talked about this before in other presentations. Refresh the analysis. And these numbers are actually have gone down by one-tenth of a year. So we were at a solid 6.0 years on the high, medium and low. And they've slightly crept down. And this is the graph I have generated before of the lifetime of a bug when it was introduced. This is Kernel versions along the one side. When it was introduced and when it was fixed, critical and high. So the longer lines have a longer lifetime. And the concern I was having recently was that the bug lifetime that we'd seen at like five years and growing to six years, I was worried that what we were actually seeing was distance from the beginning of Git history. And as we got further away from it, the bug lifetime would continue to increase. But I saw that some of these long tails were starting to lift up out of Git history. And it looks like that is continuing. So maybe there is an actual real number somewhere in the five-year range that we're trying to protect against. Anyway, so quickly a year's worth of kernel releases. And for 14, we got a whole three of reference count conversions. There was a stall on bike shedding. We... I was surprised about bike shedding. The port of the Randstruck plug-in in automatic mode landed. We got free list pointer obfuscation. So attacking metadata in the heap is more difficult. The Struckleek plug-in got a by reference mode that I talked about earlier. We gained VMAP stack for ARM64. And then there was a large series of patches to just get rid of setFS, which has been a problematic interface for a while, along with gaining balance detection. See if we set FS out to all of kernel memory. And then we exit out of assist call without resetting it. That's a very bad bug, but that's one we've tripped over a number of times. So now we actually test for it on exit. We say, did you forget to reset the boundary? And it will come back. It will crash and come back, or whatever. Anyway, so back bike shedding is done. 35 ref count conversions, about 32 remaining. 415 was when we landed PTI and Rhett Palin. This is also where I gave myself Carpal Tunnel doing Struck Timer List removals, trying to get that refactored, since that was a source of some exploit infrastructure. And we gained the fast ref count overflow protection, which is one of the very few features we back ported to 414 for an LTS because it was really a one-line bug fix plus enabling it. All the code was already in 414. And we gained the percent P hashing, so that we have, in theory, fewer information leaks going out to logs. In 416, we had 12 reference count conversions, maybe about 20 more, gained PTI for RM64, hard and user copy gained whitelisting, which was instead of just checking the size of an allocation, when you're creating allocations, you can specify what portion of it you expect to go out to a user space. So this narrows the availability of what's getting copied out even further. And around this time was the blue-born attack, where I was horrified to discover that basically everyone building little embedded devices did not turn on Stack Protector because it sort of default off due to some limitations in tooling and other things in the config. So I managed to get an automatic mode of this working where during the build, it would try to figure out the best thing your compiler supported and use it. This has since been replaced with better tooling, but ultimately it gets us to the point where now when you build a kernel, you get the Stack Protector off and that was a long time-limited problem. In 4.17 is the start of VLA removal. So 5.1 removed in 4.17, lots of people helping with this, 80 remaining. We're wiping the stack on fork. So in the past, you would allocate memory for the stack and it could have come from anywhere and it wouldn't be initialized in any way. So if you managed to leak something immediately or at any deep location in the stack, you would have whatever used to be there and that was ridiculous because it's easy to wipe the stack on fork because that only happens once per process. As it turns out, this appears possibly to actually speed up exec. I have bad data. More fixes for our limit bypasses on exec. Map fix, no replace came in, which is yet another stack clash issue. When execging, it was possible to confuse the kernel into overlapping an executable region onto other regions that had already been mapped since map fixed is happy to replace whatever is underneath it. But map fix, no replace says, I'm not going to do that and will fail instead of leaving you in a dangerous position. This 417 also included on syscall entry, clearing unused registers on x86 as a way to avoid having registers for speculative execution gadgets, speculation gadgets of any kind so you don't leave stuff sitting around in registers that aren't actively used for the syscall entry. And we got the speculative store bypass disable protections for more speculation things on x86. 418, we got 38, VLA is removed, 42 remaining. We got some of the basic arithmetic overflow detection helpers. People have to use them explicitly, but we made sure to go through and at least try to catch as many of the allocation, allocations that are using multiplication to figure out how large their size is to have all of those use the overflow detection so we can try to kill an entire class of issues there. There's a lot more work to be done, but I know that we at least got one known one as someone was trying to report overflow issues. Their patch collided with the tree-wide changes that had come in, so it's like, okay, that's actually working. We found at least one bug there, who knows how many more there are. And then we got SSB disable on arm64. So 419, the merge window is closed so I am expecting these things to have gone in. 33 VLA's removed with nine remaining. That's been a long, long path for that one. As well as the multiplication and addition overflow helpers, we've also gained shift overflow helpers, so you can be sure that your shift actually worked correctly. The L1TF defenses went in. We're now also able to restrict creating files in temp directories or sticky writable directories. This has existed for Simlinks, and with Simlinks gone as a target for attackers to use for doing temp races, they could actually turn to just creating regular files and pipes in temp as a target. So that's now blocked if you want it. And then the unused register clearing for syscall entry on arm64 and SSB disable on arm64 for 419. And then hopefully in 420 we'll be done with VLA removal and we'll get the stack leak plug-in, as you heard about. Various soon and not so soon features we're looking at, thinking about writing patches for LTO and CFI, you heard about exclusive page frame owner, this whole list here. And same slide I had on the other one, which is we have a lot of challenges with doing upstreaming. You heard a whole presentation on that. And that's it. There's places to reach me and find KSBP and these slides. Any questions? Yes. I can. So I should have linked to it. The question was about restricting Ocreate on existing files. So if there was a file in temp that you did not own and you issue an Ocreate without O exclusive, it would overwrite it if you had the permissions to. So you could replace files out from under someone who was doing the wrong thing. Same thing for FIFOs. I know the other way around. So whoever is attempting to, yes, it is somewhat backwards. You basically don't overwrite the file that was put there by an attacker because their permissions would supersede yours. Anyway, because Ocreate would succeed because you opened it. It was already there. Because you forgot to include O exclusive in your open. So it's basically stopping the legitimate process from opening the bad file. Yes. What was it? I cannot speak to that particularly well. Sorry. Anyway, come find me afterwards. I don't want to keep people more than we're already way over. So thank you.