"An abridged history of Linux kernel hardening" - Russell Currey, BSides Canberra 2023

right now we have Russell Curry who will be talking about an Abridged history of Linux Colonel hardening so let's welcome Russell to the [Laughter] [Applause] stage all right thank you very much uh yeah hi I'm I'm Russell it's great to be here it's my first first bides it's been awesome so far um today I'm going to be talking to you about the ly kernel and how it kind of grew up over time uh Lynx has come a very long way and there's been many bumps along the road um but you kind of get to see a hobby project become the thing that runs the world uh one mistake at a time uh so uh about myself so I've spent

the last eight or so years as a link kernel developer um for about half of that I was working on um uh kernel hardening Kernel Security uh for IBM for their power CPUs um and as of a week ago um I'm a researcher at infos so I've done blue team stuff red team stuff which is good cuz my favorite color is purple so um just to quickly break down what the title actually means the word a bridge does a lot of heavy lifting here um so this is not going to be some a reference material uh it's more of uh here's an excuse to talk about all these cool things that went into the colonel uh the

big caveat is that I wasn't around for a lot of it uh Linux first existed in uh publicly in 1991 uh where I was busy not being born so uh and then as time went on you know I didn't really get involved with the colonel to around 2015 so a lot of this is kind of you know retroactive um the word history also is quite questionable given I'm only actually talking about things that happened after 2007 so just don't worry about anything before that doesn't really matter um history also finishes somewhere around like 2020 so if you want to know about the really current stuff there's a talk tomorrow um called modern Linux colel mitigations that'll

talk about the things that have recently come in or soon coming in that not all droos enable Etc everything we're talking about today is pretty bread and butter um you will probably encounter these on any modern Linux system um with the exception of some Niche architectures most of the things I'm talking about today have architecture specific implementations um because they're memory management related things so the mmu needs its own implementation and the Linux kernel itself why is the Linux kernel so important as a thing to secure if you compromise some BLX if you get a foothold and you want to get a prives uh the kernel is probably not the thing you go looking at first um it's quite

difficult to compromise relative to the billion random things running in user space uh but the big thing that Linux kernel has going for it as an attack Target is that it's prolific uh it's on every Linux machine after all so if you do your due diligence and uh you know Google the kernel version and see if there's anything on exploit DB if there is something then you've won by default uh the link kernel is it's it's everywhere it's very prolific in all different kinds of devices um Android phones most servers yada yada yada most embedded devices um so if the konel has security problems then the world has security problems uh another reason that it's so

important to focus on its security is that uh it is very very difficult to prevent bugs in the link kernel um it's a gigantic code base it moves very fast it does a ton of things there's new contributors all the time it runs on hosts on guests in between it's a hypervisor on all these different architectures different configurations every Dr basically has their own complete Fork of the source code yada yada yada so it's a big difficult project um which means it's hard to secure so it's important to try and do a good job of it and the idea of hardening the kernel is about self- protection and I've tried to explain this to people and they're

like what why would you protect a code base from itself how does that make any sense why don't you just not write bugs so you tried getting tens of thousands of random people around the world writing C to not write bugs and let me know how it goes um bugs are inevitable there's always going to be bugs in the Linux Kel there's no way around that uh even if it gets Rewritten in Rust there will still be bugs in the Linux kernel despite what some people will tell you um so colel self- protection is is really important so just to run some some ground rules I'm going to be talking mostly about technology about what went

into the konel rather than so much of the politics around why and who and all of that kind of stuff on that note I'm going to be talking about what went Upstream so not all in fact a lot of Linux security stuff wasn't initially developed Upstream the concepts didn't come from Upstream they came from other projects like GC is probably the most notable one um but given the majority of the developer population focuses on Linux or the drers we use flow Downstream from from Mainline Linux and be talking about when things went went upstream and the form they were in when they were upstreamed um and just to underline them talking about the kernel itself there's security features in the

