Re: F20 System Wide Change: ARM as primary Architecture

Note that there are teams within Linaro doing benchmarking and driving such. And once the specific
stack protector issue was raised, I poked Marcus in person and he escalated it such that it will be
looked at this next engineering cycle. In general we can plan ahead if we know there are issues. We
can't offer a 4 hour SLA. This isn't meant to be aimed at Jakub :) just replying here.

Btw, on a tangent, those throwing stones in the other subthreads need to bear in mind no
architecture can guarantee every feature at all times. If you would like, we can scrub through and
find something broken on x86 that a test suite claims to work, and we can infer all kinds of
insulting things from that. But it will achieve nothing. Sometimes stuff just is unintentionally
broken. Audit was one such issue a year back - silent register corruption due to a busted patch and
lack of people historically using it to notice. But we fixed that. And we will find more issues
over time and fix those, especially now that we have many folks running Fedora kernels and others
in Linaro ramping up on testing upstream with non-embedded configs.

Jon.

-- 
Sent from my iPad

On Jul 11, 2013, at 20:03, Jakub Jelinek <jakub@redhat.com> wrote:

> On Thu, Jul 11, 2013 at 11:52:34AM -0700, Brendan Conoboy wrote:
>> On 07/11/2013 11:49 AM, Jakub Jelinek wrote:
>>> Stack guards are present, but using libssp, which is the fallback way,
>>> second class citizen and most likely slower than the standard way.
>>> E.g. the libssp stack guard setup always uses /dev/urandom, while I guess
>>> even on ARM kernel provides AT_RANDOM that can be just used.
>>> And I'd bet that even on ARM reading the stack guard via TLS (well,
>>> static only always, i.e. hardcoded offset from TLS register), especially for
>>> PIC, is faster than doing GOT read and two memory references.
>> 
>> Thanks.  Security-wise, is the implementation roughly equivalent in
>> what is protected against, albeit less efficient?
> 
> Not sure how exactly /dev/urandom compares to AT_RANDOM security-wise,
> but most probably it is just less efficient.  Definitely something to be
> benchmarked, analyzed for code size etc.
> 
>    Jakub
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel