foreign
[Music]
Russell is a Linux kernel hacker
primarily focused on memory protections
and microarchitectural security he leads
the Linux hardening team for IBM power
and today's Russell is going to talk on
the history of Linux Kernel Security
please make him feel welcome
great thanks a lot hello everyone good
morning
um good job managing to find the room
and bad job choosing to come here
instead of Paul McKinney's talker you do
know that Paul mckenney's talking right
but anyway
so yes uh today I'm going to be talking
about a bit of the history of of Linux
Kernel Security
there's a lot of history and there's a
lot of things that mean security so we
may be not able to cover it all in 40
minutes or whatever but uh I will I will
do my best so anyway
uh let's kick into things
yeah there we go great uh just quickly
rattle off um who I am as mentioned I'm
a
full-time kernel developer I run the
links on power kernel hardening team at
IBM
I'm based in Canberra at the Oz Labs
team
and yeah I've been awake since 4am so
this may be slightly more unhinged than
otherwise planned but we'll just kind of
roll with it keep that in mind and just
to set some ground rules for the word
history and just how Abridged I make it
uh first of all I'm going to be talking
about the technology itself I'm going to
be focused on what went into the Linux
kernel what it does why it's important
as opposed to
uh you know other stuff I'm going to be
focused primarily on Upstream now a lot
of Kernel Security features didn't
originate in the Upstream sorcery they
didn't originate in in Mainline and
Linus 12 volts tree
coming from other projects like grsec
but as I work on upstream and focus on
Upstream that's what I'm going to be
talking about today
and I'm specifically going to be talking
about the security of the kernel itself
now the kernel exposes a lot of security
features to user space
we don't care about user space here
we're talking about the kernel we're
talking about Linux itself the core body
that is Linux so we're going to be
talking about linux's ability to protect
itself the security of the kernel itself
which is often called kernel hardening
or kernel self-protection the ability
for the kernel to protect itself against
attacks
so we're going to be rolling through
some some areas here uh into what I've
I've delightfully called the before
times the Dark Ages uh which I was
probably in primary school for uh the
formative years Linux is growing up
people are starting to think that
security is a thing
um into the area where we're really
ramping up into some real stuff we're
actually thinking about and then the
modern era where
most people mostly care about security
which is a good thing so but it's a long
journey to get there so let's start with
the before times the Dark Ages
uh
security has become a much bigger Focus
I think across the entire software
engineering ecosystem as the years have
rolled on this is not necessarily always
being the case
um at least if you're not a security
researcher so back in the day we're
talking you know pre you know early
2000s late 90s we did have you know cves
we did have vulnerabilities get reported
we did have bugs and they did get fixed
um but not really at the rate and with
the kind of passion and vigor we fix
bugs today we're talking you know uh
privileged escalations sitting unpatched
for years Etc so there was the same kind
of process we have now just in a very
very kind of basic form
security not really a thing that people
are super fixated on we did have things
like the security at kernel.org mailing
list where you can privately report bugs
in the kernel but we didn't have things
like you know Common People on mailing
lists knowing to look for things that
could become vulnerabilities
and we didn't have the tooling nowadays
we have a lot more tooling when it comes
to things that can catch bugs before
they become vulnerabilities
things that can you know scan for
exploits and fix them and whatnot we
didn't haven't we didn't have
particularly smart compilers we didn't
have particularly smart tooling
instrumentation Etc
now there's some great quotes here which
I wasn't around for this era and seeing
these quotes makes me glad of that the
first one I found this was around like
2007-ish it's this quote that you know
problem with Linux is just too many
people hacking the code
has this but it's reached this size this
complexity to whether I hack quickly
some code approach doesn't work anymore
in the early days of Linux code
standards are not as high as they are
now I know from some of the younger
people in my team
seeing some stuff in the kernel that's
in that's been in the source for 20
years
wouldn't really fly if it got reviewed
on the mailing list today so the code
quality the standards of the kernel has
gone up
and uh that is reflected in the kind of
wild west era that the colonel used to
be in there's a quote here from from
spender about how this is this
particular time where you know okay we
got 12 new cves so 12 new
vulnerabilities some actually more than
12 found by one guy with grep and a few
days in his spare time now that is a lot
of low-hanging fruit and not to say that
there's no the kernels done with bugs
guys there's still bugs in the kernel
but probably not this level of severity
that you can find this easily I sure
hope we've we've passed this point
um and part of the reason for this is
just that you know if you're in 2005 or
whatever and you're thinking about Linux
uh security pro is on the Forefront of
your mind because the thing next door is
Windows and it's windows in 2005. how
many of you had to deal with a family
member getting spyware from and storing
like a dolphin animated wallpaper or
something you know like
heard from that to your women's computer
that may even have like a working
Network or something at that point
pretty pretty secure by comparison so
not necessarily something that's you
know
a huge concern people just kind of have
this base assumption that Linux is is
pretty secure
uh
but the problem with that is that Linux
is a big Target
um Linux runs on billions of devices it
runs on most of the server world
tons of phones in people's pockets right
now and for the Wilderness that like not
having working things also on the
desktop
so the kernel has a really big scope it
does a ton of things however many things
you think the kernel does it does more
than that so the kernel has a gigantic
scope it has a really high amount of
code that does a ton of different things
the kernel code itself changes really
rapidly thousands of different
contributors every release releases
every few months really high velocity of
course most of us don't actually use
main like Upstream Linux most of us use
distributions and every different
distribution has their own different
version of the source and different
versions of those versions and so on so
the kernel changes really rapidly it has
a really wide range in ways it's it's
distributed
it also runs on lots of different
Hardware
it utilizes lots of different add-on
cards and whatnot it runs on a
hypervisor as a hypervisor both at the
same time so scope big is the point and
because scope big bugs inevitable there
will always be bugs in the Linux kernel
because of the sheer gargantuaness of
the lyrics kernel
there's no way that that we're going to
get around this there's just simply too
much code too much code written in a
memory unsafe language uh so there are
going to be bugs
the point being that if bugs are
inevitable then we need to do something
about it we can't just have the security
model that the kernel doesn't have bugs
we need to give the kernel the ability
to protect itself so when there are bugs
in the code it doesn't get compromised
if you take over the Linux kernel you
take over the whole system if you're
infiltrating a network and you
compromise the kernel in one box then
you can make things look like business
as usual
there's a whole bunch of stuff you get
from being able to own links kernel and
in most data centers the Winx kernels on
pretty much everything so if you can
beat the Linux kernel you win at
hackening and we don't want people to
win at hackening so thus Colonel needs
to start securing up
now time begins in 2007.
uh
it is around the time Linux 2.6.15
people younger in the audience may not
remember when Linux had dumb version
numbers but this goes on for a while
this is a continuing trend
uh I've just started grade nine
for a bit of context for how long ago
this was
it's 2007 everyone's wearing this shirt
I don't know if any of you remember this
this was quite the craze at the time
and aside from that other stuff's
happening uh we're about to you know the
colonel Community is about to have a
really hard lesson about what read only
means
now most people would assume that read
only means that you can only read uh but
it may not actually be true so let's
think about what read only means
so let's just talk about memory
permissions this is the Holy Trinity the
three things you've got a bit of memory
what do you like to do with it well we
have read write and execute rwx so can
we access it can we modify it and can we
run it if we jump the cpu's execution to
this address will it start running
execution running instructions from
there so RW and X now
people may assume that if we have
something that is called read only then
we only have the r here and that would
be very false in 2007 so
read only may not mean read only now
here's just a quick look at the the file
that is the Linux kernel itself this is
a VM Linux it's a elf executable you
don't need to worry too much about this
stuff the first thing is that we've got
we've got these sections we've got you
know properties of those sections and
here we've look at number one there
we've got text now text means code I
don't know why it doesn't just say code
but it's always been text and so text
has some properties like read only and
code because it's code and it should be
read only that's cool then we've got
this next one called Ro data now Ro
stands for read only and you'll notice
there that it doesn't say read only like
the others do so that's that's your
first problem but the second problem is
that this has just did the file itself
once you load this into memory there's
no inherent property that means a
read-only data is read only it's just
supposed to be so obviously it is
um
and so this is potentially a problem if
you've got parts of your memory that you
assume are read only and someone can
change them then perhaps they can change
them in malicious ways
and so people hadn't quite had this this
realization yet for security instead we
got uh debug Ro data so someone comes
along uh iyan finder then probably
mispronounce that uh and introduces this
option when you build the Linux kernel
called config debug Ro data
and the blurb is we want to Mark the
kernel read-only data as write protected
in the page tables in order to catch
accidental and incorrect rights to such
const data
and this is completely fascinating to me
because the idea of making something
read-only be read only is a debug
feature it's not a security feature it
helps catch your bugs when you write to
the wrong place it's really useful so
it's fascinating to me that this is a
debug thing and not a security thing the
way this actually works is that when the
kernel boots it has to do a lot of stuff
based on what it's actually running on
the Kernel doesn't know much about where
it lives when it first boots So based on
the devices that's running on the CPU
it's running on it will change itself so
if you have something marked const if
you have something like that it's not
actually constant until this gets
enforced and this gets enforced in and
kernel in it imagine we've done a bunch
of the knitting you know lots of a
knitting
um then we freeze some stuff and then
before we declare the system is running
we run this magic function Mark Ro data
Ro because it wasn't before so
everything's modifiable until we
actually start running and then now that
we've got this in the kernel the
read-only stuff is read-only so 2007 big
leap forward read only means read only
for some stuff we'll get into that but
it's a good it's a good step forward
uh and this is kind of the birth of
actually setting memory permissions in
the kernel actually utilizing the
features of the memory management unit
of the CPU to make sure that the memory
of the kernel resembles something
sensible this all begins with this this
debug feature in 2007. so nowadays this
isn't called config debug Ro diver it's
called strict kernel rwx or sometimes
more broadly kernel memory protections
uh probably kind of Baseline very
fundamental very important kernel
hardening feature
so essentially asserting that code
should be readable and executable not
writable
a data which isn't read-only should be
readable and writable and read-only data
should be read-only
very glad that that happened
so let's chug forward 2008
still doing the 26 thing that's going to
be a common a common theme I become a
Linux user in 2008 this is Ubuntu 804 my
first distro back when they're still
doing the brown thing
does anyone use this gnome too anyone
used to have the the eyes on your panel
did it follow your cursor around it's
Glory Days it's all been downhill since
then
and so we start using some compiler
features to make the kernel more secure
and this is where we we enter canaries
um does anyone show a fans anyone know
the story of this particular device
couple people so this is a canary
resuscitator
um essentially you know in Coal Mines
they would send canaries in to see if
they perish
um and the engineers at the mine felt
bad for the canaries so they invented a
canary resuscitator not for economic
means but just because they felt bad for
killing a bunch of canaries so there's
your fun fact of the day
uh but when we talk about canaries we're
talking about on the stacks so
quick introduction to what the stack is
it's where a bunch of your memory lives
um the idea of a stack Canary is that
the compiler inserts this magic value
into the stack and we want to control
what's on the stack we don't want a user
we don't want an attacker to be able to
modify the contents of a stack if we're
trying to read some some data into a
buffer and we read too much by accident
that will override other stuff on the
stack other stuff on the stack could be
you know the return address where
execution is going to jump to once we
finish this code which is bad so we put
a canary on the stack and then if anyone
modifies the canary then the colonel
panics this means that you can't without
additional difficulty
um
do do buffer overflows as part of an
exploit
um because you're not but while you do
that you'll blow over the canary and the
kernel will panic
so this is the first of many kernel of
many kernel hardening features where
the compiler gets a feature the feature
starts getting used in user space and
then people find a way to make it work
in the kernel nowadays we have multiple
different modes for this for like how
many functions the compiler decides to
put canaries into which is configurable
Kernel build time
so it's a small step but it's an
important step
and now we have canaries
so we're skipping 2009 nothing important
happened in 2009 it's not really
important uh and now we get into the
formative years we've kind of
you know
we've kind of done some stuff here it's
really starting to ramp us up here so
2.6.33 four years later and we're still
doing this
um
I found this which is slightly
horrifying I'm showing it to you but I'm
in my my senior year of high school I
found my badge from grade 12.
um I think that's actually the last time
I wore a tie
so
um yes slightly horrifying
uh I haven't talked about modules yet so
most you probably know what kernel
modules are but they're dynamically
loaded
you know you'll boot up see okay what do
I need load those modules to do that
then at runtime you can dynamically load
and unload your kernel modules
and they have their own separate virtual
address space
um from the core kernel the core
built-in kernel
what this means is that they're
essentially in a lot of ways
um living in a separate memory space and
we haven't figured out what read only
means for modules yet that's kind of a
different thing so uh kind of a problem
we're still using Universal permissions
for all of our kernel modules so if you
can manage to for example
um track a kernel module into writing
somewhere it shouldn't then
you could change the kernel code to run
your exploit or whatever very bad so
thankfully uh we figured out again as a
debug feature that modules shouldn't do
this either it's got the really catchy
name of debug set module ranks uh
ranks means uh read only non-execute I
sure hope no one actually pronounced it
that way but I don't have a historical
reference for that
um and yeah same concept as debug Arrow
data but for modules
years later it was going to get renamed
to the more catchy config hardened
module mappings before finally becoming
strict module rwx so strict kernel iwx
instructor module rwx like core kernel
hardening features that mean that
things like read only means read only
code can't be writable and executable
Etc so but you know we're getting
somewhere
2011. very very impactful year this is
why
we've we've dropped the whole 2-6 thing
it just wasn't
it wasn't really working out uh finally
so we've entered 3.0 very very impactful
so now let's talk about kernel memory
and user memory
things that are logically different but
in terms of the CPU may not be that
different after all so for most CPU
architectures
user space and kernel space share the
same virtual memory they share the same
range of addresses
there's no isolation between them the
same instructions read from kernel
memory is read from user memory and
whatnot so even though they're logically
very different there's no way at the CPU
level with the mmu memory management
unit level
to enforce that barrier so if the
colonel thinks it's reading from
kernel memory but it's actually been
tricked into reading from user memory
it's just going to do it and not care
because there's no actual enforcement of
that barrier so there's a few reasons
why this is bad
so I've got a lovely image I made on the
plane this morning
um so this is our stack again now if you
don't have that isolation then it's very
easy to compromise the kernel if there's
a bug
if you imagine you stack if you imagine
a single function pointer on that stack
so that could be a funk that could just
be a function pointer as a in the kernel
or you could you know beat the canary if
you have one and then change the return
address
you can just change that to a user
address and it'll run your code that
lives in user space so the barrier that
owning the kernel is as easy as I have
this code running in user space trick to
kind of a look at it boom you win
Colonel's yours and a prize
so thankfully and this is an emerging
Trend that continues forward mmus and
side chips are getting smarter Hardware
vendors are starting to focus more on
security they're starting to add more
features either for security or they're
starting to add memory management
features that have Security benefits
uh there's only so much that can be done
by software the problem with enforcing
security things in software is that it's
often slow and you could solve
everyone's security problems but if you
regress their performance by two percent
they won't turn it on so uh because of
this often we need Hardware assists we
need to be able to set things in
Hardware that will enforce our
permissions for us
so this becomes an increasing and
increasing and increasing focus of
Hardware vendors
uh so the thing that lets us fix this
problem is called smap we're really good
at naming stuff
um
so snap on on x86 refers to supervisor
mode execution prevention so what that
means is when you are in
supervisor mode when you are
the CPU and you're executing
code as the kernel you cannot execute
from user memory the CPU just won't let
you so if the Kernel's been tricked
it'll try to do it and it'll just not
work
so basically you toggle this this bit in
the mmu you try to read from a user
address and it just doesn't very cool
very nice so now this doesn't prevent
exploits none of these mitigations
prevent exploits but they make the
barrier a lot higher they make it much
more difficult which means that you
often need multiple smaller
vulnerabilities to be able to actually
compromise something now instead of just
pointing the kernel at your pre-prepared
exploit code in user space
you now have to somehow get your exploit
code inside of the kernel memories it
but inside of the kernel memory itself
which is substantially harder so I think
snap and it's also called pxn on arm
which is privileged execution never I
want to say and it has other names on
other architectures I think this is
probably the single highest value Kernel
Security thing
so good job on that
let's go forward
2012.
uh good year we've seen version numbers
that's continuing on that's all very
good
the world comes to an end I can prove
this with a little anecdote I was in my
first year of computer science at
University
um I was talking I was you know new on
campus I was talking to a cute girl and
I mentioned I was doing computer science
and she says oh do you use Linux I go
yeah I actually use Arch
um and she says wow that's really
impressive now there's no Universe in
which someone would be impressed let
alone a cute girl that someone used Arch
Linux therefore I can definitively prove
that we're all living in a simulation
this also this also happened in in 2012
so good Good Year very iconic moment
there
now
we talked about executing user memory
The Logical extension of of the problems
of that is just accessing user membrane
I said okay well now you have to get
your exploit inside of Kernel memory to
be able to run it but if you can trick
the kernel into writing into and if you
can trick the kernel to maybe reading
from user and then writing that to
Kernel space then you already have your
exploiting kernel memory so we want to
be able to restrict how the kernel
accesses user memory part of the problem
here is that it needs to do it it does
it all the time it will read stuff from
user space and then write it out to a
device or the billion other things that
kernel does so the Kernel's reading and
writing to user memory all the time how
do we enforce some kind of barrier here
how do we actually turn this into a
security benefit
uh so we want to be able to prevent this
in places we don't want it but be able
to do it in places we do we don't have
we want to have our cake and eat it too
is the point here
so we get a thing like Snap called Snap
that lets us do that we get this mmu
feature we can turn on and it prevents
the kernel from accessing user memory
you go to do it and the mmu says no
problem here is you can't just turn that
on all the time like you can with SNAP
because we do need to access user memory
it's it's very important
so thankfully we have these functions
like copy to user and copy from user and
so what we do is when we go to copy to
user we enable being able to access user
memory do what we need to do and then
disable it again
so we can just do that so you're no
longer allowed to just arbitrarily
access user memory you have to do it
using the magic functions and then they
handle all your smapping for you this is
quite a bit more complicated obviously
if you have any way in which you leave
your execution you take an interrupt or
whatever you need to be very careful not
to accidentally leave smap off
which would be bad you also need to not
have smap on when it shouldn't be
I'm only bringing this up because I
wrote the first implementation for power
and basically broke everything and then
smarter people rewrote it so maybe this
is just me justifying my own failure but
it's quite complicated to implement
which leads to uh these copy two from
user functions why do we have them
anyway it's kind of a weird thing if you
imagine someone writing a kernel for the
first time
uh why do we have these functions just
to do something we were going to do
anyway why can't we just directly read
and write the addresses we were going to
I had a bit of a look into this because
here's the thing Windows doesn't have
smap because they have this problem
window the windows kernel doesn't have
these accesses at all user IO goes
through
so they've just got this code base with
direct accesses everywhere they can't
add some stuff to so Windows doesn't
have snap so first of all sucked in
second of all
uh how come we do so we looked a bit
into the history of this because you
know without having these functions it'd
be a Monumental effort to try to find
every single site in which we do this
kind of thing but it turns out in the
very first public release back when the
make file called it freaks FIA X I don't
know what myos was thinking with that
one uh or if it was even him but yeah
it's back in the very first version of
Linux we had these kind of accesses not
not with that specific name but we had
these functions
and part of it was just that lennis
wanted to play with a lot of features of
the CPU he wanted his test fund kernel
to do lots of stuff and so he had user
memory and kernel memory in these
different segments
um so just that little Idea LED to this
feature being monumentally easier to
implement for Linux than than on Windows
which is pretty cool there's also some
architectures that need to do special
stuff to be able to access to be able to
access user memory so
comes in very handy and yet another
Point as to why uh Windows sucks okay
so 2013 versions still sensible which is
good Linux wins Jeopardy I don't know if
you knew that if you have a commit in
the kernel before 2013 then you also won
Jeopardy and you can tell your family
and friends
so this is
um this is IBM's Watson
thing
um running on Linux on power I think so
yes there you go Linux one Jeopardy
beating out uh Ken Jennings and the
other guy who was not Ken Jennings
uh-huh
so if you want me to remember his name
he should have
done better
um
so this is this is when we get Tesla and
this is a bit of an interlude into uh
the kind of complexity versus security
gain issues you have in this kind of
space
so casla stands for kernel address space
layout randomization if you're very if
you've ever done any kind of binary
exploitation and use a space you'd be
familiar with ASLA which is address
space layout randomization so every time
you run a program
it's things are in different spots uh
the layout of its memory gets randomized
so that you can't just find things once
and then reuse the exploit forever
so what if we do that to the kernel what
if we're making when we boot the kernel
all of its stuff goes in different
places so in order to hack things you
need to be able to find where the stuff
lives fun little mini game for
um for exploiters out there
which is a decent idea in theory that
there's there's potentially some issues
with it first of all
uh the kernel now can't leak any
information ever so if you imagine the
code base really big really fast
changing yada yada like the Linux kernel
any single place there that we reveal
the location of something uh to a to
user space
is basically getting around Tesla if we
print out a pointer somewhere if we have
anything that reveals the location of a
symbol and kernel memory then that can
be used to figure out where everything
else is
which is bad so info weeks get around
kasler and there's a lot of code to
detect for info leaks which creates a
lot of work to find and fix all of the
info leaks
kernels also again big mistakes are very
easy
another side tangent rant is that if you
have a casler enabled kernel and you
have like a crash dump or something and
you want to figure out what went wrong
uh good luck figuring that out because
all your stuff's in random places so you
have to beat Casa to figure out what
went wrong
um and then we have this info week
prevention going everywhere around the
kernel you know me printing pointers
everywhere trying to find out what my
thing broke and then I just see
underscore underscore pointer vowel
underscore underscore because you know
that's the world we live in now that's
terrifying
so
has been pretty heavily criticized in
terms of the value it brings
um now that I have quite quote unquote
industry standard casual defeats uh
because there's a lot of them
uh and they've taken the order of
minutes
um to essentially get around Kessler the
fun the one I think is the most fun is
that someone you can you can look at the
voltage of the CPU
um and basically try and access all the
ranges that the kernel could be at
and by looking at the voltage of the CPU
when it spikes you can figure out that's
where the kernel is and so just with
voltage of a core you can figure out how
to get around Kesler which is pretty
cool
so there's a lot of different mechanisms
to find stuff in the kernel
it does make attacks harder but not a
substantial jump so you know you're
taking more of a security researchers
morning as opposed to making an attack
relatively infeasible
so that's Kessler it it tried its best
um and maybe this is just me justifying
what I haven't written castle for power
yet but I I think it's of dubious
Effectiveness and I'm happy to argue
with people about that later if anyone's
anyone's interested
so let's keep going through history uh
we've run out of uh fingers and toes on
Linus 12 odds and so we've incremented
major versions up to up to four three
very impactful year 2015 to the colonel
because here's my first commit
um it's it's all downhill from here I'm
pretty sure this patch is completely
broken but I I was doing my best
um and so this
plus 11 that's uh that's here yeah
[Laughter]
I just moved from Sunny Gold Coast to
Canberra so this patch not the only
questionable decision I made
[Laughter]
the cater Tooling in and around the
kernel
as time goes on and a huge step forward
here was was K sand all the kernel
address sanitizer so asan or address
sanitizers are feature in llvm in clang
you know to find memory access misuses
in user programs and then with
substantial amount of effort that can be
applied to Linux kernel as well so K10
is a dynamic memory safety error
detector it's not the kind of thing you
build into the Linux kernel itself you
run it all the time it's something you
test with
it's not a defense in itself but it
finds spots where things are happening
that should not be happening and tells
you how to fix them sometimes salty if
they've been chasing a case and Bug for
a week
um but KFAN is a huge step forward it
finds things like out of bounds use
after freeze double phrase these are
like the building blocks for exploits
these are the kinds of bugs people write
in memory on safe languages like C that
lead to real world exploits becoming
possible so having the kind of tooling
to be able to find detect and fix them
is really significant
essentially it has a shadow memory
region for for allocations and then when
you try to do them it will check if
you're allowed to do them and if you're
not allowed to do them it will fit out
this nice error report
um
about that so I found this quote I
apparently don't attribute it to anyone
it's just fact that tilde 70 of security
issues a memory misuse bugs but I found
this number in a few different places
especially when you look at
big projects written in C
most bugs are memory misuse bugs so
finding those kind of things leads to a
tangible security benefit you know a
bunch of vulnerabilities would have
become real if you know tools like ksan
hadn't found bug classes like this
is a look at the memory corruption that
K Sands found so it can tell you you
know where the address what object the
address belongs to what the offset is
what page it's in yada yada so very cool
very sophisticated but it's it's slow so
no one turns it on but we do in CI so
that's that's good
this is what happens when you have K
sand now the horrifying thing is what
happens when you Dart and what happens
when you don't is nothing
so if you're trying to debug a memory
corruption hopefully not many of you
have been here I suspect a lot of you
have
is the best case when you have a memory
corruption is that you find it straight
away your kernel crashes and you go and
fix it that's the dream case the bad
case is that you crash and you don't
quite know why it's not really obvious
you have to try and figure it out and
the absolute worst case is you don't
notice something's gone wrong you don't
know how to find it you kind of you know
up creep without the pedal so ksen
solves this because at the point that
the thing goes wrong in the first place
you detect the problem so really
significant step forward
chugging on through history of which
there is still some
versions saying it's my first LCA LCA by
the Bay who here was in Geelong
very nice very nice so
this is when we start getting smarter
about the kernel stack itself so before
I gave you this image of a stack and
said you know you can compromise them
and we have to be careful about that the
kernel Stacks are all allocated using
physically contiguous memory there's no
real infrastructure around it meanwhile
for example all of modules are allocated
using the virtual memory subsystem this
means that addresses can be you know
separate from each other
uh another big benefit is that because
your addresses can be separate from each
other you can have spaces around them
that for example can be marked as you
know poisoned God pages so if you
overflow them it gets detected which is
nice for bug finding reasons I mentioned
before so by reworking the kernel Stacks
to be on top of virtual memory you no
longer have first of all Stacks next to
each other where an overflow on one
stack could compromise the one above it
but you also get much better debugging
information when you do have some kind
of buffer overflow so pretty fundamental
thing there this is my image from before
so this is physically contiguous in the
case of Kernel Stacks until you have
stacks on virtual memory instead so on
virtual memory you can imagine instead
of the return address being right next
to the previous function stack frame
there's a gap and there's you know
poison pages in that Gap that say you're
not allowed to do stuff here
so
the modern era
that was history now we're in here and
now which is 2017-ish apparently but
just roll with it
um so this is the stuff I'm about to
talk about I essentially consider to
have birthed the era wherein now where
security is much more at the Forefront
of people's minds
where we have a lot more capability we
have a lot more technology and people
care a lot more about security so these
guys are a big reason for that
um
so Spectra meltdown essentially a
hardware vulnerabilities so they are
Hardware flaws that allow attackers to
get around a bunch of sensible
protections that the kernel has by just
making the CPU do stuff anyway
um so that's that's lovely and you know
since then a lot of people that aren't
too familiar with this world kind of
think oh yeah that happened we're fine
um but speculative execution is a bug
class of itself and there's been new
vulnerabilities year after year since
then so you know both in software and in
Hardware new techniques to harden
against these kind of things have come
along and the amount of panic over this
specific case really led to a shift I
think in the overall mindset around
security
and I gave a talk at link security
Summit North America last year about
that if people are interested another
huge reason is is Android which I very
helpfully uh put a black font on a dark
background but we'll ignore that
um billions of android devices right
um Android devices run the Linux kernel
compromising the Linux kernel
compromises Android so a huge amount of
investment into these type of things
especially around tooling around things
like sanitizers around fuzzers has come
in
largely motivated by
the huge Target that Android is so the
amount of android devices has definitely
contributed to the overall security and
mindset of the kernel
syscoa which I don't really have time to
get into but Cisco is a assist called
fuzzer so
essentially it just does stuff it makes
the kernel do stuff and it finds when it
breaks stuff and it gives you a little
reproducer so you can break stuff
yourself now some people say Cisco is
the best thing ever look at all the bugs
that's finding we can fix them all other
people say security researchers can now
just checks his call or take something
and run with it which depending on your
mindset both are true but this is the
level of thing we could do now where we
have essentially automated finding bugs
in ways that we've never been able to do
before
so checkouts is cool it's cool
we have a lot more sanitizers
um sanitizers for for concurrency
undefined Behavior Etc
and rust
who raise your hand if you're on the the
rust uh hype train I am
so uh arrest in the colonel people have
pretty mixed opinions so just you know
first of all we can't what we probably
won't but we also can't rewrite the
whole kernel in it it's going to be a
steady trickle
um writing something in Ross does not in
fact uh make it 100 memory secure
especially in the context of a kernel so
riding stuff in Rust doesn't solve a lot
of problems but it does help minimize
them a lot it won't actually do that
um but it is good and it will help
um so right now there are several actual
device
um drivers being written in Rust most
notably probably is the GPU for Apple
silicon
but we will gradually have more rust and
it will gradually help
anyway that's the end of History so
thanks for history thanks for consuming
history hopefully I didn't miss any
history and that's it thank you
[Applause]
we've got time for a couple of questions
quick ones that are actually questions
uh yes
oh yes sorry um was power hit hard by
Specter and meltdown
um was uh Power was vulnerable yes not
to the same degree as Intel in
particular but yeah pretty much every I
think every CPU architecture was hit to
some degree yeah so
absolutely
and uh we've got a little gift here for
you from the organizers in the hackers
space great there's a little speaker's
good for you awesome thank you very much
Russell
[Applause]