On 10/23/24 10:18 AM, Niels Möller wrote:
Bill Roberts <bill.robe...@arm.com> writes:
Enable Pointer Authentication Codes (PAC) and Branch Target
Identification (BTI) support for ARM 64 targets.
I only have a rough idea of how these security features work, but I have
I have a talk here on it: https://vimeo.com/1019370992
I'll have more public information available later.
a few suggestions after having a new look at the patch. (These are my
opinions as a GMP contributor, I'm not speaking for the rest of the GMP
team).
1. Must PAC and BTI be used together, or can support be added as two
separate contributions?
I can split up the patch series, but they work better together.
Essentially if you have
pac and bti enabled, the pac instructions work as a bti landing pad.
This means with
both enabled the first instruction can be something like paciasp ...
rest of code instead of 2
instructions like bti c paciasp .... rest of code, if that makes sense?
2. It's not so nice to need a BTI_C line in every(?) .asm file. Please
fold the needed magic inside the PROLOGUE macro. A 900 line patch
looks rather intimidating.
I have this fixed locally. I initially went that way and then abandoned
it to a combination
of bad m4 foo and to get that one instruction speed up, but I think I
understand the PROLOGUE_cpu
better, and my m4 error, and now was able to leverage that to simplify
the patchset and get that
optimization.
3. Tests would help providing some confidence that this works as
intended, and keeps working as intended as GMP evolves. Maybe you can
When building this with CFLAGS='-mbranch-protection=standard', as like
the Fedora package does, the
current test suite exercises this. It would fail with a pile of sigill's
on systems that support BTI and sigsegv
for PAC if something in the assembly is missing.
get some inspiration from this test in Nettle:
https://git.lysator.liu.se/nettle/nettle/-/blob/master/testsuite/x86-ibt-test.c?ref_type=heads
That test does not ensure that Nettle works, it ensures that the
architectural feature works and doesn't
ensure that Nettle has it implemented.You could take that test and drop
it into anyone's project, so I have no idea why this would be in GMP's
tree. This should be in a vendor's test suite or something. What you
really want is a test that ensures it works for the actual gmp code base.
A test could verify (i) that an executable linked with GMP gets the
properly marks (ELF flags or whatever it is) to have the protections
enabled by the kernel,
That should be easy enough and tests that at least gmp has the proper
annotations.
and (ii) that if the executable runs some code
violating the PAC/BTI conventions, than it gets the expected kill
signal.
Offhand, I think an easy test would be to get a function pointer to
something in the assembly,
add an instruction to the pointer value and then call it. Pure C and it
will not land on a landing
pad, but rather the old entry point, that would be a test that tests
nettle, not the processor.
4. "Dynamically generated m4" doesn't sound good to me. I would hope
this support can be added without adding one more level of
preprocessing. I'd prefer either configure tests based on, e.g.,
predefines set by the compiler.
That's what it's doing, it's invoking the compiler to get the
environmental defines and slapping it into the m4.
If the problem is the mechanism of how, and there is a way to move this
functionality somewhere else, like during
configure I am all ears. I guess it would be adding it to DEFS via -D,
but how to plumb it over there isn't clear to
me at the moment, I can look into it more, is that the right direction
you're thinking?
If for some reason it's very
difficult to configure automatically in a robust way, then it's
probably better to start with only a configure argument for enabling
this, and improve on automatic configuration later.
Regards,
/Niels
Thanks, I appreciate your comments.
Bill
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
