An ancient kernel hole is closed

i know what my response was but it wasn't the only thing what i was referring to (piece of advise, if i may: when you read some text next time, try to see the forest for the trees ;). if you parse your own statements in context in this thread, you'd have realized that you'd previously asked about the security fix being discussed on LKML:

> Was the security community nagging LKML about this issue that whole
> time? (if they were, I'll gladly retract my claims that this is BS).

now my comment you called irrelevant was merely hinting at the fact that this rush of fixes on top of fixes (which made it into the -stable trees after a week only btw, what's your take on that?) could have been avoided had the discussion actually taken place in public on LKML. i see that you still haven't connected the dots though, but i was actually saying that yes, you are right to raise the issue: what you were asking about (public discussion) would actually have been important (something i explained in my previous response too, apparently to no avail). man, i'm beginning to wonder if i'll ever be able to please you! ;)

> 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;

comparing two approaches involves more than the raw code itself, the design/submission/discussion/refinement/etc processes are all part of it. you know, it's called software development. and yes, the two approaches went through quite a different development process.

> Hold on, your link was broken, and I now learned that the web engine
> doesn't automatically match prefixes.

it does, you just have to supply it with a valid prefix (a 'v' isn't part of it).

> 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?

what you call a follow up patch (btw, did you see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... ?) would actually have been part of the actual security fix had the problems with it been recognized originally. you know, as it normally happens in the public discussion/review process that kernel developers use for, well, development.

> 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)?

it has no equivalent because his approach didn't need such crap workarounds. speaking of comparisons, do you realize that comparing things involves pointing out both similarities and differences? unless of course you want to have a skewed one.

> Pathetic.

looks like i must have touched on a nerve ;).

> That patch is explicitly mentioned in the article, you only needed to
> have said that (ie, I had already seen it).

are you implying that you read everything else explicitly mentioned in the article, including Gaël's paper? ;)

> 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),

yes, that is exactly the issue here. you either prevent the stack VMA from growing next to another VMA for good, or you allow that growth but prevent actual use of the stack guard page (ideally, that'd be 'pages', but let's not digress). clearly, Linus didn't like the first approach for some reason we'll probably never learn, so he implemented something else instead.

> it is the means of implementing that solution in code in a way that
> could make its way upstream in a decent timeframe.

implementation details are just that, details. first comes overall design and obviously you don't get to write code until there's agreement on the 'right approach'. now as far as we know, such discussion never took place in public for Linus's solution, it just magically happened (and got fixed like 3 times, and broke all -stable releases in one fell swoop, for a week). call it what you want, i find *that* pathetic.

> So you claim the 2004 patch *was* accepted and included by a vendor (I'll accept that claim on faith).

no need to, you can just dig out the SuSE kernel trees of the time (and ever since, i hear) and see for yourself. or you can just take *their* claims on faith: http://support.novell.com/security/cve/CVE-2010-2240.html .

> That is clearly a problem, I concede that. Why couldn't you just say that?

uhm, say what exactly?

> You are unoriginal.

well, what can i say, it was your term, not mine, so suit yourself ;).

> 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.

Chad, before indulging in more name calling, you might pay attention to what i've been trying to explain to you already: there is *no* guard/gap concept per se. these are *two* *different* concepts. you either have an enforced address space gap *or* you don't but have a guard page instead at the boundary. can you understand this?

> The 'approach' in this discussion was NEVER about the issue of whether
> the guard page/gap concept itself is the right fix. [...]

since these are two different concepts, of course the discussion was always about which one was better.

> So why are you mentioning that now, and presuming it is *me* who doesn't understand?

because you obviously didn't understand the conceptual (let alone implementation) difference between the two. heck, you apparently believed that they were the *same*.

> 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?

i tried to parse this a few times but still can't figure out what you were trying to say here, but back to your original statement:

> You've previously claimed that Linus and the other kernel developers
> are "not qualified" to make judgements about security patches "due to
> lack of expertise".

instead i said this:

> [..]they're simply not qualified to make such judgement calls due to
> lack of expertise.

now what was the judgement call to make in question? quoting dlang:

> the kernel developers and stable team have decided not to try and judge
> which patches are security fixes and which are merely bugfixes.

so what i said was about deciding whether any given patch (newly written code) has security implications or not (i.e., it fixes a security problem, and then let's not get started about recognizing patches that introduce said problems...). i never once mentioned 'security patches' in there, something you were trying to (mis)attribute to me. think about it, if a patch is known to be a 'security patch' (assuming you mean a patch that fixes a known security issue such as this heap/stack gap issue) then there's no need to judge anything, it is a security fix and that's it (mind you, as Jake pointed it out as well, Linus conveniently 'forgot' to omit this little fact from the commit).

so what security experts do is recognize security issues in code (among others), whereas kernel developers write that code (including security fixes, that then gets analyzed by security experts, ad infinitum). it's two very different mindsets, although there're some people who are good at both.

> 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.

i explained a few times already what you don't understand, but then i guess there's only so much one can do ;). when you get over yourself, you might realize that if you stop acting like an RVI, you won't be treated as one.