> it'd be relevant if you hadn't carefully omitted some bits of my response ;).
Your response was "you mean the one that he had to fix like 3 times?" It didn't seem worth repeating; now you forced me to...
> you see, those bugs could have been found and fixed before committing the patch had they been discussed publicly.
Oh, so instead of being a snarky response to *my* comment that you quoted immediately prior, about comparing the two approaches, it was an unrelated response to a *completely* different issue; I should have guessed you'd bait-n-switch on me. Why'd you quote me if your response wasn't the issue you were replying to?
As I said, it was an irrelevant response.
> so you admit that your claim of "Linus's patches, which *only* touch mm/memory.c" is flat out false.
Hold on, your link was broken, and I now learned that the web engine doesn't automatically match prefixes. A "git log d7824370e" would have worked had I been near my repo at the time.
Ohhhh, so *now* you mean that a follow up patch, which is not actually the security fix, also touches 2 more files, and *that* is what I should have mentioned? The patch which has *no equivalent* in the 2004 AA patch, so it wasn't necessary to point out in my comparison (thus I didn't link to it)? Pathetic. That patch is explicitly mentioned in the article, you only needed to have said that (ie, I had already seen it).
> Chad, i think you should stop commenting on issues you clearly have no idea about.
Oh, yes sir.
Understanding the security issue isn't hard; the article explains it nicely. But it isn't the guard page (or gap) itself that is the issue of discussion here (clearly those involved see that as a solution), it is the means of implementing that solution in code in a way that could make its way upstream in a decent timeframe.
> it's irrelevant to correctness who included it but it was present in -mm of the time and also SuSE, IIRC, but you'll have to do the digging yourself i'm afraid.
So you claim the 2004 patch *was* accepted and included by a vendor (I'll accept that claim on faith). THAT is the whole point. If there was an implementation not only proposed, but also accepted and put in use (ie. tested), then that is (finally) evidence there was a fix in use in the field, that wasn't filtering up into Linus's tree. That is clearly a problem, I concede that. Why couldn't you just say that?
> How irrelevant. (tm)
You are unoriginal.
> by the look of it, you still don't quite get it.
And condescending. Since it was *you* who mentioned the butt-uglyness of the implementation of the accepted solution, it is perfectly reasonable to assume you have issues with the coding details of the guard page/gap solution (not the guard/gap concept itself), which *again* was what my response was specifically addressing. So now you re-define what I meant by 'approach'; that's dishonest.
> now that you (hopefully) understand what 'approach' means in this context
The 'approach' in this discussion was NEVER about the issue of whether the guard page/gap concept itself is the right fix. So why are you mentioning that now, and presuming it is *me* who doesn't understand? You wanna claim that the security expert's job is to "recognize" issues in existing code, and not "write new kernel code" to fix it, then stop yammering about the coding details of the solution UNLESS you are claiming that it is insecure? Is it?
Your ego based, toxic form of communication is a thread killer, and it wasn't worth initially responding to. I thought you'd shed some light. If you are at all representative of how insanely frustrating it must be for implementers to get security feedback on their code, it helps explain why there can be such a long disconnect. I guess that is somewhat enlightening in itself.