kernel that are actually just the kernel enabling things to happen in user space um and that happens all the time but we're not interested in that not going to be talking about SE Linux Etc so focusing on the Kernel protecting itself against attacks rather than exposing things to user space to do the same thing so kernel hardening or kernel self- protection you might also see um kpp which is the kernel self- protection project there's a links hardening mailing list Etc things that happen in that that kind of a space uh so here are the things that happened in history we have the the the prehistoric era basically the before times when LX was a you know a hobby

project that had the unfortunate incident of uh running all the world's businesses the formative years where people kind of started to accidentally realize that security is a problem um and tried to start doing something about it often inadvertently um the period in which things started to get a bit more serious so vendors CPU vendors are now doing things related to security um and then kind of entering modernity where there's a much greater Focus um and there's a lot of external to the Upstream Community projects that are having a big influence on Linux so that is what history is let's let's talk about it and in the olden days again I was busy being in primary

school or whatever um but there isn't a great story for security in Linux um um there isn't really a centralized reporting mechanism there's open security bugs that have been reported that get fixed years later um security is is a very distant thing from developers Minds uh tooling as well is is quite poor so nowadays we have we have static analysis we have much better compilers um we have a lot of Tooling in inside and outside of the colel that helps us find problems none of that uh so there's a few few there's a few quotes here that I think tell an interesting story um here's one from from the early days which is this guy complaining that the problem

with Linux is there's just too many people hacking the code um it's reached a complexity where the ihack quickly some code approach doesn't work anymore and this is kind of an inflection point in which Linux is a a hobby project for random people to vomit their code into isn't really going to work when we're relying on this to run the world um code standards have improved over time our ability to test has improved over time our thoughtfulness for what we put in the Kel has uh but you know depends on the subsystem uh here's a quote from spender who's very iconic in the colel hardening space um 12 new CVS from just one guy with GP in a few days in a spare

time so loow hanging fruit I'm not sure if that actually describes it it's probably worse than that um security is just not a strong consideration it's took a long time as well not just on the technical side but in terms of a a project structure to have a um a central reporting mechanism for security issues to properly kind of iron out what the relationship between upstream and distributions is uh those in the know will know that that war rages to this day uh and a general sense that like who cares about Security on Linux when the thing next to you is Windows if it's 2005 and your mom's got a virus again cuz she downloaded a dolphin screen

saver that you're not really thinking about your security problems on Linux um so a general sense in in the community allegedly from the people I asked that were there cuz I was busy being in Primary School um that the link just didn't have the security Focus because Windows was just this gigantic dumpster fire next door uh so at what point did things start to get better let's have a let's have a bit of a look at that so 2007 is where history begins famously um so it's Linux 26 615 the 2.6 thing will will go for a while don't worry about it someone thought it was a good idea um for context I've just I've

just started grade n so you know I was very on top of kernal Security in these days I definitely knew what that meant um if you want to know how long 2007 is or if you want to feel old everyone was wearing this shirt I don't know how many of you remember this but it was it was quite does anyone still have one raise your hands if you still have one of these shirts anyone yeah probably for the best anyway uh and so the the colel community is about to have a really hard look at what read only means now I'm not a linguist right but I would I would infer that read only means that you can only read

that would kind of check out right so um what does read only mean well you have the the Holy Trinity the three Horsemen of the Apocalypse wait isn't there four anyway doesn't matter um Three Musketeers that sounds better of read write and execute your fundamental permissions you have these on files you have it on memory um and so memory permissions come down to which combination of these you have uh and if you get it wrong then one could say that there are consequences if you look at if you compile a binary and you look at the sections in the in the output so this is just some Rando elf um you know we've got text which is code and we've got

data which is data and you can see you've got some some things here like uh you your text is is read only which is what you'd want you don't want people to be able to overwrite code your read only data is in its own section which is separate to the not readon data but ultimately when you load this into a when you load this there's nothing magical that says well it was in elf section so it has to be secure um you need a memory management unit in your CPU to actually enforce these things if you want your readon data to be readon you have to tell your mmu that and your mmu has to be able to do that um so you

