Created attachment 396552 [details] emerge --info All 3 versions of openafs-kernel currently available in portage (1.6.2-r1, 1.6.5-r1, ~1.6.5-r2) fail to emerge on hardened kernel 3.2.65-r2 with the error message: /var/tmp/portage/net-fs/openafs-kernel-1.6.5-r2/work/openafs-1.6.5/src/libafs/MODLOAD-3.2.65-hardened-r2-MP/osi_misc.c:120:2: error: invalid initializer afs_linux_path_t p = { mnt, dp }; ^ This also affects openafs since it depends on openafs-kernel. Steps to Reproduce: 1. Update kernel to latest available on hardened (3.2.65-r2) 2. Attempt to install net-fs/openafs (emerge net-fs/openafs)
Created attachment 396554 [details] build.log
Please test with 1.6.11 version.
(In reply to Andrew Savchenko from comment #2) > Please test with 1.6.11 version. 3.2.65-hardened-r2, openafs-kernel-1.6.11 make[5]: Leaving directory '/usr/src/linux-3.2.68-hardened' Error: Undefined symbols in modules Makefile.afs:241: recipe for target 'libafs.ko' failed make[4]: *** [libafs.ko] Error 1 make[4]: Leaving directory '/var/tmp/portage/net-fs/openafs-kernel-1.6.11/work/openafs-1.6.11/src/libafs/MODLOAD-3.2.68-hardened-MP' Makefile:138: recipe for target 'linux_compdirs' failed make[3]: *** [linux_compdirs] Error 2 make[3]: Leaving directory '/var/tmp/portage/net-fs/openafs-kernel-1.6.11/work/openafs-1.6.11/src/libafs' Makefile:483: recipe for target 'libafs' failed make[2]: *** [libafs] Error 2 make[2]: Leaving directory '/var/tmp/portage/net-fs/openafs-kernel-1.6.11/work/openafs-1.6.11' Makefile:692: recipe for target 'build' failed make[1]: *** [build] Error 2 make[1]: Leaving directory '/var/tmp/portage/net-fs/openafs-kernel-1.6.11/work/openafs-1.6.11' Makefile:42: recipe for target 'only_libafs' failed make: *** [only_libafs] Error 2 The error looks like http://gerrit.openafs.org/#change,8981
Created attachment 400548 [details] build.log 3.2.65-r2 with 1.6.11
Have openafs-kernel ever worked for you on a hardened kernel? I really doubt it will, because kernel modules requires "Write protect kernel read-only data structures" (CONFIG_DEBUG_RODATA) to be *disabled*. And it should be enabled on hardened systems.
It hasn't worked *yet*, no. The package wasn't masked so I assumed it should work ;) I can confirm that module compilation at least requires GRKERNSEC_RANDSTRUCT to be off. I've managed to emerge 1.6.11 with the attached patch. http://gerrit.openafs.org/#change,8981 introduces a forced failure when there are module symbol mismatches during compilation, the patch reverts that change.
Created attachment 400562 [details] Fix emerge with undefined symbols
Reverting this patch makes no good: undefined symbols in kernel module may hamper behaviour up to kernel panic. The proper fix will be to find these symbols and deal with them. Have you tested that openafs-kernel not only compiles, but works properly? You should be able to start openafs-client and copy some data from some node on mounted /afs partition.
(In reply to Kenan Avdic from comment #3) > The error looks like http://gerrit.openafs.org/#change,8981 This error message is the result of the patch that you reference. Prior to that, it failed silently, or completed and then caused issues when using the module. Regarding support, I've just spoken to a developer of OpenAFS who stated that that "hardened sources require that a number of data structures be initialized by C99 field names instead of explicit structure layouts. [...] Not all OpenAFS platforms support C99. [...] Supporting C99 would require dropping support for platforms or tons of ifdefs." Thus, upstream doesn't support hardened sources and it is unlikely that they will do so anytime soon..
@hardened, should we mask net-fs/openafs-kernel on hardened profiles?
(In reply to Andrew Savchenko from comment #10) > @hardened, should we mask net-fs/openafs-kernel on hardened profiles? Also worth looking into, because it's on my list of things to do, whether net-fs/openafs works with the in-kernel CONFIG_AFS_FS. If yes, I agree with that assertion, and make the client depend on the config or openafs-kernel. If that doesn't pan out, I would say we should mask both openafs{,-kernel} on hardened.
(In reply to NP-Hardass from comment #11) > (In reply to Andrew Savchenko from comment #10) > > @hardened, should we mask net-fs/openafs-kernel on hardened profiles? > > Also worth looking into, because it's on my list of things to do, whether > net-fs/openafs works with the in-kernel CONFIG_AFS_FS. If yes, I agree with > that assertion, and make the client depend on the config or openafs-kernel. > If that doesn't pan out, I would say we should mask both openafs{,-kernel} > on hardened. Scratch that. Looks like the in-kernel AFS is a server and client.
(In reply to NP-Hardass from comment #11) > Also worth looking into, because it's on my list of things to do, whether > net-fs/openafs works with the in-kernel CONFIG_AFS_FS. Ah, that is a common delusion. CONFIG_AFS_FS is completely independent implementation, sufficient on its own to mount /afs. See Documentation/filesystem/afs.txt in kernel src directory. That is: the only utility needed to mount /afs is mount. Of course, it is limited in functionality compared to openafs and is a bit harder to use. > If that doesn't pan out, I would say we should mask both openafs{,-kernel} > on hardened. openafs can be used without openafs-kernel if someone is interested in the server only (see bug 239369).
(In reply to Andrew Savchenko from comment #8) > Reverting this patch makes no good: undefined symbols in kernel module may > hamper behaviour up to kernel panic. The proper fix will be to find these > symbols and deal with them. > You're right, it doesn't work even as a workaround. The module built is unusable.
net-fs/openafs-kernel and net-fs/openafs[modules] are now masked on hardened.
Since the hardened-sources are now masked and unmaintained, could it be possible to lift this mask (or at least move it to the ebuild itself?).
