Re: [Devil-linux-develop] PAX support for newer kernels

[Bruce S. <bw...@re...>]

Is it worth asking the question on the list (about what it means for grsec)?

Or shall we just dump grsec now?  :-)

 - BS


>  not sure if you guys are following the grsecurity mailing list, but it
> seems PAX may soon not be adapted for new kernels anymore.
>  I'm not sure what the game plan is going to be from our side if this really
> happens. Brad did not mention what this would mean for grsecurity.
>
>  --
>
>  Regards
>   Heiko Zuerker
>   http://www.devil-linux.org
>
>
>  ----------------------------------------------------------------
>  This message was sent using IMP, the Internet Messaging Program.
>
>
>
> ---------- Forwarded message ----------
> From: pag...@fr...
> To: grs...@gr...
> Date: Wed, 07 May 2008 03:27:43 +0200
> Subject: Re: [grsec] grsecurity 2.1.11 released for Linux 2.4.36.2/2.6.24.4
> On 14 Apr 2008 at 21:07, Brad Spengler wrote:
>
>  > It is not clear if the PaX Team will be able to continue supporting
>  > future versions of the 2.6 kernels, given their rapid rate of release
>  > and the incredible amount of work that goes into porting such a
>  > low-level enhancement to the kernel (especially now in view of the
>  > reworking of the i386/x86-64 trees). It may be necessary that grsecurity
>  > instead track the Ubuntu LTS kernel so that users can have a stable
>  > kernel with up-to-date security fixes. I will update this page when a
>  > final decision has been reached.
>  >
>  > In the meantime, please email pag...@fr... and let him know how
>  > much you appreciate the hard work he has put in for the past 8 years.
>  > The accomplishments of the PaX Team have extended far beyond just Linux,
>  > and have today found their way into all mainstream operating systems.
>
>  now that i released a new test patch for 2.6.25.1, i'd like to address
>  the above.
>
>  first of all, thank you all who emailed me during this time, i hope
>  you'll forgive me for not responding to everyone individually, it'd
>  take too much time and repetition, so i'd rather answer here. if
>  there're questions left unanswered, just ask again (preferably in
>  public).
>
>  as spender said, there're several factors that make the continued
>  maintenance of PaX harder than necessary or maybe even unfeasible
>  given the circumstances.
>
>  for me the most important one is my free time i can spend on this
>  project, which has always been a delicate balance between family
>  and friends and other things that needed my attention. as long as
>  this time was enough to cover the necessary work needed for a forward
>  port, i did the work.
>
>  things have changed on both fronts though in that both my time i
>  can spend on this will soon decrease and the effort needed has
>  increased quite a lot as well with the inevitable consequence that
>  the development (or let's just stick to maintenance) of PaX have
>  slowed to a crawl. so lest things change for the better, future
>  releases may not happen at all or rather irregularly.
>
>  many of you asked how things can change for the better. given the
>  above, there're a few ways but frankly, i don't think any of it is
>  realistic.
>
>  one way is to increase the time spent on PaX. this can come from
>  either me or someone else. for me it's pretty much not possible
>  because if there's anything i want to spend less and less my time
>  on then it's everything computer security related. it was fun and
>  interesting at the turn of the millennium, but not anymore. so no
>  amount of funding or moral support will help here i'm afraid. on
>  the other hand the door is open for other adventurous souls to take
>  over, although i doubt anyone will show up. note that helping with
>  a few chunks or trivial rejects is of little help to me since, well,
>  i can do that easily too. the really big work is always related to
>  core changes done in PaX and porting those requires very deep
>  understanding of both the kernel and PaX (and a lot of time to debug
>  the inevitable bugs).
>
>  the other way is to decrease the effort needed for a forward port.
>  this in turn would require a change in the current linux development
>  model which is not going to happen anytime soon. one could also track
>  the vanilla tree more often/closely, but then we're back at the free
>  time problem (most of which would be a complete waste since as end
>  users you're really interested in the patch that works with a release,
>  not arbitrary git snapshots).
>
>  so there you have it, i know it looks rather bleak, but c'est la vie.
>
>  cheers,
>   PaX Team