could think okay cool uh he's about to tell me that uh they realized this was a security problem and that you should actually have sensible permissions on your memory uh well no they didn't really do that so this came along in the form of config debug rro data so it's not a security feature it's a debug feature and it was described as Mark the kernel readon data as right protected in the page tables in order to catch accidental and incorrect rights to such const data so the concern is not our entire memory space is iwx the concern is like well if you screw up your code this can like help you find out why um

and so it would still be quite some time from this point to where people actually turn this on and then fast for to today where uh it's ubiquitous on many architectures you can't turn it off so the way this actually works is that um after kernel init so the kernel has functions that only runs during early boot in the init section it will do all its init stuff and then it'll just get rid of that stuff it just jettison it and after that point it marks read only data read only and there's perks to doing it this way um because you have like annotations in the kernel source where you can say um read only after a

knit for example on a variable um and so basically you hit this Mark data which does what it says on the tin it goes to the m and it says please mark this stuff read only uh and so yeah this was this was a debug feature and not a security feature nowadays we know a strict konel rwx it's also called kernel memory protections if you're on some Niche architecture that doesn't have this you get this big bold text in your in your D message saying uh this kernel does not support kernel this architecture does not support kernel memory Protections in which case you should cry um and this is very ubiquitous now and it just enforces the

fundamental rules on your on your core kernel that code in the text section should be readable and executable data that is not read only should be readable and writable and readon data should be read only so the concept of read only being read only came along quite late in linux's lifespan and still no one turned this on for ages so it's still not we're not looking too good yet but that was the state of the world in 2007 um so do things get better in 2008 well kind of we're still doing the 26 thing um very important year 2008 because I became a Linux user so my first drro was auntu 804 back when they were doing the orange

brown thing that they grew out of um this was the Glorious era of wobbly windows and like the eyes thing you had on your panel that followed your cursor around the three people who believe in the Euro Linux desktop like yeah man I remember that um so very iconic kind of thing and and this is the point at which uh the first support for for stack canaries happen so um this device I've got a photo of here um is a canary resuscitator and it's a good uh example of the hacker spirit I think um so this is a device from col miners who uh having some amount of morality felt bad for the canaries that they were sending

off into the murky abyss and develop this Canary resuscitator to bring them back to life so uh canaries are cool and the colonel finally got them so stack canaries are probably a reasonably common uh concept um and it marks a pretty important Milestone I think in being one of the first major um compiler features that ended up being used in the kernel when tool chains get new support for for security features it's often quite challenging to turn them on in the kernel it often takes additional work the konel is not really written in CN ASM it's kind of written in uh GCC garbage um it's kind of written in weird GCC hacks and the konel and GCC evolve

alongside each other and pile Jank on top of Jank they're very hard to separate to the point where for Clank to pile the Kel they basically had to Port a bunch of GCC garbage so it's not always easy for a new kernel sorry for a new comp high security feature to be turned on in the kernel plus it usually degrades performance which means you're not allowed to turn it on so we now have a a a nice compiler feature here and the concept is is reasonably simple if you have something like a buff or overflow that allows you to write into the stack and you can just achieve whatever code execution you want by blowing over the return address so if

you blow past your buffer and you overwrite some stuff and you put a pointer at the return address then your function returns and you jump to the place that you've you've inserted having a canaran in there inserted by you know that with instrumentation inserted by the compiler means that you can no longer overwrite that without also figuring out what the canary is and putting the same value in place you can no longer just trash that Canary because if you blast over the canary then uh it'll blow up so this is again some some pretty basic stuff but it took quite a while for things like this to happen this is known as a config stack protector and

there's like stack protector strong or whatever so um making some making some Headway so continuing on here into into 2010 apparently 2009 didn't happen it's not really important really uh still doing the 26 thing so that's that's regrettable but but we'll trudge on through I really hope no one here still runs one of these in production um I'm about to show you something disturbing so this is uh my senior year of high school I showed this photo to people and they said they look like gy from the office I don't know how accurate that is but to each their own so we haven't talked about modules yet so colel modules are a big part of the kernel um

