Fix build failures on PaX/GRSecurity patched kernels #767

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
Member

ryao commented Jun 1, 2012

Gentoo Hardened kernels include the PaX/GRSecurity patches. They use a
dialect of C that relies on a GCC plugin. In particular, struct
file_operations has been marked do_const in the PaX/GRSecurity dialect,
which causes GCC to consider all instances of it as const. This caused
failures in the autotools checks and the ZFS source code.

To address this, we amend the autotools checks to utilize struct
file_operations_no_const and modify the ZFS source code to use memcpy(),
which avoids issues in the PaX/GRSecurity dialect.

Signed-off-by: Richard Yao ryao@cs.stonybrook.edu

Member

ryao commented Jun 6, 2012

The use of memcpy() is not the right thing to do here. I am closing this until I have reworked this to avoid memcpy().

ryao closed this Jun 6, 2012

ryao reopened this Jun 17, 2012

Member

ryao commented Jun 17, 2012

I have reworked the patch. This closes #484.

ryao referenced this pull request Jun 17, 2012

Closed

building on gentoo hardened #484

Member

ryao commented Jun 17, 2012

0.6.0-rc9 is now in Gentoo. This patch is applied as part of that.

@ryao ryao Fix build failures on PaX/GRSecurity patched kernels
Gentoo Hardened kernels include the PaX/GRSecurity patches. They use a
dialect of C that relies on a GCC plugin. In particular, struct
file_operations has been marked do_const in the PaX/GRSecurity dialect,
which causes GCC to consider all instances of it as const. This caused
failures in the autotools checks and the ZFS source code.

To address this, we modify the autotools checks to take into account
differences between the PaX C dialect and the regular C dialect. We also
modify struct zfs_acl's z_ops member to be a pointer to a function
pointer table. Lastly, we modify zpl_put_link() to address a PaX change
to the function prototype of nd_get_link().  This avoids compiler errors
in the PaX/GRSecurity dialect.

Note that the change in zpl_put_link() causes a warning that becomes a
build failure when debugging is enabled. Fixing that warning requires
ryao/spl@5ca50ef.

Closes zfsonlinux/zfs#484

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
89393dd

It occurs to me that there's probably a cleaner more supportable way to do this. Instead of adding all of these almost duplicate test cases for PAX kernels, we could add a single test early on to detect if your using a PAX kernel. If you are then this result could be used in the subsequent API specific tests. For example something like this:

        ...
        (*fallocate) (struct file *, int, loff_t, loff_t) = NULL;

#if defined(HAVE_PAX_KERNEL)
        struct file_operations_no_const fops __attribute__ ((unused)) = {
#else
        struct file_operations fops __attribute__ ((unused)) = {
#endif /* HAVE_PAX_KERNEL */
        ...

That upside of course is not having to maintain multiple copies of the same test.

Owner

behlendorf commented Jul 4, 2012

Initial testing suggests the patch doesn't introduce any new build issues on other platforms so we should be able to get it in with a little more testing.

Member

ryao commented Jul 17, 2012

@behlendorf I think that the duplicate test cases are necessary. Determining what constitutes a PaX kernel is an issue. Maintainers of kernel patch sets might choose to port a subset of the PaX patches, which would pose a problem for PaX kernel detection. Duplicating test cases avoids this and it only penalizes patched systems in terms of the time it takes for the ./configure script to run.

Owner

behlendorf commented Jul 17, 2012

Alright, I've merged this is to master as 0a6b03d

behlendorf closed this Jul 17, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment