On Wed, 20 Jul 2016 14:14:23 -0500 Austin English wrote: > On 07/20/2016 12:13 PM, NP-Hardass wrote: > > This is the first draft of a news item describing a packaging change for > > OpenAFS so that we no longer require the DEBUG_RODATA be turned off. > > Given the security implications of the previous setting of having > > CONFIG_DEBUG_RODATA=n, we thought it prudent to ensure that OpenAFS > > users get notice of the change in a manner that they are not likely to > > miss (unlike a message in a phase that can be missed/hidden/squelched). > > > > > > Title: OpenAFS no longer needs kernel option DEBUG_RODATA > > Author: NP-Hardass <np-hard...@gentoo.org> > > Author: Andrew Savchenko <birc...@gentoo.org> > > Content-Type: text/plain > > Posted: 2016-07-23 > > Revision: 1 > > News-Item-Format: 1.0 > > Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2 > > Display-If-Keyword: amd64 > > Display-If-Keyword: ~amd64-linux > > Display-If-Keyword: ~sparc > > Display-If-Keyword: x86 > > Display-If-Keyword: ~x86-linux > > > > As a result of bug #127084 [1], it was determined that OpenAFS's kernel > > module required that the kernel's data structures be read-write > > (CONFIG_DEBUG_RODATA=n). Upon reviewing the latest version of OpenAFS > > with Linux kernels 3.4-4.4, it has been determined that this condition > > is no longer necessary to ensure that OpenAFS builds and loads into the > > kernel. > > The second sentence reads awkwardly to me. Was this recent discovery a > result of OpenAFS changes, or from a re-audit of the source? > > If it's the former, I'd use something like: > As of openafs-1.6.18.2, it is no longer necessary to disable > CONFIG_DEBUG_RODATA for the OpenAFS module to build and be loaded by the > kernel. > > If the ebuild doesn't block on kernels < 3.4, of course warn about that > as well. > > For the latter it is okay, but still a bit akwardly worded.
This discovery is a result of ebuild audit in the first place. While discussing another issue of OpenAFS [1], we noticed user report that it works fine with GRSecurity CONFIG_PAX_KERNEXEC, which is more strict variant of vanilla's kernel CONFIG_DEBUG_RODATA. So natural question was: do we really need that ancient 10-years old limitation these days? Thanks to NP-Hardass hard testing we know that we don't need it and for quite a while, testing was limited to linux-3.4 due to manpower issues or technical limitations I suppose, so older versions are likely to work too, just not verified to do so. We don't know exactly when and where this issue was fixes aside from the fact that it was done a long time ago. It is likely to be a fix in the OpenAFS, but I can't find or grep anything relevant in its ChangeLog (though it is easy to miss message in 10 years long log). So as a precaution a wide range of kernels was tested. What the second sentence is trying to say is that we built and tested all kernels within 3.4 - 4.4 range and verified that it works fine. [1] https://bugs.gentoo.org/show_bug.cgi?id=586244 Best regards, Andrew Savchenko
pgpHosUJL80Uo.pgp
Description: PGP signature
