Re: F20 System Wide Change: ARM as primary Architecture

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/15/2013 12:53 PM, Matthew Garrett wrote:
> On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote:
>> On 10/14/2013 10:55 AM, Matthew Garrett wrote:
>>> 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).
> 
> What's the effective difference in security between this and the 
> existing ports?

There is no effective security difference between accessing the randomized
stack guard value from a global variable or a value stored in the dynamic
thread vector.

It is only a performance optimization. The choice of a global variable vs. 
DTV offset has only to do with the speed of access of the stack guard.

>> - Pointer mangling:
>>   - Not supported.
> 
> Do we ship it in the x86 ports?

We do.

>> 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.
> 
> Cool. This is a runtime change, right? There's no requirement for a 
> rebuild to take advantage of it?

That is correct. It is only an internal glibc change that does not
require any rebuilds for applications to take advantage of this.
The pointer mangling is hidden from the application.

>> 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.
> 
> The aim was for parity of important features, but it doesn't seem like 
> we've ever advertised pointer guard as a Fedora feature so I'm not 
> personally that worried.

Pointer mangling is useful, but we can roll that change into an update
and it should not in my opinion block F20.

I've filed:
Bug 1019452 - [ARM] Backport pointer mangling support from upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=1019452

Cheers,
Carlos.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux