Gentoo Archives: gentoo-dev

From: R0b0t1 <r030t1@×××××.com>
To: gentoo-dev@l.g.o, blueness@g.o
Subject: Re: [gentoo-dev] Regarding the State of PaX in the tree
Date: Mon, 16 Apr 2018 01:25:19
Message-Id: CAAD4mYgT+Lo4uTAMHG2nZsA41ky=Gs9qw1WVrjdHL1E2BSb-+Q@mail.gmail.com
In Reply to: [gentoo-dev] Regarding the State of PaX in the tree by "Anthony G. Basile"
1 On Sun, Apr 15, 2018 at 7:04 PM, Anthony G. Basile <blueness@g.o> wrote:
2 > Hi everyone,
3 >
4 > Magnus (aka Zorry) and I have been talking about what to do with PaX in
5 > the Gentoo tree. A year ago, grsecurity.net upstream stopped providing
6 > open versions of their patches to the community and this basically
7 > brought an end to sys-kernel/hardened-sources. I waited a while before
8 > masking the package in the hope that upstream might reconsider. There
9 > were also some forks but I didn't have much confidence in them. I'm not
10 > sure that any of these forks have been able to keep up past
11 > meltdown/specter.
12 >
13 > It may be time to remove sys-kernel/hardened-sources completely from the
14 > tree. Removing the package is easy, but the issue is there is a lot of
15 > machinery in the tree that revolves around supporting a PaX kernel.
16 > This involves things like setting PaX flags on some executables either
17 > by touching the ELF program headers or the file's extended attributes,
18 > or applying custom patches.
19 >
20 > The question then is, do we remove all this code? As thing stands, its
21 > just lint that serves no current purpose, so removing it would clean
22 > things up. The disadvantage is it would be a pita to ever restore it if
23 > we ever wanted it back. While upstream doesn't provide their patch for
24 > free, some users/companies can purchase the grsecurity patches and still
25 > use a custom hardened-sources kernel with Gentoo. But since we haven't
26 > been able to test the pax markings/custom patches in about a year, its
27 > hard to say how useful that code might still be.
28 >
29 > I'm just emailing everyone to get advice.
30 >
31
32 I retain hope that compatible features will be added to the kernel.
33 Consequently, I would appreciate if the machinery can be left. If it
34 becomes a maintenance burden in the future I suspect that would be a
35 good time to remove it.
36
37 Cheers,
38 R0b0t1