Arch Linux

I don't think there's much I can do about this. I could build two sets of plugins but you would need to switch between them just as you have to do with the multilib toolchain.

I added documentation to the wiki:

https://wiki.archlinux.org/index.php/Grsecurity#Out-of-tree_module_compilation_failure

I'm open to suggestions on a better way to deal with this, but I'm going to close to bug for now because I don't think there's any way to improve it.

1. what's gcc -v say for your various gcc versions? i'm asking it because it's possible to relax the default (strict) gcc version check to an extent.

2. where do you install gcc plugins? gcc can load plugins without a full path specification if they're installed in the proper plugins dir which would allow compiling/installing multiple plugin instances at once. i'm open to changes in the kernel-side plugin build system if you can figure out the rest ;).

PS: CC me next time on PaX related issues please.

There's a gcc package with --disable-multilib and a gcc-multilib package without it. Both of them have the same path for -print-file-name=plugin.

gcc:

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-isl-version-check --disable-cloog-version-check --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 (GCC)

gcc-multilib:

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-4.9.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 (GCC)

> PS: CC me next time on PaX related issues please.

I'll make sure to do that.

Hi All,

I dont have multilib repo enable in my pacman.conf. still after updating gcc and glibc I greeted with same error.

[savio@savio-arch ~]$ pacin multilib-devel
error: target not found: multilib-devel
[savio@savio-arch ~]$ pacin multilib-devel
error: target not found: multilib-devel
[savio@savio-arch ~]$ pacin gcc-multilib
[sudo] password for savio:
error: target not found: gcc-multilib



Below is make.log error for dkms install

[savio@savio-arch ~]$ cat /var/lib/dkms/vboxhost/4.3.20/build/make.log
DKMS make.log for vboxhost-4.3.20 for kernel 3.18.6.201502062100-1-grsec (x86_64)
Mon Feb 9 21:24:41 IST 2015
make: Entering directory '/usr/lib/modules/3.18.6.201502062100-1-grsec/build'
LD /var/lib/dkms/vboxhost/4.3.20/build/built-in.o
LD /var/lib/dkms/vboxhost/4.3.20/build/vboxdrv/built-in.o
CC [M] /var/lib/dkms/vboxhost/4.3.20/build/vboxdrv/linux/SUPDrv-linux.o
cc1: error: incompatible gcc/plugin versions
cc1: error: fail to initialize plugin ./tools/gcc/size_overflow_plugin/size_overflow_plugin.so
cc1: error: incompatible gcc/plugin versions
cc1: error: fail to initialize plugin ./tools/gcc/stackleak_plugin.so
cc1: error: incompatible gcc/plugin versions
cc1: error: fail to initialize plugin ./tools/gcc/colorize_plugin.so
cc1: error: incompatible gcc/plugin versions
cc1: error: fail to initialize plugin ./tools/gcc/structleak_plugin.so
scripts/Makefile.build:257: recipe for target '/var/lib/dkms/vboxhost/4.3.20/build/vboxdrv/linux/SUPDrv-linux.o' failed
make[2]: *** [/var/lib/dkms/vboxhost/4.3.20/build/vboxdrv/linux/SUPDrv-linux.o] Error 1
scripts/Makefile.build:402: recipe for target '/var/lib/dkms/vboxhost/4.3.20/build/vboxdrv' failed
make[1]: *** [/var/lib/dkms/vboxhost/4.3.20/build/vboxdrv] Error 2
Makefile:1459: recipe for target '_module_/var/lib/dkms/vboxhost/4.3.20/build' failed
make: *** [_module_/var/lib/dkms/vboxhost/4.3.20/build] Error 2
make: Leaving directory '/usr/lib/modules/3.18.6.201502062100-1-grsec/build'


