On 10/14/2013 10:55 AM, Matthew Garrett wrote:
> On Thu, Jul 11, 2013 at 01:39:21AM -0400, Carlos O'Donell wrote:
>
>> Next steps:
>> - Verify libssp works correctly on 32-bit ARM.
>> - Look at enhancing the existing support in glibc.
>> - Add TLS stack guard.
>> - Add TLS pointer guard.
>> - Add pointer mangle/demangle support.
>> - Enhance aarch64 to support the same set of features.
>
> Did the arm32 portions of this end up being completed for F20?
For 32-bit ARM on f20:
- Stack guard:
- Existing glibc support provides stack guard value in global
variable and is used by existing runtime. Regression tests are
passing in glibc testsuite. Verified working. Upstream verified
that global variable is the best compromise for performance across
all 32-bit ARM targets (TLS will be too slow in the average case).
- Pointer mangling:
- Not supported.
Upstream glibc 2.19 summary:
- Stack guard support already present using global variable.
- Will have pointer encryption support using global variable,
and could be a candidate for backport to f20.
~~~
commit b7f2d27dbd85f6a0966dc389ad4f8205085b7ae8
Author: Will Newton <will.newton@xxxxxxxxxx>
Date: Wed Aug 7 13:55:30 2013 +0100
ARM: Add pointer encryption support.
Add support for pointer encryption in glibc internal structures in C
and assembler code. Pointer encryption is a glibc security feature
described here:
https://sourceware.org/glibc/wiki/PointerEncryption
The ARM implementation uses global variables instead of thread pointer
relative accesses to get the value of the pointer encryption guard
because accessing the thread pointer can be very expensive on older
ARM cores.
...
~~~
Do we need pointer mangling? If so then we need someone to file an
f20 specific bug so the glibc team can look at backporting the fix.
I won't commit to it until I review exactly what might need changing.
Cheers,
Carlos.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
