LWN: Comments on "An ancient kernel hole is closed"

An ancient kernel hole is closed

nix — Fri, 03 Sep 2010 00:20:27 +0000

You would also have known about the additional hacks Linus added specifically to account for an incompatibility with an LVM app

Well, the LVM app was doing something sufficiently bizarre that if you'd asked me beforehand, I'd have said of course nobody would do anything like that. (I mean, parsing /proc/self/maps and mlock()ing everything you see? Why not mlockall()? Why would it fail for the guard page yet not for the vdso or vsyscall pages? Well, now we know.)

So, Linus didn't test every single app in the entire world before releasing a security fix. He didn't even test every ramification of every app on his machine. That's simply terrible. He should be publically whipped.

Xorg flaw

mgedmin — Mon, 23 Aug 2010 23:42:50 +0000

The bad thing that malicious programs can do is send emails using the user's bandwidth (and their IP, to avoid spam blacklists).

VM_GROWSDOWN

PaXTeam — Mon, 23 Aug 2010 17:51:51 +0000

when talking about getting rid of VM_GROWSDOWN, it seems that people forget that it does not only expand the stack as needed, but it can also detect a kind of userland bug where the stack expansion request is beyond a certain architecture dependent limit (just look at the callers of expand_stack in the arch specific page fault handler and the checks before that). so statically allocating the initial task's stack range would let those bugs go undetected in the future. now admittedly this is a rare bug class (IIRC, gcc 2.96 had such a code generation bug) but it still means that there'll be a userland visible change when you get rid of VM_GROWSDOWN.

VM_GROWSDOWN

helge.bahmann — Mon, 23 Aug 2010 17:35:06 +0000

