RE: the assertion in track_stack, the flaw in it (the added ~) was found by Tycho Andersen, not Alex (though it's not claimed directly, it's implied as Alex is taking credit for the STACKLEAK upstreaming work). This was properly credited below: commit 12927d314b2763dd791ef11e56c42184fba4d3f8 Author: Brad Spengler Date: Tue Aug 15 07:11:47 2017 -0400 Fix 32bit stackleak stack_left test present in grsec only, as spotted by Tycho Andersen This test however doesn't have to do with PAX_STACKLEAK as mentioned there -- you can look at any PaX patch and see that the test doesn't exist. What the check in grsecurity (tried) to do was piggy-back off being called in useful places throughout the entire kernel and in the lack of KSTACKOVERFLOW wanted to avoid a recursion-based stack overflow from being able to cleanly overwrite its intended target. In fact, the same day I made the above change I added an #ifndef to make this explicit: commit 16e1332faabc9f270fde9787ddb23e95cb2aad9c Author: Brad Spengler Date: Tue Aug 15 07:16:30 2017 -0400 Make 32bit stack_left check depend on !KSTACKOVERFLOW to improve performance a bit So it is correct that there was a bug in the check I added that caused it to be a no-op, but it's not part of the STACKLEAK defense and I don't believe we ever advertised that particular added check. A further claim was "STACKLEAK was missing PLACES where the stack needed erasing" (emphasis mine). Alex identified one location in ret_from_fork which in our 4.9 patch was missing instrumentation for x86_32. This instrumentation wasn't missing in the original STACKLEAK code, nor in our stable patches for 3.2 or 3.14. Alex is free to verify this as we have done. It was introduced during some upstream churn in the entry code via the following commit: commit 39e8701f33d65c7f51d749a5d12a1379065e0926 Author: Andy Lutomirski Date: Mon Oct 5 17:48:13 2015 -0700 x86/entry/32: Open-code return tracking from fork and kthreads This open-coding changed ret_from_fork from following a path that would perform the stack clearing to one that would not, and since we didn't have any comment-based guards in place there, it slipped our notice. As mentioned, this only affected i386, and would be rendered benign by having RANDKSTACK enabled (as it is by default in autoconfig) which would clear the full stack on entry to the following syscall (as the lowest_stack field is set to the end of the stack for the new process). Further, the newly-created process' stack would already be cleared in the presence of CONFIG_DEBUG_STACK_USAGE or in any kernel with commit e01e80634ecdde1dd113ac43b3adad21b47f3957 "fork: unconditionally clear stack on fork". Further, it is likely (possibly guaranteed, I'd have to confirm this) that the presence of PAX_MEMORY_SANITIZE (which would be auto-enabled in every instance where STACKLEAK was auto-enabled) would ensure the newly-allocated stack would be cleared with the SANITIZE poison value. There was no other location identified by Alex (and I went ahead and confirmed with v14 that no other location has been identified), so the claim that "places" (a plural) were missing instrumentation is false. Regarding errors in the alloca() checking, Alex's claims there are false. get_stack_info didn't exist when STACKLEAK was first written, but when it was introduced we did convert to using it. We don't needlessly duplicate functionality of get_stack_info, we only have some additional code for correctly computing the amount of stack space left, and our checks there are correct. If Alex would like us to explain to him how his change there is incorrect and our checks are correct, I'd be happy to explain it in full provided he agree to donate $1000 to a charity of my choosing. Now that I've stated he's wrong, he's able to either figure out the reason on his own and correct his statement publicly, or if he's so certain he's correct, has nothing to lose by entering into this challenge. In the case that we're wrong (not possible as we re-confirmed it prior to writing this), I'll be happy to admit defeat and donate $1000 to charity, providing full proof to the public and correcting this statement. So to sum up: Yes there was a bug in an added check in grsecurity that depended on STACKLEAK being enabled, but which wasn't advertised and wasn't part of the STACKLEAK defense. This was found by Tycho Andersen, not Alex, and credited properly in our changelogs. Yes, in some newer versions of grsecurity (after the commit mentioned above) we were missing explicit STACKLEAK clearing in returning from fork on i386 in a newly-forked process. Due to the other factors mentioned above, this likely had 0 real-life impact. No, our alloca() tests aren't wrong and don't needlessly duplicate code. We have made a public offer to donate $1000 to charity if we're wrong on this point (with us offering to provide all the details to easily determine the truth of the statement) provided that Alex agrees to the same terms, as we won't do the KSPP's work for free.