# Kernel build errors when moving to hardened-sources

## archnaid

Hello!

I am trying to set up a VPS (Linode). After some stumbling, I've accomplished these things:

 Deploy an image and switch from the Linode-supplied kernel to the Gentoo kernel (is dist 2017-01 really using 4.4?)

 Run through the initial emerge @world updates; upgrade the kernel to whatever was latest in stable (4.9.something), update grub to boot it by default, etc... This ran into the eudev CONFIG_SYSFS_DEPRECATED should not be set but it is warning, which I found others refer to. Fixed that config, rebuilt and reinstalled the 4.9 kernel.

 Select the hardened profile, rebuild GCC, select the hardened gcc profile, rebuild the toolchain

 Rebuild the whole system

I completed all of the upgrades first because my first attempts all failed (seemed to be due to a perl dependency issue of some kind). Everything else is all as per the hardened documentation, as I understand it. Last step is to emerge hardened-sources, build the kernel, and install. And that is where I am having issues.

After 

```
emerge hardened-sources
```

 I copied the config over from 4.9, and went though the updates. I did this manually the first time via 

```
make silentoldconfig
```

 After having issues, I tried a 

```
make distclean
```

 Then re-copied the old config in; and to use the defaults for the new items, in case I broke something with my custom selections, I tried a 

```
make olddefconfig
```

 But in each case, running make yields hundred (thousands?) of errors across many modules, all like 

```
WARNING: crypto/built-in.o(.data+0x5ea0): Section mismatch in reference from the variable key_type_asymmetric to the function .text:asymmetric_key_match_free()
```

. To be very clear, this is happening for many many things, not just crypto.

I'm at a loss of what to do here. I've done a fair amount of googling, but it generally points in three directions:

 CONFIG_BUILD_DOCSRC being enabled can cause this problem. But I've ensured it is disabled via 

```
make menuconfig
```

 Just build with 