I'm not sure there are that many applications that rely on "unlimited stack" meaning "allow to fill the entire address-space", but that's why I would not change the default behavior and pick a new elf flag instead (and for anyone needing ridiculously large stacks, split stacks are IMHO the better long-term answer, see http://gcc.gnu.org/wiki/SplitStacks).

There is certainly the practical question of what it means to run a process with stacksize == RLIMIT_INFINITY when the stack vma is supposed to be fully expanded -- I'd say pick some random really large value like 512M, just enough to get sysvinit/upstart/systemd/whatever running, demand that sane limits be set afterwards and have admins suffer really if they do not.

In any case, apparently nothing breaks with my distribution's default 8MB stack rlimit, so I would expect that gradually converting the whole system over to use pre-allocated stack VMAs would not hit too many obstacles.

VM_GROWSDOWN

foom — Mon, 23 Aug 2010 13:13:45 +0000

Sure, but there's already differing behavior depending on whether the stack size is limited or not.

If the stacksize is limited, mmap starts allocating below the stack rlimit (the stack is at the top of memory) and moves down until it hits the heap at the beginning of the memoryspace. Then it'll start filling in holes in other places (such as between the end of the actual stack and the stack rlimit size).

If stacksize is not limited, mmap starts allocating partway between the heap and stack, and moves up until it hits the stack. And then starts filling in holes (such as below the begin address above the heap).

It seems to me that it'd be fairly sane to in the first case, also disable the VM_GROWSDOWN behavior and just allocate a stack of the RLIMIT size immediately. But that *would* mean that you lose RLIMIT_STACK amount of memory in your VM space which could've otherwise been used for mmap'ing, which might be a problem in some cases.

VM_GROWSDOWN

spender — Mon, 23 Aug 2010 12:44:33 +0000

What about RLIMIT_INFINITY?

on a 64bit OS, the max stack size is larger than the possible address space
on a 64bit OS with a 32bit userland app, the max stack size is larger than the possible address space

(these are both bugs still waiting to be fixed even though I've already published http://grsecurity.net/~spender/64bit_dos.c)

on a 32bit OS, the only limitation is on the initial arg/env stack, limited to 1GB (it should be the same with the 64bit OS and 32bit userland app above, but it's not)

you sure you want to do that reservation? ;)

-Brad

VM_GROWSDOWN

helge.bahmann — Mon, 23 Aug 2010 06:33:09 +0000

You are right that this is not a short-term solution, vulnerable apps would stay vulnerable this way until they were recompiled to have their elf flags changed to take advantage of a pre-allocated stack. The implemented "solution" however just trades a "code injection" vulnerability for a "denial of service" vulnerability. While this is an improvement, it should IMHO therefore not be the final answer.

I am not sure single-threaded apps with large stack requirements are the problematic case here -- they are already now bounded by the stack size rlimit, so the kernel could make an initial reservation of exactly the specified rlimit to keep them happy, which should be doable and even resizing the VMA in case the app changes its rlimit should be possible (with the added bonus of the kernel immediately detecting that resizing failed due to collision with other mappings). More likely the problem cases are apps that do "fancy things" wrt their memory mappings, but short of trying it to see what breaks there is probably no way to discover which these are :)

VM_GROWSDOWN

Blaisorblade — Sun, 22 Aug 2010 22:55:52 +0000

What you suggest is not sufficient. What would happen with existing vulnerable applications? You cannot remove VM_GROWSDOWN for them.
So we have some sort of mess. Reading the description, I think what got in is messier than Arcangeli's proposal. But I digress.

However, since VM_GROWSDOWN seems to be used just for the stack of the main thread (I think it wouldn't be possible to do otherwise for reasons already discussed), ditching it out would mostly make sense. _Except_ if you have a single-threaded application (and there are lots) which needs a big stack. So now each application has to decide whether to switch to the new layout.
For myself, I would enable the new layout by default, but I know somebody is going to complain; unfortunately, backward compatibility makes such changes hard.
Just my 2 cents.

recursion

jeremiah — Sun, 22 Aug 2010 03:31:51 +0000

>AFAIU It is always possible to transform a recursive algorithm into an equivalent iterative one which stores intermediate state on the heap.<

you don't write much XSLT do you...;)

An ancient kernel hole is closed

chad.netzer — Sat, 21 Aug 2010 20:39:32 +0000

This 'fisking' style of back and forth responses to specific lines of text doesn't seem to be helping.

Basically, there is a response to a specific point with a new point (or implied new point), without enough context to show how it's related, and there's just a pointless adversarial back and forth.

One of your recurring points in this thread is there was no public discussion of this new patch (or series of patches, really). Which is a fine point to raise, and worth a thread of its own (as it's mentioned in the LWN article). I don't disagree with the criticism of that point. But working it in as a response to an unrelated (IMO) one line quote, is not useful. Rather than a discussion on a good new, and related issue, it leads to a confused argument.

Note, I gave you credit (I felt) for answering my question about which vendors had already guarded against this (SuSE), and I conceded that that was damning evidence about the development and upstreaming process, and a *core* point to make. So, thanks for that.

I'm done with the arguing. I learned a few things, I hope it wasn't a waste of space for the site. However, I am not continuing it.

An ancient kernel hole is closed

PaXTeam — Sat, 21 Aug 2010 14:31:17 +0000

hey, i got an ever better one you can chew on: http://lists.immunitysec.com/pipermail/dailydave/2010-Aug... ;)

An ancient kernel hole is closed

PaXTeam — Sat, 21 Aug 2010 14:29:45 +0000

> Your response was "you mean the one that he had to fix like 3 times?"

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.

VM_GROWSDOWN

helge.bahmann — Sat, 21 Aug 2010 11:58:47 +0000

The stacks for threads are not allocated with VM_GROWSDOWN [*], so you already pay the "price" for a fully reserved address space there. VM_GROWSDOWN apparently onlys affect the main thread, so the expenditure of additional 8MB of address space is really only once (and if the admin likes fine-tuning, s/he can always rlimit this further down).

[*] I don't see how GROWSDOWN would make sense for thread stacks, to provide any meaningful growth potential for them you would have to thoughtfully sprinkle them throughout the address space and carefully dance around these locations with other mappings.

Xorg flaw

niner — Sat, 21 Aug 2010 09:12:41 +0000

"send e-mails in the user's name, etc."

Just because this is one of my favourite misconceptions floating around: nothing at all prevents anyone from sending e-mails in any user's name. Same as you can write any name as sender on an envelope of bad old snail mail. The only thing proving the identity of the sender is in both cases a signature. The electronic version even more so than your easy to fake hand writing. And of course, such a signature should not lie around on your computer unprotected...

stack management

chad.netzer — Sat, 21 Aug 2010 04:32:23 +0000

The article mentions the Delalleau paper, and spender points out that it discusses a lot of the issues you raise, and has informative graphs. So check it out.

http://cansecwest.com/core05/memory_vulns_delalleau.pdf

VM_GROWSDOWN

chad.netzer — Sat, 21 Aug 2010 04:28:06 +0000

Threaded processes can conceivably allocate a lot of (mostly unused?) stack space, and the kernel allows processes to specify a much bigger limit for those wacky applications that need it. Also, mmap'ing applications can put a lot of pressure on the 32-bit address mapping. So the address space may not be as cheap as you envision.

As the article mentions, and spender helpfully emphasizes, the Delalleau paper gives a good graphical overview of the situation.

http://cansecwest.com/core05/memory_vulns_delalleau.pdf

An ancient kernel hole is closed

chad.netzer — Fri, 20 Aug 2010 21:39:49 +0000

Since you're the expert, is the current kernel fix adequate, or not? If not, what can be done to fix it?

I'm not the one claiming to be the security coding expert, but I *AM* now claiming that some of these experts are apparently an enormous pain to have to deal with.

> you decided to take it "on faith" that Andrea's patch was used by SuSE

I said that specifically *because* that was what PaXTeam claimed and *I* was giving him credit for probably being correct! I was attempting to be cordial on that point. And now you take umbrage, and try to hang me for it...

I'm done. You've successfully shouted down another inquisitor. Thanks for all your efforts with improving Linux security (sincerely; I can see you have enormous talent), but I don't need to put up with your distortions of my meaning, intent, and words.

An ancient kernel hole is closed

chad.netzer — Fri, 20 Aug 2010 21:13:26 +0000

Whatever. Give them credit for their work where it is due (absolutely). But people who hijack threads with twisted misrepresentations of what is being discussed are ruinous to the value of this site.

My "defense" of Linus against what seems an unwarranted accusation is justified since no one has adequately explained why the 2004 patch didn't get reworked into an acceptable solution that then got promoted upstream. It now seems less of a technical issue, and more of a communication issue, and I'm seeing *ample* evidence to suggest what kind of factors may have led to that unfortunate situation.

On a side note, to both 'cde' and 'avik', I appreciate your input. In particular 'cde', whom I took issue with stating this was a problem of "priority". This further convinces me it isn't a matter of priorities, but personalities, and "we" may indeed have been denied an earlier fix solely because of it. Thankfully, the right personalities belatedly addressed this particular issue.

An ancient kernel hole is closed

spender — Fri, 20 Aug 2010 21:12:33 +0000

Here's a question: before entering in a discussion with the PaX Team, did you bother to do any research of your own? Did you, for instance, read Gael Delalleau's 2005 presentation? Did you specifically read slide 24 and onward? Did you bother to read any of the news articles recently that had mentioned that SuSE has had the fix since SuSE Linux Enterprise 9 (released in 2004)? Had you bothered to create the following test application for instance and see how it happily accesses over the stack gap (using gcc 4.3.2 here but it applies to every other gcc version)?

int main(void)
{
char buf[4096];
char buf2[4096];

strcpy(buf2, "hello");

printf("%s\n", buf2);

return 0;
}

You'll notice the beginning of main() gets compiled by gcc to:
lea ecx, [esp+0x4]
and esp, 0xfffffff0
push dword ptr [ecx-0x4]
push ebp
mov ebp, esp
push ecx
sub esp, 0x2014 <--- look here
mov dword ptr [esp+0x8], 0x6 <--- and now here
mov dword ptr [esp+0x4], 0x80484f0

See, if you had done any research, you would have known about this behavior and known why then a single hardcoded guard page isn't acceptable in certain contexts for security. You'd know that Windows and MSVC don't have these problems. You would also have known about the additional hacks Linus added specifically to account for an incompatibility with an LVM app (after the stable kernels were already released and his buggy patch was pushed out without community review, causing oopses on some machines in addition).

From all of these reasons you would have known why the PaX Team objected to the patch itself and the way it was created and could have engaged in a reasonable discussion, yet with no knowledge and no intention of obtaining any on your own (you decided to take it "on faith" that Andrea's patch was used by SuSE) you chose to argue.

Why is it that people like you choose to engage in heated arguments with people who *have* done their research when it's evident that you've done absolutely none? How about taking responsibility for your own actions and behavior?

-Brad

An ancient kernel hole is closed

zakalwe2 — Fri, 20 Aug 2010 20:32:52 +0000

PaXTeam is a gentleman and a scholar. Every time I have had an issue with PaX on a new kernel release he extremely helpful and a fountain of knowledge. Your fanboy defence of linus was worthy of attack by someone who has worked tirelessly to improve the real security of linux and got nothing but grief for his efforts. It is only because of spender and the pax team that the upstream kernel developers stubborn, cavalier attitude towards security is being eroded and the real security of your systems being improved.

An ancient kernel hole is closed

chad.netzer — Fri, 20 Aug 2010 20:30:08 +0000

Check out their commenting on Joanna Rutkowska's blog posting (if you like watching these kind of train wrecks).

http://theinvisiblethings.blogspot.com/2010/08/skeletons-...

VM_GROWSDOWN

helge.bahmann — Fri, 20 Aug 2010 19:26:10 +0000

This is typically about 8MB and therefore <1% of the total address space (assuming 32-bit kernel). If your app cannot tolerate that, you are in worse trouble.

An ancient kernel hole is closed

sbishop — Fri, 20 Aug 2010 18:40:46 +0000

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.

Yeah, it's funny given the Latin meaning of "pax".

I remember when PaXTeam and spender first showed up here and we thought they were the same person. The difference seems to be that spender can be worth engaging. PaXTeam seems to be a symbolic link to /dev/vitriol.

An ancient kernel hole is closed

chad.netzer — Fri, 20 Aug 2010 17:47:10 +0000

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

[SNIP]

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

VM_GROWSDOWN

njs — Fri, 20 Aug 2010 17:05:35 +0000

For 32-bit apps, address space is not at all cheap.

An ancient kernel hole is closed

PaXTeam — Fri, 20 Aug 2010 11:56:22 +0000

> How irrelevant.

it'd be relevant if you hadn't carefully omitted some bits of my response ;). you see, those bugs could have been found and fixed before committing the patch had they been discussed publicly. there's some irony in that it was you in the first place who was asking about "the security community nagging LKML about this issue that whole time" and now you find it irrelevant that discussion of this long sought-after fix missed LKML.

> They touch completely different sets of files

so you admit that your claim of "Linus's patches, which *only* touch mm/memory.c" is flat out false.

> AA's patch was more intrusive.

how do you measure intrusiveness? but besides that, whether something is more or less intrusive is of secondary importance when it comes to correctness (and not to mention that ugly hack about lying about vma boundaries).

> "404 - Unknown commit object"

oops, a stray 'v' slipped into the url, here's the correct one: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .

> So you admit the patch shouldn't have been accepted.

not at all. what often happens is that a problem gets fixed and later refined, even simplified. just look at the evolution of rmap, there were quite a few rounds of complexity added only to be removed later. it also happens sometimes that a problem gets fixed on a specific arch only then gets generalized (and simplified) for all/most archs. the need for evolution is not a reason to prevent code from entering the tree.

> You just admitted that it was the wrong approach, since it touched arch files it didn't need to, etc.

Chad, i think you should stop commenting on issues you clearly have no idea about. 'approach' here means solving the heap/stack gap problem by either stopping stack growth at the automatic vma expansion level or detecting stack expansion attempts at the lower guard page access level. it's an implementation detail where you add the detection logic in either case and can of course always be discussed/refined/etc (something that didn't really happen for either approach).

> Which vendor or distro included AA's 2004 patch, since you now claim it is "the right approach"? If you've got a (working) link to a vendor commit, from a long time ago, you will begin to have a better argument.

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.

> You've previously claimed that [...]

How irrelevant. (tm)

seriously, do you understand the difference between being able to *recognize* a security issue in *existing* code and *writing* *new* kernel code to solve problems? by the look of it, you still don't quite get it.

> So, what have the security "experts" come up with that is better than Linus's solution, and why not 5 years ago when they discussed it? Where is the non-butt-ugly-hack fix that you advocate?

now that you (hopefully) understand what 'approach' means in this context, i believe you can answer these questions yourself.

VM_GROWSDOWN

helge.bahmann — Fri, 20 Aug 2010 10:35:15 +0000

Could anyone remind me why "VM_GROWSDOWN" (and the resulting bloody hack of a movable guard page) is actually needed anymore? Address space is cheap, afetr all.

Sure there may be apps that rely on the present specific address space layout, so I'd say define a new elf flag and just pre-allocate the stack address space with a proper static guard page instead of this mess...

An ancient kernel hole is closed

chad.netzer — Fri, 20 Aug 2010 09:50:37 +0000

> you mean the one that he had to fix like 3 times?

How irrelevant. I suppose you just give up after the first try? They touch completely different sets of files, which context allows you to understand is the point. AA's patch was more intrusive.

> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...

"404 - Unknown commit object"

>with due respect to Andrea's efforts, there was really no need to touch arch
>specific code

So you admit the patch shouldn't have been accepted.

> it's still the right idea and approach

You just admitted that it was the wrong approach, since it touched arch files it didn't need to, etc.

Which vendor or distro included AA's 2004 patch, since you now claim it is "the right approach"? If you've got a (working) link to a vendor commit, from a long time ago, you will begin to have a better argument.

> [a compelling case was presented] in 2004-2005 already

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

http://lwn.net/Articles/373896/

So, what have the security "experts" come up with that is better than Linus's solution, and why not 5 years ago when they discussed it? Where is the non-butt-ugly-hack fix that you advocate?

An ancient kernel hole is closed

PaXTeam — Fri, 20 Aug 2010 08:30:57 +0000

> And note how very different it is from Linus's patches

you mean the one that he had to fix like 3 times?

> which *only* touch mm/memory.c

right, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... (and let's not get started how bloody crap this whole 'solution' is, just look at the hacks like this commit introduces and high-five for not using an easily changeable define for the gap size)

> and none of the arch specific files.

with due respect to Andrea's efforts, there was really no need to touch arch specific code, one can get away with patching expand_downwards, get_unmapped_area and mprotect or so these days.

> So the issue is still, if AA had the right idea, but the wrong approach back in 2004

it's still the right idea and approach (the userland managed guard page brought up in the original discussion is easy to handle).

> Once a compelling case was presented,

that happened in 2004-2005 already (not saying people weren't aware of the problem many years before that though).

> Linus seems to have put effort into implementing an elegant fix

it's a butt-ugly hack he couldn't even get right the first time (where was the lkml discussion before committing it btw? oh right, there wasn't).

> so how does that mean *his* priorities are screwed up

5 years of ignoring the problem (not that it was only him) implies 'screwed up' in my book. certain big commercial companies get grilled for spending a fraction of that time on a security fix.

> Was the security community nagging LKML about this issue that whole time?

ask your security@kernel.org and/or vendor-sec contacts for their 2005 archives and you'll see the discussion take place then.

PS: there's some irony in mm/nommu.c still having an unused heap_stack_gap variable.

An ancient kernel hole is closed

drag — Fri, 20 Aug 2010 01:30:52 +0000

Well as long as your using decent open source video drivers then your X Server can run as just a regular application _right_now_, rather then some monster that needs to fiddle with bits on your PCI bus like is traditionally needed.

It's certainly and absolutely possible.

But it probably breaks most closed source drivers so development is going to continue to be painfully slow.

There are probably a lots of problems with it, like was mentioned above with input devices, but it's absolutely possible that at some time we can have a non-root-privileged X. But people do have it working in a more-or-less fashion.

An ancient kernel hole is closed

drag — Fri, 20 Aug 2010 01:15:56 +0000

Yes Yes. Spender tends to back up his arguments with facts, which is a win in my book.

Linux was never really designed with security in mind. It's priorities lay in practical uses and performance. It's the conscious application of effort and improvements that improve the security of Linux and not comparisons to Windows. :)

An ancient kernel hole is closed

cmccabe — Fri, 20 Aug 2010 00:11:10 +0000

> All the more reason for making the X server run as non-root.

OpenBSD uses privilege separation in its port of X.org.

I wonder if, with kernel modesetting, a totally non-root X.org will ever be possible. Or an selinux-sandboxed one, for that matter.

An ancient kernel hole is closed

nix — Thu, 19 Aug 2010 22:26:42 +0000

The lack of any way to revoke() other users of the input devices, I understand.

An ancient kernel hole is closed

chad.netzer — Thu, 19 Aug 2010 20:06:27 +0000

And note how very different it is from Linus's patches, which *only* touch mm/memory.c, and none of the arch specific files.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...

vs.

http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-09/7...

So the issue is still, if AA had the right idea, but the wrong approach back in 2004, then how could the proper discussion to address this have been started back then? Once a compelling case was presented, Linus seems to have put effort into implementing an elegant fix, so how does that mean *his* priorities are screwed up? 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).

An ancient kernel hole is closed

avik — Thu, 19 Aug 2010 19:27:01 +0000

A fix in fact was submitted in 2004.

An ancient kernel hole is closed

chad.netzer — Thu, 19 Aug 2010 18:41:29 +0000

From the article: "but the nearly two-month delay between the report and the fix is raising some eyebrows."

Then you: "Quite unbelievable that we had to wait 5+ years for this bug to be fixed-- kinda shows Linus' priorities"

You don't need to slander. This sense of entitlement saying that "we" had to "wait" 5+ years for a fix from Linus is bogus. It implies that he was sitting on his hands over this issue for 5 years, uninterested in fixing it. Instead, he and others were working their asses off to ensure that *your* crappy POS hardware device, etc. worked well with Linux, while trying to address any (and I think all) security issues that were reported in the meantime. Unless you claim that the issue was known to Linus for 5 years, I think you should ask how to better ensure security bug discoverers report more quickly to bug fixers, and lay off the BS.

Xorg flaw

iabervon — Thu, 19 Aug 2010 17:32:25 +0000

I think that there are actually three things the client has to do: get the server to allocate enough server-side, non-shared resources to use up most of the address space and force the remainder somewhere useful; get a shared memory segment so that the client will be able to change an area of the server's address space; and get the server to overflow the stack into the shared memory segment.

The shared memory aspect is not really a flaw to avoid; the flaws to be fixed on the userspace side are really that the server will go overboard allocating resources for clients, rather than applying some limits to protect itself, and that the server's stack can grow into the heap. At some point, the server should refuse to do what the clients are asking in order to protect itself from overloading (which is hard); the kernel should do better at preventing overloading from leading to unexpected aliasing (which they did). The MIT-SHM aspect just makes the exploit comprehensible.

I don't doubt that a sufficiently clever request could get the server to overflow the stack into the area where the response to the request will be written and write a chosen response into a spot that aliases a return address on the stack, causing the server to return to effectively calling system() on a chunk of an image provided by the client.

An ancient kernel hole is closed

nim-nim — Thu, 19 Aug 2010 17:00:01 +0000

Isn't xorg cross-platform?

So does this mean every OS but Linux has been protecting against this kind of abuse, or that the press only talks about the most visible OS?

recursion

tialaramex — Thu, 19 Aug 2010 16:33:29 +0000

AFAIU It is always possible to transform a recursive algorithm into an equivalent iterative one which stores intermediate state on the heap.

In some cases the recursive algorithm will be clearer, which makes maintenance easier (and reduces the chance of security relevant bugs). In some cases the iterative algorithm will be faster (particularly if your programming language or compiler suck)

An ancient kernel hole is closed

cde — Thu, 19 Aug 2010 16:19:25 +0000

Quite unbelievable that we had to wait 5+ years for this bug to be fixed -- kinda shows Linus' priorities in the developement of the kernel. Not that other competing operating systems do a better job.