grsecurity forums

Well, unfortunately this time a new patch is required. Damn. I'll be waiting patiently

bring on grsecurity+pax for 2.6.15

I wonder if there are any planned release date, in the past new grsec versions were released almost the same day as the Linux kernel, what happened? Lack of time or motivation?

Regards.

Porting non-PaX features of grsecurity to new 2.6 kernels is generally not a problem, though since PaX is very dependent on low-level aspects of the kernel for all architectures it supports, it is simply not possible to port PaX to every kernel version when the VM system is being nearly completely rewritten in every "stable" release. The PaX team and I agree that their time is better spent on new features for PaX, rather than keeping up with every release of the mess that is Linux 2.6.

-Brad

would it possible to release a non-pax grsec patch for 2.6.15?
some people don't need pax.

regards,
//richard

Then why not support only these major versions of 2.6 Linux kernel? Many admins who uses 2.6 only use "big" releases. Even Torvalds himself said he is not supporting "small" Linux kernel versions.

Regards.

I don't understand. What are these "small" Linux versions? the .x.y style (ie 2.6.14.6)?

-Brad

the last digit, 2.6.15.1 denotes a crucial error which required immediate fixing

No, it denotes a packet of minor issues which has been fixed, they are minor enought to not require a big number, and they are usually not reviewed/made by Torvalds, so these minor versions rather seems to be kernel hackers sandbox than a stable version, it happened to me that some things I use were even broken in these, so I have abandoned using them. Anyway usually grsecurity patches well on these minor stuff, maybe with some rejectiosn in Makefile therefore I would suggest grsecurity developers to stay with major releases of Linux kernel, therefore work without rush.

Regards.

Version numbering

The version number of the Linux kernel currently consists of four numbers, following a recent change in the long-standing policy of a three-number versioning scheme. For illustration, let it be assumed that the version number is composed thus: A.B.C[.D] (e.g. 2.2.1, 2.4.13 or 2.6.12.3).

* The A number denotes the kernel version. It is changed least frequently, and only when major changes in the code and the concept of the kernel occur. It has been changed twice in the history of the kernel: In 1994 (version 1.0) and in 1996 (version 2.0).

* The B number denotes the major revision of the kernel. Even numbers indicate a stable release, i.e. one that is deemed fit for production use, such as 1.2, 2.4 or 2.6. Odd numbers are development releases, such as 1.1 or 2.5. They are for testing new features and drivers until they become sufficiently stable to be included in a stable release.

* The C number indicates the minor revision of the kernel. In the old three-number versioning scheme, this was changed when security patches, bugfixes, new features or drivers were implemented in the kernel. With the new policy, however, it is only changed when new drivers or features are introduced; minor fixes are handled by the D number.

* A D number first occurred when a grave error, which required immediate fixing, was encountered in 2.6.8's NFS code. However, there were not enough other changes to legitimize the release of a new minor revision (which would have been 2.6.9). So, 2.6.8.1 was released, with the only change being the fix of that error. With 2.6.11, this was adopted as the new official versioning policy. Bug-fixes and security patches are now managed by the fourth number, whereas bigger changes are only implemented in minor revision changes (the C number).

[edit]

straight from the wiki

And now? 2.6.15.4 is out and already 2.6.15.3 fix a critical bug ..

http://www.kernel.org/pub/linux/kernel/ ... g-2.6.15.3


Sure, it's nice that you work on new features for PaX, but it's necessary to update the kernel when a bug is found ..

Crasline wrote:And now? 2.6.15.4 is out and already 2.6.15.3 fix a critical bug ..

http://www.kernel.org/pub/linux/kernel/ ... g-2.6.15.3


Sure, it's nice that you work on new features for PaX, but it's necessary to update the kernel when a bug is found ..

When the changes are as minor as the one you link to, it should be possible to apply that change to a GR kernel without modifying any of the GR code (unless that particular function happens to have GRsecurity modifications in it, in which case you should review them before rearranging the function). You don't even need a new release from the GRsecurity team if there's no interaction between their changes and the official ones.

For a simple change like this one, here's how I'd suggest doing it:

Unpack three kernels:
tmp/2.6.15.2-linus
tmp/2.6.15.2-GRsec
tmp/2.6.15.3-linus

Then run:

Code: Select all

cd tmp && diff -Nur 2.6.15.[23]-linus > linus-2.6.15.2-to-2.6.15.3.patch
cd 2.6.15.2-GRsec && patch -p1 <../linus-2.6.15.2-to-2.6.15.3.patch && cd .. \
&& mv 2.6.15.2-GRsec 2.6.15.3-GRsec

If patch asks for help, or mentions fuzz, you may want to examine the changes in more detail (or have a programmer examine them if you aren't a programmer yourself). Otherwise you should be good to go. The expression above could be shortened a bit, but I like to have the patch file around for manual review. Once you're satisfied everything worked, you can delete the linus-*.patch that the above snippet generates.

Cant you just release only the grsec patch without pax for 2.6.15.x? I have waited it for about 4 weeks now...

Well, alot of people resigns from grsecurity because it recently not follows kernel releases...I like to have my kernels up to date too. :(

Regards.

yeah, it would certainly be nice to get some version for 2.6.15.x now or at least some idea when it might happen or just a remark it wont happen.