On 07/16/2017 12:36 PM, Trevor Saunders wrote: >>> On the other hand if probing is fast enough that it can be on by default >>> in gcc there should be much less of it. Even if you did change the ABI >>> to require probing it seems unlikely that code violating that >>> requirement would hit problems other than this security concern, so I'd >>> expect there will be some non compliant asm out there. >> Certainly my goal is to enable it by default one day. Even if that's >> ultimately done at the distro level or by a configure time switch. >> >> Certainly if/when we reach that point the amount of unprotected code >> will drop dramatically, but based on my experience I fully expect some >> folks to turn it off. They'll say something like "hey, we've audited >> our code and we don't have any large stack or allocas, so I'm turning >> this thing off to get some un-measurable performance gain." It'd be an >> uber-dumb thing to do, but it's going to happen. > > I agree with that, though we could consider not having an option for it. > Of course people can compile there own compiler, but I think its pretty > clear if you do that the security problem is your fault too. I suspect not having an option is a non-starter. But maybe I'm wrong on that one.
>> Tweaking the ABI to mandate touching *sp in the outgoing args area & >> alloca space is better because we likely wouldn't have an option to >> avoid that access. So a well meaning, but clueless, developer couldn't >> turn the option off like they could stack checking. > > However see the comment about assembly code, I can easily see someone > forgeting to touch *sp in hand written assembly. Obviously much less of > that, but it kind of sounds like you want perfect here. Perfect would be good :-) The odds of hand written assembly code having a large enough outgoing args size or dynamic frame to require touching is exceedingly small. >>> It seems to me pretty important to ask how many programs out there have >>> a caller that can push the stack into the guard page, but not past it. >> I've actually spent a lot of time thing about that precise problem. You >> don't need large frames to do that -- you just need controlled heap >> leaks and/or controlled recursion. ie, even if a function has no >> allocas and a small frame, it can put the stack pointer into the guard. > > There may not be room for it on 32 bit platforms, but I think another > thing we learned here is that its a mistake to allow the heap to grow > into space the stack might use. That would require the use of recursion > here. The heap grows in response to explicit requests and appropriate checks can be made to prevent jumping the guard due to heap growth. It's the implicit mechansisms for stack growth that cause headaches. >> I think the largest >>> buffer Qualys found was less than 400k? So 1 256k guard page should >>> protect 95% of functions, and 1m or 2m seems like enough to protect >>> against all non malicious programs. I'm not sure, but this is a 64 bit >>> arch, so it seems like we should have the adress space for large guard >>> pages like that. >> I'm all for larger guards, particularly on 64 bit architectures. >> >> We use 64k pages on aarch64 for RHEL which implicitly gives us a minimum >> guard of 64k. That would be a huge factor in any analysis I would do if >> the aarch64 maintainers choose not to fully protect their architecture >> and I was forced to make a recommendation for Red Hat and its customers. >> I hope I don't have to sit down and do the analysis on this and make >> any kind of recommendation. > > Its certainly easier to say its not the compilers job to fully protect > when you don't have to make that recommendation ;) Lots of factors come into play. What I don't want to do is put Red Hat in a position where some customer gets hacked because we left open a known hole that we could have reasonably closed. > >> The fact that Qualys found nothing larger than X (for any X) in the code >> they scanned isn't relevant. There could well be code out there they >> did not look at that uses > X or code that is yet to be written that >> uses > X. > > If you want to protect all code someone could write I agree. I've been > thinking more about protecting most reasonable code and saying if you > allocate a 50mb buffer on the stack that's your bug, and we don't need > to make that safe. Depends on your point of view. I can't reasonably take that position with my Red Hat hat on. In that role, I would say that any architecture for Red Hat Enterprise Linux needs to have a minimum level of protection against stack clash style attacks and that would include being safe against someone allocating very large structures on the stack. Such code may be dumb, such code may be inefficient and not terribly portable. But in the environments where RHEL is deployed, we can't just dismiss it out-of-hand. That level of protection does not necessarily extend to an unbound alloca/vla because if it's unbound, then it's just a matter of controlling the size and when the unbound alloca occurs to jump the stack -- no amount of compiler hackery can fix that situation. > > It might well not be what you need, but it does kind of seem like what's > generally useful is protecting almost all if not all "reasonable" > programs with the least performance impact. Looking at various real > programs to decide what is reasonable or not seems like a good way to > draw that line. Its an interesting exercise, but more from determining what are the common cases so that those can be made the most efficient. > >>> On the other hand making -fstack-check=clash the default seems to me >>> like a very significant security improvement. >> Agreed and it's where I'd like this to go. > > yeah, I'm just wondering if it isn't possible to get there already on 64 > bit machines with some kernel changes. > > thanks / sorry about lag. No worries. Thanks, jeff