so they are dynamically loaded so they can load at boot when you're kernel the text you've got certain Hardware to load some modules in they can be dynamically loaded um you go to spin up some kind of network interface and you don't have the the module in yet it can autoload you plug in a new device yada yada yada um so they have their own separate virtual address space they live entirely inside um the Colonel's virtual address space um and at this point there's still nothing enforcing that they have sensible memory protections they still have redri execute on on everything um because that what was done for the kernel text wasn't done for wasn't done

for modules it's a different it's a different memory space so you would think it's several years down the track uh people have learned something uh and this is going to be this is going to be a security feature uh no it has the lovely name uh debug set module ronx I know it's read only no execute but come on Ronks it's a lovely word um which implements the same thing as debug Roo data but but for dynamically loaded modules so enforcing that code is readable and executable data is readable read only data is is read only and uh in the spirit of good namings it was going to be renamed to uh hardened modu mappings uh before finally

becoming strict module rwx so it's like the companion to to strict iwx it's a bit more difficult to to implement um quite a bit more difficult to implement than um strict colel RX I know because I wrote it um for for power so um but we're making some progress here we're starting to get some sensible memory protections at least uh so at this point uh things are things are getting a bit better but still we're not L thinking about security here so Linux 3.0 very very very big achievement um I've seen people from outside Linux ask what is up with the the version the versioning um the answer is it's whatever Linux feels like and uh nowadays the way that major

version numbers increase is um the the leftmost number goes up when the right most number exceeds uh wi's amount of fingers and toes uh the concerning thing thing is that we've had a 20 and then an increments but we've also had a 19 and an increments so I'm not sure what the state of his fingers and toes are but perhaps we should be concerned um so we haven't talked much about user memory get and what distinguishes user memory and kernel memory um things you would not really want to overlap and and have issues with so uh user space and and Colonel kernel space share the same uh the same virtual memory so you know you're in the same you have different

ranges but ultimately you know you're dealing with the dressers in the same way um and so if you don't have isolation between user memory and kernel memory then you have problems and this is not Universal across architectures that are architectures that um have completely separate memory spaces um I think um s390 or that's um IBM Z the Mainframe architecture uh they just have completely separate spaces for for user pointers and kernel pointers but that's quite rare So if you don't have this level of isolation then attacking the kernel is really easy because if you can just bamboozle it into into reading from some user pointer or executing from some user pointer you don't even need to do

anything in the kernel you can just point at what you've already done in user space um so even though they're they're logically very different concepts there's if you need some way to enforce the barrier um again from from before if you don't have any kind of protection here then if you blow some stack in the colonel put a user address there then you're done there there's nothing further to to do um so as you can probably guess I'm leading up to there's going to start being more more enforcement of these kind of barriers and it it marks a pretty uh important uh moment in kind of the the history of of Linux security and operating system Security in general

which is that it's not just people on the software side thinking about the stuff anymore it's it's silicon vendors so uh chips are being made with more and more memory Protections in them um it's becoming a you know becomes a competitive Advantage for for chip vendors and we're getting more and more mmu features that let operating system developers do smarter things um there's a lot of things that you you can theoretically do in software you don't need Hardware support for um and if you want to have some Ultra hardened user Space Program um that's very slow that's fine but you know I've put Security mitigations in the kernel and then got bug reports for 05% micro Benchmark

regression so it's really hard to justify doing things if they if they cost performance um and Hardware features are the main way to get around that if the hardware vendor can have some Hardware accelerated mechanism to um be able to do these kind of enforcements and that's the realistic way in which they um get included and then you know also they can advertise that you know we're more secure and yada yada so this is where we first got uh smap or supervisor mode execution prevention um on different architectures it has names like pxn which is privileged execution never um but basically you just set a bit in whatever magic register it is for your architecture um and uh the CPU will