```
make CONFIG_DEBUG_SECTION_MISMATCH=y
```

 and try it. I did try to do the build this way just to see what happened or if any more interesting error information arose, but it did not. I do not want to try to boot it because this is a remote server and recovery from failed boot could get interesting (I really don't want to wipe and spend the next 24h emerging everything to get back to this point).

 There's some config issue, good luck. Maybe there are some debug flags which could provide more info, but I haven't found much.

So, any advice as to next step? And (dare I ask it), is gentoo-hardened really being maintained anymore? I ask because the hardened-sources is 4.8 series, and there's a thread down a little way with someone posting what appears to be unofficial 4.9 patches. [edit] read a few more threads on hardened, sad news that grsecurity is shutting out the community.

Thanks in advance! Let me know if anything is not clear.

----------

## mv

Due to the very recent changes in grsecurity distribution policy, one can assume that hardened-sources is no longer maintained.

Probably the best you can do is to switch to standard sources (gentoo-sources or vanilla-sources) ASAP, to follow the recommendations of KSPP, and to hope/support mainlining pax into the kernel.

----------

## archnaid

Thanks,

One update, I did another make distclean, copied in the config from 4.4.39 instead, and attempted make olddefconfig make, but same result.

And... I'm trying to decide now what to do with this project. Getting security patches is of course important, but it would be nice to have the other protections until something like KSPP is mature enough and mainlined into Gentoo etc. Tough spot   :Confused: 

----------

## h4rdened

Before rushing to a vanilla kernel, as the benefit of the last grsecurity patch public will provide you (and for the next 3 years at least) the highest security, you can give a try to :

https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec

More information about "How to use it" here -> https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec

KAPP is a good project but keep in mind for the moment that will not provide you the security of grsec patch at all

----------

## NeddySeagoon

h4rdened,

I'm running 

```
$ uname -a

Linux grytpype-thynne_KVM 4.9.20-hardened #2 SMP Mon Apr 3 21:05:32 2017 x86_64 Intel Xeon E312xx (Sandy Bridge) GenuineIntel GNU/Linux
```

and 

```
$ eix hardened-sources

* sys-kernel/hardened-sources

     Available versions:  

     (4.4.8-r1) 4.4.8-r1^bs

     (4.7.6) 4.7.6^bs

     (4.7.10) 4.7.10^bs

     (4.8.17-r2) 4.8.17-r2^bs

     (4.9.21) (~)4.9.21^bs

     (4.9.22) (~)4.9.22^bs

     (4.9.23) (~)4.9.23^bs

     (4.9.24) (~)4.9.24^bs
```

up to 4.9.24 is available in testing.

Go with 4.9.24.

----------

## h4rdened

```
uname -a

Linux linux 4.9.24-hardened #1 SMP Wed May 10 16:20:25 Local time zone must be set--see zic  x86_64 Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz GenuineIntel GNU/Linux
```

Agree with Neddy, the 4.9.24 is fine

----------

## archnaid

Thanks for the replies. Bit of a Gentoo n00b, didn't think to check if there were more recent versions in hardened-sources that I could unmask.

So: I removed the 4.8.x, unmasked the 4.9.24, emerged it, and went through the config. The config was much less friendly in that there were not clues in the defaults to help make choices (all PaX, GRSecurity, etc options default to N). At any rate, made some selection after reading through the helps for each, and went to make the kernel.

Same issue (perhaps worse), tons and tons of errors like before:

```
Section mismatch in reference from the variable
```

Did a sanity check on the config for the 4.9.16-gentoo source (reminder: this is currently running kernel that I successfully built), the relevant flags were enabled (DEBUG_SECTION_MISMATCH and SECTION_MISMATCH_WARN_ONLY), so it's not a cosmetic difference.

As another sanity check, I again did a make distclean; copied in the 4.9.16 config; make olddefconfig (which should have set all new options to N); make. Same issue.

So... where to now?

And by the way h4rdened, both of your links go to the same page.

Thanks again for the help!

----------

## h4rdened

 *archnaid wrote:*   

> Thanks for the replies. Bit of a Gentoo n00b, didn't think to check if there were more recent versions in hardened-sources that I could unmask.
> 
> So: I removed the 4.8.x, unmasked the 4.9.24, emerged it, and went through the config. The config was much less friendly in that there were not clues in the defaults to help make choices (all PaX, GRSecurity, etc options default to N). At any rate, made some selection after reading through the helps for each, and went to make the kernel.
> 
> Same issue (perhaps worse), tons and tons of errors like before:
> ...

 

Yes will edit my post, thanks to point this out.

About the section mismatch, the short answer is those are harmless and can be ignored 

The long answer is the grsec team have enabled a debug tracking when the kernel is building to catch some "problem" in the code and they are fixing slow by slow, on every grsec patch update. According to their statement, those mismatch are endless and as, it may lead to a security problem (by exploiting a memory bug), they take some of their time to fix the maximum they can. But the risk even with 2k mismatch on a single build are extremely low.

I'm not dev of low level programming, some of my words to describ the technical thing of those could be not exact. But you can rely on "Harmless and can be ignored", this is said by the grsec team.

----------

## archnaid

I'm no dev either. I'm just surprised that building the kernel, with the same gcc profile and toolchain, causes the issues -- even if none of the grsec etc. options are configured. In other words, it would seem for that to be true, what you're compiling is setting its own options outside of the config I gave it. Maybe it's normal.

I found that with Linode, I could dynamically resize my disk, so I ~halved it and duplicated the system disk. Kinda cool, I can always choose to boot the other if things fail, or just roll back to my current point   :Very Happy: 

So... cleaned things up, threw back in my custom config, make, make install... and it booted successfully it seems. uname -r returns 4.9.24-hardened.

Still not totally comfortable with ignoring all of those errors, but forging ahead for now... Thanks again for all of the inputs.

----------

## h4rdened

 *archnaid wrote:*   

> I'm no dev either. I'm just surprised that building the kernel, with the same gcc profile and toolchain, causes the issues -- even if none of the grsec etc. options are configured. In other words, it would seem for that to be true, what you're compiling is setting its own options outside of the config I gave it. Maybe it's normal.
> 
> I found that with Linode, I could dynamically resize my disk, so I ~halved it and duplicated the system disk. Kinda cool, I can always choose to boot the other if things fail, or just roll back to my current point  
> 
> So... cleaned things up, threw back in my custom config, make, make install... and it booted successfully it seems. uname -r returns 4.9.24-hardened.
> ...

 

Will give you some quote of the grsec team to help you getting comfortable with thoses warning (which made me at the beginning of using grsecurity, the same feeling)

 *Quote:*   

> Additional compiler warning flags are added by PaX to reveal more potential bugs within the vanilla kernel. The addition of grsecurity/PaX hasn't added code that is causing those warnings (which don't cause compilation to fail), it's just providing additional information.
> 
> -Brad

 

 *Quote:*   

> the extra section mismatches (on top of the vanilla linux count, that is) are due to PaX detecting writable function pointers as well, not related to __init. if you want to get back the original counts, just revert the hunks applied to scripts/mod/modpost.c.

 

 *Quote:*   

> the extra section mismatches are due to my changes, i explicitly
> 
> added detection for writeable function pointers which are potential
> 
> exploit targets, just to know how many of them there are. we've been
> ...

 

Hope it's help

----------

