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
Sent from my iPad
On Jul 12, 2013, at 5:36, Jonathan Masters <jcm(a)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.
Sent from my iPad
On Jul 11, 2013, at 20:03, Jakub Jelinek <jakub(a)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.
> devel mailing list
devel mailing list