no longer allow uh the kernel to execute from a user address so if you do bamboozle the kernel into trying to execute user space code it just won't work it'll blow up um and you might have seen this uh you'll get like a a kernel error you get a log and it'll be like exploit attempt question mark so if you ever see that in your kernel log then you should in fact be concerned uh and this is quite a significant bar raise in terms of the difficulty of of getting an exploit to work um a lot of these kind of hardening features and and protections don't eliminate it being possible to um compromise the kernel they just make it

more difficult and the more difficult you can make it the hard you know the more sophisticated an attacker has to be the more things they have to change together um if even if it just makes them take more time from Step a to step B that gives you know people more time to patch the issue or whatever so the harder you can make these things the better as a um as a Defender so now we've raised the bar quite a bit if you if you have some Shell Code you want to execute inside the kernel you can't just tricker to looking at user space anymore you have to try and find some way to you know get

your um get your shell code into the kernel memory and then execute it from there uh which leads us to to 2012 um so we have sane version numbers now well for some definition of of sane anyway um 2012 the world ended um I can prove this because um I was at Uni it was my first year of computer science at Uni um and I met a girl and I told her I used arts Linux and she was actually impressed and didn't just roll her eyes and walk away um and that there's no way that can happen outside of a simulation so um very famous image here that we always link to um my friend that works

at Nvidia so um if you've heard a little bit about like the relationship between Nvidia and the Lynch Community um just know that uh over a decade and nothing has changed so uh we're going to be talking about uh accesses to user meing now instead of execution so read and write and unlike execution uh access to user memory is is a necessary evil it happens all the time most most of your CIS calls and whatnot you're giving the colonel something to do you're passing it some data you're getting some data back so reading and writing the user memory needs to happen it happens all the time I don't think there's any justifiable case where you

should be executing user memories that one's kind of cut and dry uh but you need to be able to do this you can't just you know unconditionally turn this off um and again if you if it's a very powerful primitive to be able to you know get either um to get corrupted data or or shell carde whatever into the kernel memory also you know leaking Secrets out of the kernel is also a big problem so we want to only have the the user space accesses from the kernel that we like we want to have our cake and eat it to essentially um which is where smap comes along or supervisor mode access prevention on on x86 on arm it's called

pan or privileged access never basically the same thing as as smap except in this case uh you can't just unconditionally turn it on um so we do need to be able to do this and the way it works is basically that it just gets swapped on and off all the time um which leads to its own bug category so when it comes to to user accesses very thankfully the konel has these copy two user copy from user functions so the kernel isn't just doing raw reads and writes from from user pointers it's going through these helpers so you know you would go into copy to user and you would enable user access do all your things hopefully

you're not preemptable um and then turn it back off and and you're fine so it is quite a bit more complex than smap to implement um maybe I'm overselling that the reason I think that is cuz I wrote this for power and I got it pretty wrong H the maintainer only rewrote like half of it it's not really wasn't really that bad um who knew nested interrupts were a thing anyway it doesn't matter um so the origin story of these coffee two from user functions is is really interesting and it's it's quite fortunate that Linux has these because imagine not having these imagine trying to implement smap without having dedicated accesses imagine having to go through your entire

operating system and replace every single Direct Read or right with a helper uh that's a pain and that's why Windows doesn't have smap and basically every other operating system does so these were present right from the get-go right from 1991 when I was busy being not alive um wi TOS as part of the reason Linux was a hobby project for for him was he you know was experimenting with all these i386 features and some part of that led him to have these helpers to always do something for some optimization or whatever um when reading and writing from user space so that had a you know the follow on effect from that um to to the ability to to make the link colel

more secure is is genuinely enormous so turned out quite well so continuing on through history to 2013 version numbers saying um Linx was was busy uh winning Jeopardy I don't know how many people know about this but this is IBM's Watson AI thing on on Jeopardy with Ken Jennings and the guy who's not Ken Jennings I don't know who that is um so this is running on like a big big data center full of I think power sevens um so Linux one one Jeopardy uh still has trouble sharing my screen but it it can win Jeopardy so that's great um and so this is where we had the introduction of of KLR kernel address space layout randomization or or

