* Jeff Law: > On 06/28/2017 12:45 AM, Florian Weimer wrote: >> * Richard Earnshaw: >> >>> I can't help but feel there's a bit of a goode olde mediaeval witch hunt >>> going on here. As Wilco points out, we can never defend against a >>> function that is built without probe operations but skips the entire >>> guard zone. The only defence there is a larger guard zone, but how big >>> do you make it? >> >> Right. And in the exploitable cases we have seen, there is a >> dynamically sized allocation which the attacker can influence, so it >> seems fairly likely that in a partially hardended binary, there could >> be another call stack which is exploitable, with a non-hardened >> function at the top. >> >> I think a probing scheme which assumes that if the caller moves the >> stack pointer into more than half of the guard area, that's the >> callers fault would be totally appropriate in practice. If possible, >> callee-only probing for its own stack usage is preferable, but not if >> it means instrumenting all functions which use the stack.
> That position is a surprise Florian :-) I would have expected a full > protection position, particularly after the discussions we've had about > noreturn functions. I might have gotten carried away on that one. I really want stack probing to be enabled by default across the board, so this becomes a non-issue because the caller has been compiled with probing as well. However, in order to get there, we need extremely cheap instrumentation, and if we cover any hypthetical corner case, this might force us to instrument all functions, and that again defeats the goal of enabling it by default. Does that make sense? > I guess the difference in your position is driven by the relatively high > frequency of probing worst case assumptions are going to have on aarch64 > with a relatively small vulnerability surface? Right, and I expect that the limited form of probing can be enabled by default, so that eventually, the caller will take care of its share of probing (i.e., it has never moved the stack pointer more than half into the guard page, or whatever caller/callee split of responsibilities we come up with). > Which is a fairly stark contrast to the noreturn situation where it > rarely, if ever comes up in practice and never on a hot path? I've since researched the noreturn situation a bit more. We never turn noreturn functions into tail calls because the intent is to preserve the call stack, in the expectation that either the noreturn function itself performs a backtrace, or that someone later looks at the coredump. So the noreturn risk just doesn't seem to be there.
