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 <ja...@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