kasla and if you've done much binary exploitation you're probably quite familiar with aslr uh your stuff is now everywhere and you have to try and figure out where it went so the idea that you can randomize where things are in memory means that in order to mount some attack you need to figure out the location of the objects you're looking for if they're at fixed offsets then it's quite a bit easier um so this is when this came into the Kel it is it is quite complicated to to implement as well um and I think that Kor is also an interesting inflection point because I think this is the first time that for the Linux Community a security feature

came along that made their lives a genuine living hell so before this if you're trying to debug something your pointers are just your pointers um you have you know in print care you have all these these different function what they called the string replacement thingies in in print print F and print k um instead of being a to see your poter to figure out out what's going on you get an under under poter Val under under um you now have to go through every single point at which anything is printed in the kernel and try and figure out if we're ever leaking the location of anything um in order for for kasla to be effective you can't have info leaks any

info leak that reveals the location of something in the kernel is now a security security vulnerability um which is a big pain if you are also you're debugging some issue you might not be able to just turn kler off and run it again you get a report from someone and they spit out the thing and you're like okay great I can't wait to figure out what all that means the colonel as I mentioned before the Colonel's big complicated mistakes are easy info leaks happen all the time so the effectiveness of of kler is quite quite complicated and if you look up there's a lot of different analyses of the effectiveness of of kler out there

and it is effective as a bar raise it does make things more complicated but the value of aslr and user space is can't really be compared to the value of of kslr um a lot of reasons are just size and persistence user space programs run all the time um it is much easier to get an infoe out of Linux um so a lot of the things that made aslr an effective mitigation in user space struggle to hold up at something at the scale of the kernel um so it is an effective bar raise but it's a bar raise that people tend to get around anyway it's rare that KSL would prevent a full attack if you've found some cool

Linux exploit you can probably find multiple kslr defeats to go along with it so it's not to say it's not useful because it is and there's been attempts later down the line to to expand kslr and make it more useful um it is definitely still something you should have on unless you're debugging um but it's not the the slam dunk quite a lot of these other things and it had a pretty significant impact you still see people complaining about this um it really did kind of change the way people worked in in the lenix Kel so continuing on with our with our story uh we ran out of digits or Ln did so we've gone up to to four uh what year

are we on 2015 yes yes very important year 2015 uh in which the Linux Kel got irrevocably worse cuz my first patch got in so there's my first MIT I don't have any clue what that patch does but it doesn't really matter it's still in there I think um and so this is where we got our our first sanitizer and this is going to be a continuing Trend we've mostly been talking about features in the kernel itself that run to actively protect it and ksan doesn't do that K's a sanitizer so built on top of of asan which you might be familiar with from from users space um K has a dynamic me memory safety error detector and so it's

not something that you you your diss don't turn case an on right it has a performance impact um it has some false positives sometimes uh but if you're trying to figure out what's going on in some code if you're trying to test to see if there's there's memory safety issues having a tool like this you can build into your kernel and enable and run um and actually have an idea of what's going wrong with my allocations do I have things going out of bounds am I um use after freeze double freeze y yada being able to actually have something automatically find these things and report them to you is a is a really powerful tool it does this by

having a shadow memory region where it it records and tracks um allocations and then Compares them um and so I found this number uh the sources are trust me bro but I swear I found this number in a few different places um around 70% of security issues are memory misuse bugs uh I totally found this from like some credible sources you'll just have to believe me um so being able to find memory missuse bugs is is very good for for colel security and as the Colonel code base gets smarter um it's not just about protections it's also about tooling so here's some memory corruption and you know you get this nice thing out of out

of having case on so it says um this is the address it's in this case it's this offset it's it belongs to this page um which is very good if you're a developer because memory corruption is one of the hardest things to debug um so memory corruption is cursed and this is kind of a random tangent but I feel like it's important how much you know this memory corruption is the worst thing in the world um because the problem is that if you have memory corruption and you crash you're having a great time um if you can figure out what's going on at the point at which the memory corruption happens or not long after you've saved yourself

