| 1 |
2017-04-29 19:04 GMT+02:00 Luis Ressel <aranea@×××××.de>: |
| 2 |
> On Sat, 29 Apr 2017 17:56:10 +0200 |
| 3 |
> Daniel Cegiełka <daniel.cegielka@×××××.com> wrote: |
| 4 |
> |
| 5 |
>> By the way, I don't know what the Gentoo Hardened or Alpine Linux |
| 6 |
>> have done wrong, that now are left out in the cold. |
| 7 |
> |
| 8 |
> That's the part I don't get either. Since the only possible motivation |
| 9 |
> I can think of for this move is to generate more income, they could've |
| 10 |
> at least tried asking the community for donations first. |
| 11 |
|
| 12 |
It's more complex: |
| 13 |
|
| 14 |
https://www.theregister.co.uk/2015/08/27/grsecurity/ |
| 15 |
|
| 16 |
I don't judge them. I'm interested in the future of projects that were |
| 17 |
heavily dependent on PaX (Gentoo Hardened, Alpine Linux). |
| 18 |
|
| 19 |
> Now, I suppose someone is going to answer "If you'd be willing do |
| 20 |
> regularily donate to them, you might as well get a subscription", but I |
| 21 |
> fear this might have some serious drawbacks. In the past years, |
| 22 |
> the Gentoo Hardened devs have invested quite some work to make sure |
| 23 |
> most applications in the tree work on grsec/PaX-enabled kernels without |
| 24 |
> too much fallout. But now, there's suddently a lot less motivation to |
| 25 |
> keep up this work. |
| 26 |
|
| 27 |
Ned Lud (or Solar, but != Designer) has put a lot of work into the |
| 28 |
launch of Gentoo Hardened and, of course, the popularization of PaX. |
| 29 |
Old times.. :) |
| 30 |
|
| 31 |
|
| 32 |
>> Instead of complaining, we have to decide what to do next. In my |
| 33 |
>> opinion, it is critical to maintain support for PaX* for future |
| 34 |
>> kernels. It will not be easy, so I'm right away saying that Gentoo |
| 35 |
>> Hardened, Alpine Linux etc. should join forces in realizing this |
| 36 |
>> project. I think there will be more people who will be interested |
| 37 |
>> in... |
| 38 |
> |
| 39 |
> It might be hard to come up with the manpower needed to maintain such a |
| 40 |
> large kernel patch. Assuming upstream stand by their decision in |
| 41 |
> the long run, I think the only reasonable long-term approach would be to |
| 42 |
> try mainlining as much as possible and forget about the rest. And as |
| 43 |
> Brad and PaX Team can surely tell us, that'd be a gargantuan task if it |
| 44 |
> is at all possible. |
| 45 |
|
| 46 |
Patch weight is not the problem.. KSPP is. They copy (raw copy.. I |
| 47 |
hope) code from PaX and bring it to the kernel: |
| 48 |
|
| 49 |
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c054ee3bbf69ebcabb1f3218b7faf4b1b37a8eb6 |
| 50 |
|
| 51 |
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f5509cc18daa7f82bcc553be70df2117c8eedc16 |
| 52 |
|
| 53 |
This means that there will be conflicts in the future. I don't claim |
| 54 |
that maintaining PaX support will be easy, but it's possible to do so. |
| 55 |
|
| 56 |
Daniel |
Archives