So my name is Peter, I work for arm and I've been sort of tangentially involved in the
point of authentication IBI, mostly by deans of being the author of the specification.
I've written absolutely none of the code, so at this particular point I'm presenting
mostly other people's work here.
So first of all, what I'd like to do is quickly explain what point of authentication is,
I'm not sure everyone will know what that is and then I'll go on for why I'm talking about this.
So just in a nutshell, and it's very, very simple as forms, you've got two basic operations
to first of which is sign and sign will take you a raw pointer, a secret key that's sort of
known to the hardware and a local discriminator that's sort of normally derived from something local
to a particular function and the instructions that you'll see in a sembler here are called
start with pack for a point of authentication code.
The nicer they start with sign, but unfortunately it's pack and then there's the reverse operation
of that which is an auth short for authenticator obviously and that takes a sign pointer in terms
it back into a raw pointer and it uses the same key and the same discriminator that was used
when you sign your pointer and then you have the alt instructions that are basically the
mirror image of the previous ones at that point. So how's this working hardware?
Sorry, I just didn't mention the key is shared secret, discriminator is local and
the tricky bit about the point of authentication, ABI is that you've got to choose which
point is to sign, you've got to choose what key to use and you've got to choose what to discriminate
to use for every particular pointer in the program and everyone who's signing and everyone who's
authenticating has to agree on what those are and every time you change it it's an ABI break.
So it's one of those things where there are deployment challenges with this to say the least.
And there's another form of what you would call ABI clean or at least an ABI neutral form
of pointer authentication. You might use already on an A64 system that's branch protection equal standard
which is where we use pointer authentication to protect the return address. Whereas pointer
authentication ABI goes a lot further than that. So how's this working hardware? Well,
what we've basically explained is that no one yet has got 64 bits of virtual address,
addressable memory. So some of the spare values at the top of the pointer available for extra
metadata and what we do is we use some of that to store the pointer authentication code.
So when we do one of these pack instructions, we take the key and then two registers, one of them
contains the pointer that we want to sign and another one that takes the modifier and then we put
the result of that calculation into the top bits at that particular point. So why am I actually talking
about this? So pointer authentication ABI is not new. It's currently restricted
at the moment in terms of use of pack to the branch protection equal standard. And that's as I've
mentioned before, optimised for being as deployable as widely as possible. It all work on all
machines because it's implemented in the hidden space. Now the PLTABI has existed as a specification
for about five years and this is all derived from Apple's 64E ABI. So that was the genesis of this
and Apple have done a lot of the hard work for this and you'll be able to find a lot more information
on Apple platforms for the ARM 64E. I'm talking specifically here about the elf implementation
of that which is sort of more deployable on potentially Linux potentially other systems that use
else. Now the pointer authentication ABI extends pointer authentication to all code pointers
but the downside of that is that you need hardware that supports it which is ARM V8.3A and it's
likely an ABI break if you've already got an existing system. So the specs being around for about
five years there's been a group diligently, well from access, off-tech, a company who's been
diligently working away on an elf implementation for, I don't know, probably the last three years
or so, maybe two, and upstream LLVM has finally got an implementation for testing.
It's not an official target as yet because there's not a fully defined ABI but it's certainly
now something that you can try out with upstream LLVM. So I'm just basically talking about it here
to ways raise a bit of awareness of it or what it might be able to do because we're also kind
of in a chicken and egg problem and until somebody implements it no one can try it and no one's
going to bother implementing until somebody wants to use it. Okay and I'm talking about embedded
systems particularly that's mostly because that's where my background is but also their metal doesn't
have as many ABI continuity problems you might be able to just have a completely separate
system target that and go rather than trying to say false it into an extribution. Okay and yeah
I would like to see points for authentication ABI to have an official elf target that anyone can
use to build a system. Okay so yes this is just an example code to show how things would go. So
you can imagine we've got a C++ VTables, so VTables are tables of co-pointers for example.
VTables is an interesting case because there's actually a VTable point for itself and that is
strictly speaking a data pointer but the point to authentication ABI thinks that is important
enough to protect anyway. So we take this so what this thing is actually going to do is going to load
the VTable VB, it's going to load the address of the function from the VTable and then it's going
to indirectly call it. So we look at the generated code from this we see the use of the point
to authentication instructions. So we've got the first one pack IBSP which is kind of a short hand
instruction for protecting the return address using the stack pointer as modifier and you'll see
that matched at the bottom with the retab which is kind of a combined return and authenticate at this
point. So the other instruction you can see there is AltDA which is DN is authentic the VTable point
of so that's already been signed when the class was created and then this BLRAA which is a combined
branch and authenticate at that particular point. So at this point you don't see any of the signing
but above those or engine instructions you can see the moth case that's the blending of the
discriminator as 16 bit value into the address to form the modifier, particular point.
Okay, so what actually exists in upstream L of the end today? So we have an experimental
target called PLF test which you can use with the Linux OS at the moment. I think it's
restricted to Linux if you try it with something else it probably won't work but yes target equals
AR64 Linux PLF test to get some sample code generation going. Yeah and there's no one's committed
to an ABI yet. It's currently for testing purposes so it's been deployed so that we can
write tests and upstream L of the end to it. There's also a header file coin port pointer off
dot h and that's where you can manually control how pointers are signed with a things like the
pointer off qualifier and that's recommended for things like C function pointers because C lets you do all sorts
of stuff with function pointers that limits what sort of modifier and address diversity can
be done with it but if you're manually doing it yourself you can put more protection on it than the
basic one. Okay and of course the killer at the moment is you need compatible runtime libraries
and you need a dynamic linker to support it. So why do you need dynamic linker support? It turns out
this is because quite a lot of set pointers are statically initialized and because the keys only
known at runtime the static linker can't sign any pointers and before hands it has to be signed
when the program loads up and to do that we've extended some of the dynamic relocations and so
that when they do the relocation calculation they do an immediate sign afterwards. Of course the
dynamic linker needs to know how the signings done and what I was assigning schema is sort of embedded
in the location that you're relocating so if the dynamic linker will pick that up read it which tells
it exactly all the instructions it needs to do. Okay so if you want to try this out today in Linux
user space the team ss of tech have provided some build scripts where you can build a muscle based
Linux statically linked Linux tool chain so yes basically there's a a docker container that you
can run that will build your tool chain. It produces a squash FS file system that you can mount
and then from that you can run the the programs produced on quennu user mode or if you
lucky enough to have an 8.3 save for example you're running Linux on a on a Mac via some kind of
virtualization or whatever then you can run it directly on that at that point so that's the easiest way
to try this out today yeah building the tool chain isn't too much for problem okay so what to what
my part in this I guess is trying to see can we run this on bare metal okay so as I mentioned before
hardware requirements are less of a problem at that point so what we need to do build ourselves
an embedded tool chain used quennu to check everything's running so what's on my shopping list at the
moment so first of all I could add peel test support to the bare metal drive because it's currently
fixed Linux I've got a compile all my runtime libraries I've got to get some support code to actually
turn the point of authentication on I've got to get a link a script that's going to get the dynamic
relocations and put them in a location where I know where they are so I can go and resolve them and
then I've actually got to write the resolve that I go and do that okay and then I've got to make
sure the excuse me the the link can go and pick up the things down okay so what I've done here
is I've made a fork of L of the M which builds all all of this from L of the M components
and I've put the link in the reference as many as interested in trying it out so what's my experience
so adding the bare metal target didn't take very long it was just basically cutting pasting
code from the Linux driver L of the M lipsy had some assembly that changed I won't go into too much
of the details there but it's essentially down to that in minor assemblies doing direct branches
but when you access things with the point of authentication ABI it wants to think it wants it
done indirectly via a register so you need to change the constraints and instruction used and
that bit of link a script there is just going to define some symbols relay didn't start relay
didn't end I just I chose those names so that I can find them later on okay this is how you
would do the dynamic relocations what I've got there is the things that are in sign on there
are just where the signing scheme was encoded for example it would be like if addressed diversity
and discriminator then take the current location of the relocation blend the 16 bits of
the discriminator into that value then sign with the key that's in that particular bit so it's not
particularly complicated okay so my last slide here besides the references what the next steps
are P.O.T.A.B.I so yeah the support is currently chicken in the air at the moment so
it's in their own the team access soft tech are doing this for a downstream platform so this
is not something that's easily available to use but to get upstream support we need at least
one platform of something real to actually use it I think that it's likely that the number of
possible signing schemers will coalesce into a small number of variants maybe say three and at that point
there's a chance to get this in as a properly supported target and then anyone can build a tool
chain from there okay so just some last references here the one thing I would say so if you
if you are interested in this at all the first one there the client documentation on point
authentication is very good because it also goes through some of the caveats that you need to do
to avoid things like signing or recalls and how to really protect your system so it's a very
very good document fully recommend that and then there was a talk last year at the L.O.B. I'm dev
meeting so it's now two years ago we're in 26 now from access soft tech that's also with
watching so that's all I had for you today there is there maybe some time for questions or I may
have over run two minutes I can probably take a couple of questions but if not find me outside
Thank you
you know go a bit more to detail like how the P also ABI and I'm six before E.D.E.D. and so what are the
differences on that promising for example the keys to be used for the different signing of
right okay so I don't know precise details obviously the object file format's very different
so there's macro at one point L from the other I believe there may be also differences in some
of the relocations that get used I believe the signing scheme I was picked to be as close as possible
just to know as you don't have if this do this all in the other in devrims and no
Nicholas differentiation and there are things like is the got signed or access to the got because
it's your to if you've got relocation we don't need to sign the got but if your platform doesn't
have that you do so it's mostly a whole bunch of toggleable things and so yeah I'd say it's
very similar at that point that I couldn't give you detail sorry yes yeah where is this a bit
on finance okay it's it's hard work yeah so there are various keys for various
exception levels so user space is one exception level there'll be a kernel level exception level
each of them have got keys that can be set by the exception level higher
it's I think it's just standards set hardware is to that type of thing but yeah
okay so I guess if there's no more questions it would probably best to hand over the next
um oh one more with that and I don't know the full details I think at the moment it's used
by kernel space behind the scenes I don't I there is at least some documentation of how to
use it in user space but I don't know how widely it is unfortunately not very familiar with macOS at
that point yeah okay thank you very much