1 |
On Wed, 20 Jul 2016 14:14:23 -0500 Austin English wrote: |
2 |
> On 07/20/2016 12:13 PM, NP-Hardass wrote: |
3 |
> > This is the first draft of a news item describing a packaging change for |
4 |
> > OpenAFS so that we no longer require the DEBUG_RODATA be turned off. |
5 |
> > Given the security implications of the previous setting of having |
6 |
> > CONFIG_DEBUG_RODATA=n, we thought it prudent to ensure that OpenAFS |
7 |
> > users get notice of the change in a manner that they are not likely to |
8 |
> > miss (unlike a message in a phase that can be missed/hidden/squelched). |
9 |
> > |
10 |
> > |
11 |
> > Title: OpenAFS no longer needs kernel option DEBUG_RODATA |
12 |
> > Author: NP-Hardass <NP-Hardass@g.o> |
13 |
> > Author: Andrew Savchenko <bircoph@g.o> |
14 |
> > Content-Type: text/plain |
15 |
> > Posted: 2016-07-23 |
16 |
> > Revision: 1 |
17 |
> > News-Item-Format: 1.0 |
18 |
> > Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2 |
19 |
> > Display-If-Keyword: amd64 |
20 |
> > Display-If-Keyword: ~amd64-linux |
21 |
> > Display-If-Keyword: ~sparc |
22 |
> > Display-If-Keyword: x86 |
23 |
> > Display-If-Keyword: ~x86-linux |
24 |
> > |
25 |
> > As a result of bug #127084 [1], it was determined that OpenAFS's kernel |
26 |
> > module required that the kernel's data structures be read-write |
27 |
> > (CONFIG_DEBUG_RODATA=n). Upon reviewing the latest version of OpenAFS |
28 |
> > with Linux kernels 3.4-4.4, it has been determined that this condition |
29 |
> > is no longer necessary to ensure that OpenAFS builds and loads into the |
30 |
> > kernel. |
31 |
> |
32 |
> The second sentence reads awkwardly to me. Was this recent discovery a |
33 |
> result of OpenAFS changes, or from a re-audit of the source? |
34 |
> |
35 |
> If it's the former, I'd use something like: |
36 |
> As of openafs-1.6.18.2, it is no longer necessary to disable |
37 |
> CONFIG_DEBUG_RODATA for the OpenAFS module to build and be loaded by the |
38 |
> kernel. |
39 |
> |
40 |
> If the ebuild doesn't block on kernels < 3.4, of course warn about that |
41 |
> as well. |
42 |
> |
43 |
> For the latter it is okay, but still a bit akwardly worded. |
44 |
|
45 |
This discovery is a result of ebuild audit in the first place. |
46 |
While discussing another issue of OpenAFS [1], we noticed user |
47 |
report that it works fine with GRSecurity CONFIG_PAX_KERNEXEC, |
48 |
which is more strict variant of vanilla's kernel |
49 |
CONFIG_DEBUG_RODATA. So natural question was: do we really need |
50 |
that ancient 10-years old limitation these days? |
51 |
|
52 |
Thanks to NP-Hardass hard testing we know that we don't need it and |
53 |
for quite a while, testing was limited to linux-3.4 due to |
54 |
manpower issues or technical limitations I suppose, so older |
55 |
versions are likely to work too, just not verified to do so. We |
56 |
don't know exactly when and where this issue was fixes aside from |
57 |
the fact that it was done a long time ago. |
58 |
|
59 |
It is likely to be a fix in the OpenAFS, but I can't find or grep |
60 |
anything relevant in its ChangeLog (though it is easy to miss |
61 |
message in 10 years long log). So as a precaution a wide range of |
62 |
kernels was tested. What the second sentence is trying to say is |
63 |
that we built and tested all kernels within 3.4 - 4.4 range and |
64 |
verified that it works fine. |
65 |
|
66 |
[1] https://bugs.gentoo.org/show_bug.cgi?id=586244 |
67 |
|
68 |
Best regards, |
69 |
Andrew Savchenko |