On Mon, Jul 17, 2017 at 09:51:40AM -0600, Jeff Law wrote: > 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.
I can see conditions under which I'd support it depending on architecture and impact, but I can't speak for anyone else, so your probably wise to expect it won't happen. As an example it seems > >> 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. Probably true, but that's not perfect so we're back in the land of balancing probabilities. > >>> 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'm aware the heap can't jump the guard on its own. However my understanding of some of the known exploits was that they used heap leaks to grow the heap until the stack couldn't grow any larger to make it easier to jump the guard. Has anyone looked at how necessary it is to support stack growth on 64 bit arches? I'd hope we could just have a set size that gets faulted in, but I'm probably wrong. > >> 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. Yeah, that's understandable if I thought all of this should be fixed in the compiler I'd agree with not wanting to leave any holes. > >> 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's understandable. > 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. true, though most probing schemes should at least make that harder to exploit, so they are a reason to want to enable checking as much as possible. Trev