months of of pain um if you crash and you don't know why at least you've crashed but it's when it's when bad data propagates that everything is horrendously cursed because if you have some kind of memory corruption and then you know weeks later you crash for some reason the thing that made you crash is going to be very far removed from your actual memory corruption so in terms of the general sanity and stability of the L kernel having tools like this that can actually Le snow when things are going wrong are are really important um so carrying on to to 44 through the 49 um and this is when uh the entire way the kernel Stacks work

changes so in 2016 um we first got Vmax vmap stack or virtually mapped kernel Stacks so before this uh the own Stacks but allocated on you know physically contiguous memory if you have some kind of buffer overflow there's no mechanism to to report that um there's nothing going to prevent you from doing that um so reworking the way that the Kel's own Stacks work to use its own virtual memory sub system uh has some very significant both security and just um debug ability ramifications uh the fact that buffer overflows can can be detected and reported and explained to the developer most of which are not Security Experts is a is a really powerful thing there's quite a bit of

complexity here behind this but um it's a very big jump to go from not having this to to having this you no longer have to have the kernel Stacks next to each other so you no longer have to be able to blow past one thing and then screw up some other thing you can spread them out a bit more so these are all like kind of things you would be like wow how did the colel not have these before but um nevertheless things have things have come quite a lot way and as time has gone on here um the level of sophistication has gone up the level of focus has has gone up things are being

taken more and more seriously so past this we enter modernity and a big part of of modernity is is a shift in focus and mindset to the point where a lot of people suddenly care about colel security a lot and this is a a big reason why the problem around Spectre meltdown first dis scories I think in 2017 is that there was kind of this big industrywide Panic without a whole lot of understanding of what it actually means so operating systems were the main place that these classes of vulnerabilities got mitigated we've talked about CPUs in terms of CPU vendors providing um protections features that that enable mitigations in this case CPUs are now the enemy um CPUs are now doing things

that they shouldn't do that allow um attackers to bypass typical um typical protections on between privilege mandies so operating systems have a pretty big role to play in mitigating these kind of attacks and the way it typically works is that if you're context switching either from user Space Program to user space program or you're Contex switching between user and kernel doing a CIS call or whatever then you would flush a bunch of State so you would clear out a bunch of the cpu's internal state so that it couldn't potentially be be deduced from from an attacker on the other side you can potentially influence um influence things and there have been many attempts to mitigate things in in software or

with clever gadgets that haven't particularly held up over time um if you want to know more specifically about these bugs I gave a talk about last year um if you really want to go into the Weeds on these things um but I've never seen more people talk about patching the L kernel and who's vulnerable to what than after the Spectrum Aldan era and if you go to um where is it in in the fs CIS class something there's a there's um CFS entries that go over all the mitigations I think lscpu prints them out where you can see um line by line for what are mostly specul execution vulnerabilities what your mitigation status is um but this represented a

pretty big shift I think um and a shift that people tended to accept despite the performance concerns um Intel in particular has taken many gigantic performance hits um implementing these kind of things but something you have to do Android also just Android's existence and prevalence and Google's focus on security has also had a a pretty massive shift in the level of sophistication of of people trying to defend Linux um Android runs Linux but um much like the rest of the Linux ecosystem has issues with fragmentation it has issues with currency with Upstream it has issues with security um the Android kernel is getting better at being something vaguely closer to Upstream but it's still it's still quite far away and so

an attack Vector on Android you can have all these nice sandboxes but if you can own the kernel then you can own the kernel so a lot of um investment in in tooling and infrastructure and security came into Linux off the back of um of Android's prevalence and the ability to Target and user devices that are walking around and connecting to everything relative to you know hardened servers with a few specific entry points um so I want to to also mention uh szer so szer is a very sophisticated um operating system uh system call fuzzer um it supports Linux and a bunch of other operating systems no one cares about so sisol was a big leap in um our

