grsecurity 2.1.0 and kernel vulnerabilities [LWN.net]

grsecurity 2.1.0 and kernel vulnerabilities

Posted Jan 8, 2005 0:37 UTC (Sat) by mmarq (guest, #2332)
In reply to: grsecurity 2.1.0 and kernel vulnerabilities by havoc
Parent article: grsecurity 2.1.0 and kernel vulnerabilities

Oh c'mon!... you are being much more unfair to the authors of the article than they towards the development leadership of Linux kernel...

And the key word here, i belive, is "development" !!... Linux were always in a constant state of development. There never were a relly true 'stable version' out of the initial series of 'stable marked' kernels. But that is my opinion. Also, IMO, the best solution for these problems is to open another tree, after a new *wild* unstable serie is open...

...lets say a 'stable-final', where only bug fixing and security holes *should* be mended, and not as we have today where pretty major features changes are made on stable series...

...there shoudn't be any clash among a wild 'unstable' and a 'stable-final' flowing in simultaneos, since they are so different in purpouse.

And that is not asking for to much, i belive, since the it is in all the interest of the commercial party of Linux world, to have a 'Titanium' solid product,... and they have the resources to make it rock.

(Log in to post comments)

grsecurity 2.1.0 and kernel vulnerabilities

Posted Jan 8, 2005 18:41 UTC (Sat) by mmarq (guest, #2332) [Link]

Right!... when did it officially had SATA support ?... by 2.4.25 i guess, no ?

So 2.4 is a real evidence that a stable serie are just better continued versions of the unstable ones.

"IMHO a real "stable" kernel, will result in it lacking features..."

How is that ?... i mean, if 2.4.25 was at the point where there wasent any more features added, if efficiently decided it should had been 2.4.20 or 21, then afterwards the tree could became 2.4.(??) stable-final, that is, no more features besides bug features and security holes mended(dont know but guess more features were added after 2.4.25). So what's wrong with this view ?

I mean, you should have had a closed stable serie, and instead had a live *real* stable-final for only bug, security holes, and drivers, and at the same time have the normal 2.5 or 2.6(stable)... If people wanted more features they should had waited for 2.6, and had helped more in its development, instead of trying pushing it to 2.4 where they fealt more save.

So in conclusion i belive is obvious, that a *real* stable-final, 'IF WELL MANAGED', will help in the general development of Linux, because there is a sure place for things like the ones discussed in this article, and more skilled and inventive developers will be pushed to the next *real development* tree.

And the well managed part, intentionaly in bold(sorry), means that a stable-final(ex:2.4.50-FINAL) au contrary of the development tree, should be very very carefully planned, and should have only *ONE* final version number, after the necessary " pre " ;... and the process shoul only be repeated, after a lot of consideration(ex:2.4.55-FINAL) if results were not at all satisfactory.

I belive the community has enough room now, and Linux kernel enough features(well above average for servers, not quit enough for desktops) for it to go smoodly, without vacating any of the trees out of developers.

Cheers

Marques

grsecurity 2.1.0 and kernel vulnerabilities

Posted Jan 8, 2005 18:02 UTC (Sat) by bluefoxicy (guest, #25366) [Link]

I've been hoping they'd split 2.7 out and go with a 6-9 month release cycle. I think the 2.6 development model is great for the odd number branches; but we need a strict bugfix stable branch that's semi-recent (hence, not 2.4 for today).

http://woct-blog.blogspot.com/2005/01/finally-new-pax.html

In this blog entry I talk about the problems with the 2.6 development model being used for a 'stable' tree, opening up by discussing PaX finally catching up on all the VM changes like it shouldn't have to until 2.8.

I then took a page out of whatever book the Ubuntu guys are going for and structured a low-maintenance, long support cycle release mechanism around the 2.6 development model, simply by shifting the model to the odd number branches (2.7) and using the even branches for bugfixes only (security holes are bugs).

Driver backporting can be invasive, and is more work than just bugfixes. Drivers requiring invasive changes (Reiser4 hacked up the FS core a lot) would be forbidden for "Stable" in my design. Drivers that are just drop-in and modify a Makefile and Kconfig slightly are ok, but remember that somebody has to maintain that.

My goal is a release cycle that produces long-term support for stable kernels and timely releases, without stacking too many stable releases on maintainers at once or too much maintenance on a stable release. Maintaining a stable kernel should take about 10-15 minutes of your time per day in net. That means that an hour or two spent on your weekends to merge in a backported security patch is the target.

Unfortunately it seems that I didn't produce a model that would make everybody happy. At the very least I have no support; but that's ok, because I have no experience designing development models, so I'm probably way out of line.

Still, get the damn ball rolling and come up with something.