My grsecurity kernel is compiled from abs with few option disable to get VirtualBox working ( I'll be moving towards qemu/kvm :)). Do I need to compile my linux-grsec everytime there is gcc update.

> Do I need to compile my linux-grsec everytime there is gcc update.

If you need to build out-of-tree modules for it, yes.

Aside from compiling time, is there any reason not to rebuild linux-grsec in community after each gcc update?

I'm not sure if I'm following the reasoning behind not updating it.

There are very frequent grsecurity updates so the problem solves itself within a few days. I can't make everyone happy because there's often a different gcc version in [testing].

Spending time compiling it is time I can't spend compiling *other* things, so it blocks me from doing stuff like actual work.

This issue is about gcc and gcc-multilib being treated as separate compilers though. They might have a compatible ABI so the PaX script could ignore that configuration difference. I'm not sure, haven't had much time to look at this.

I think it's fair to skip complaints that arise from [testing].

Isn't this what pkgbuild.com is for? Unless you're referring to the time it takes to test it, and not the compiling time.

I can add a warning in post_install/post_upgrade if the installed gcc package doesn't match the kernel, and maybe put a optdepends for gcc=x.x.x-x? Think that's a good or bad idea?

I don't like the idea of building packages on a server I don't control and then downloading + signing them with my key. I use pkgbuild.com for testing various things but not for my official packages.

It's not possible to make an accurate optdepends entry and it won't take into account the fact that gcc-multilib provides gcc.

A post-install/upgrade message won't work because the problem is that gcc is upgraded after linux-grsec.

It might be worth considering trying to give this package to someone else to build who has more processing power to spare.

I feel there needs to be some notification to the user that installing two packages from [community] will break each other.

Look at how frequently I already update it:

https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/linux-grsec

A condition of grsecurity being the official repositories was that it wasn't going to put a burden on other people, meaning it's not going to be coordinated with upgrades of the virtualbox module package or gcc. There will always be a window where it won't be possible to build modules without downgrading gcc or rebuilding it with the new gcc.

This issue was just about gcc vs. gcc-multilib with the same version. Totally different gcc versions is a separate issue without a full solution as they really do change the ABI frequently.

I think, considering the scope of archlinux, that we shouldn't push too much responsibility on the maintainer and let the users deal with the few corner cases of [multilib] themself. Overcomplicating this by coming up with elaborate schemes of optdeps and pushing maintainership around isn't worth the trouble. If one has the skill and knowledge to set up and maintain a grsec/pax system then recompiling a kernel and and a few out-of-tree modules shouldn't be too much to ask for.

The multilib issue can probably be worked around, it's the GCC upgrade issue that's not solvable. The best I could do is rebuilding it when the new gcc is moved out of [testing] (but it's not going to be coordinated with the gcc maintainer, too much trouble) but I don't really see the convenience that would offer users as important enough to be worth doing. Few people use out-of-tree modules and those that do can learn that they need to either downgrade GCC or rebuild the package (it's not like you have to do anything beyond running makepkg -is).

There are coordinated rebuilds for things like library upgrades, but grsecurity is a bit of a special case: nothing else needs to be rebuilt on normal GCC upgrades (the C++ ABI bump will be fun, but Clang is blocking that). There's also the fact that I promised to handle everything myself. It's also expected that the GCC plugins won't work with a newly released GCC for a while, so there's sometimes nothing that can be done about it: you have to install one of the packages providing a specific gcc version to build it.

I just ended up building the out-of-tree modules in a chroot using base-devel. This is faster than to rebuild the kernel on the host using multilib-devel. The only downside is the waste of a few hundred megabytes of diskspace but since i use the chroot for other AUR packages anyway it doesn't really matter.

@Danial: How about locking linux-grsec to the version of gcc that it was built with?

_gcc_build=$(pacman -Q gcc || pacman -Q gcc-multilib | sed 's/ /=/')
depends=("${_gcc_build}")

It doesn't have a runtime dependency on gcc though, only the niche use case of building out-of-tree modules does. The only supported one in the repositories for use with linux-grsec is that VirtualBox dkms package and AFAIK VirtualBox will be half broken without disabling some PaX features anyway.

Isn't dkms somewhat popular?

~ > yaourt -Ssq dkms | wc -l
70

66 of those are unsupported user packages (+ one is dkms itself) and many of them aren't going to work with grsecurity without patches or rebuilding it with features disabled anyway.

This bug report can probably be closed then.

I personally disagree that the "problem solves itself within a few days" is an acceptable solution for a rolling release distribution. This package isn't ready for [community], it should be moved back to [community-testing] until it stops breaking other [community] packages.

This bug report is only about the gcc vs. gcc-multilib incompatibility which can probably be solved, although it's a very low priority issue for me. I build packages in clean containers so even though I have gcc-multilib as my main compiler, so it isn't involved in anything to do with grsecurity.

IMO, there's really nothing I can do about the fact that new GCC versions are a problem. It can take a relatively long time for the GCC plugins to adapt to the API changes so a lot of it is out of our hands completely. The distribution isn't going to hold back moving to new GCC versions for the sake of the linux-grsec package and I don't see another 'solution'.

I think it's reasonable to expect the audience targeted by Arch to cope with this if they want to build out-of-tree modules. The Red Hat solution would be turning on kernel module signing...

i.e. build stuff with 'extra-x86_64-build -- -I old_gcc_package.pkg.tar.xz`