Date: Fri, 23 Jun 2017 22:05:38 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: oss-security@...ts.openwall.com Cc: Jeff Law <law@...hat.com> Subject: Re: Re: Qualys Security Advisor -- The Stack Clash * Daniel Micay <danielmicay@...il.com> [2017-06-22 01:39:46 -0400]: > On Wed, 2017-06-21 at 11:33 -0600, Jeff Law wrote: > > On 06/20/2017 12:44 AM, Daniel Micay wrote: > > > I think it's also worth mentioning the segmented stack support in > > > GCC > > > and LLVM that was added for Go. It's possible to use it for C with > > > the > > > __morestack call set up to simply abort when stack space is > > > exhausted. > > > > > > That's what Rust was doing after it dropped segmented stacks, but > > > they > > > wanted to move to stack probes for efficiency and prematurely > > > dropped > > > these function prelude checks. > > > > > > It's not efficient, but it works, unlike -fstack-check. > > > > > > I don't think it makes sense for general purpose distributions to > > > adopt > > > it but it's an available option for others with more concern about > > > this > > > issue. > > > > Yup. go's split-stacks are another option. As you mention, probably > > not performant enough for a general purpose distribution, but could be > > interesting for more specialized needs. > > > > jeff > > It can be used with large fixed size stacks and no actual expansion, but > yeah it's expensive to add a check to every non-leaf prelude. It's not > as expensive as the SSP check for a function but it needs to cover many. > > Since probes can be so much more efficient, it only makes sense to > consider it if getting probes fully working is going to take a long > time. split stack is broken, it cannot be mixed with non-split-stack code reliably, the runtime provided by the compiler cannot possibly be conforming for thread creation, thread exit, user allocated stacks and it can crash randomly. but it is not even supported on some targets so i think it's not a viable workaround anyway.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