The stack-protector issue has been raised to priority number one for the library folks within the Linaro toolchain group. I have followed up with members of the toolchain and steering committees as appropriate to ensure this is going to be taken care of extremely swiftly.
Next! -- Sent from my iPad On Jul 12, 2013, at 5:36, Jonathan Masters <j...@redhat.com> wrote: > 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