ability to automatically test the Linux kernel for vulnerabilities uh just being able to fuzz all of the things that the L Kel does well you know not all of them a bunch of them uh exposes a lot of problems and as time went along and things like kaan um and other sanitizers improve the ability that we have to understand what's going on inside the kernel when things go wrong we get a whole bunch of bug discoveries thousands of of Kernel bugs have been found by by sisa now not all bugs found by ssca um have been fixed and never exploded but you know the numberers probably on the blue side I would guess so cisola has kind of marked um a

big Improvement in in Automation and we do see other fuzzing attempts happening now that never really happened in the past with a bit more sophistication as well there's this really good talk in an article about um Intel's focus on hardening um basically what happens when uh you're a guest but you don't trust the host right if you're running through KVM you're uh you're a guest of of Linux as a host but you you think the host is hostile um and how they fuzz that really early path before cisca can do anything so a bunch more tooling sophistication has come around the colel that has kind of moved the needle quite a bit and more and more sanitizers have

have come along as well some of these are really quite new I think km San only landed um late last year here so again tool chains have had some of these sanitizers for a decent amount of time operating in in user space um but increasingly they've been they've been ped ped to the kernel to do things like um you know casy sand for concurrency issues that can find um uh that can find data races and whatnot km sand that can find um bad memory accesses to the level of you know you're trying to read from this that wasn't initialized in this um in the 64-bit integer UB s for undefined Behavior so our ability to understand what's going

on the Kernel is getting better along with our ability to prevent attacks from inside it and I also wanted to mention uh rust so I don't know how much of this rant is fueled by hack and news comments but people have a lot of misconceptions about R what rust can do in the kernel um or even what rust in the links kernel is so so I also wanted to to touch on that um rust has like a a very Baseline level of support in the kernel to where there's a a shim that will let you um start writing kernel modules in Rust um and you can do that and people have done that um none Upstream that do anything

interesting yet there's obviously some quite interesting projects in the pipeline such as the um Apple M2 GPU driver uh but every time there's some kind kind of Linux memory safety thing there's a hoorde of people saying oh if it was written in Rust this wouldn't have happened and I love rust I am on the rust evangelism Strike Force but I don't really see how it's going to solve a l our problems the first thing is that we both can't and probably uh won't anyway rewrite the curdle in it um a big bottleneck for linux's ability to get better is down to what the maintainers can do have time for and and understand um kernel maintainers are overworked

there's many of them but they have a lot of of work to do they have a huge amount of of stuff to keep up with and learn this entirely new very complicated language um is a pretty tough pill to swallow uh modules are one thing they're dynamically loaded they're reasonably isolated within themselves rewriting core kernel bits has a lot of WS um not just in terms of maintainers but in terms of distributions distributions hate changing tool chains um having to add some new tool chain just to compile the kernel for some like ancient kernel version that rail still supports it whatever isn't going to work so if you're thinking about writing something in Russ today there's very real problems

as to why you might not want to do that and those problems aren't going to go away um anytime soon so um a big part of it is it also it won't solve all the problems the upside of a big part of the upside of of writing things in Rust in Linux is that uh the problematic bit gets kind of scrunched down um the layer between you know the bindings between the C parts of the kernel and the Ross parts of the kernel need to be good but if you're writing code um if you're writing safe rust in a module using those apis and you screw you probably can't screw it up too bad um but there's

still going to be problems there's always going to be bits in the in kernel that are written in SE that are written in Pur ASM um there's many classes of bugs that are not memory safety bugs so that is something to keep in mind as well um and yes it it won't take us to the promised land if there is a rust kernel being written um which is quite cool and has come quite a way long um but yeah it's not a it's not a silver bullet but it it will help um rewriting bits in the colel will help there's a whole bunch of abominable things the Linux kernel has to do um you know if we

can just take out all the parts and drivers that like PA strings from users or whatever and just write it in Rust instead that will make a big difference um but it's it's going to it's going to take a while um so um that's about all I had um if you want to know what's going on after the these periods in history then um head to the talk tomorrow uh thank you for watching history and uh thank you very [Applause] much