Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Kernel build errors when moving to hardened-sources
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
archnaid
n00b
n00b


Joined: 28 May 2017
Posts: 8

PostPosted: Sun May 28, 2017 4:26 am    Post subject: Kernel build errors when moving to hardened-sources Reply with quote

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
Code:
emerge hardened-sources
I copied the config over from 4.9, and went though the updates. I did this manually the first time via
Code:
make silentoldconfig
After having issues, I tried a
Code:
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
Code:
make olddefconfig
But in each case, running make yields hundred (thousands?) of errors across many modules, all like
Code:
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
    Code:
    make menuconfig

  • Just build with
    Code:
    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.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6294

PostPosted: Sun May 28, 2017 4:46 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
archnaid
n00b
n00b


Joined: 28 May 2017
Posts: 8

PostPosted: Sun May 28, 2017 4:51 am    Post subject: Reply with quote

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 :?
Back to top
View user's profile Send private message
h4rdened
n00b
n00b


Joined: 13 May 2017
Posts: 14

PostPosted: Sun May 28, 2017 11:31 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43754
Location: 56N 3W

PostPosted: Sun May 28, 2017 1:22 pm    Post subject: Reply with quote

h4rdened,

I'm running
Code:
$ 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
Code:
$ 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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
h4rdened
n00b
n00b


Joined: 13 May 2017
Posts: 14

PostPosted: Sun May 28, 2017 4:56 pm    Post subject: Reply with quote

Code:
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
Back to top
View user's profile Send private message
archnaid
n00b
n00b


Joined: 28 May 2017
Posts: 8

PostPosted: Sun May 28, 2017 5:10 pm    Post subject: Reply with quote

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:
Code:
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!
Back to top
View user's profile Send private message
h4rdened
n00b
n00b


Joined: 13 May 2017
Posts: 14

PostPosted: Sun May 28, 2017 5:53 pm    Post subject: Reply with quote

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:
Code:
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!


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.
Back to top
View user's profile Send private message
archnaid
n00b
n00b


Joined: 28 May 2017
Posts: 8

PostPosted: Sun May 28, 2017 7:30 pm    Post subject: Reply with quote

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 :D

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.
Back to top
View user's profile Send private message
h4rdened
n00b
n00b


Joined: 13 May 2017
Posts: 14

PostPosted: Sun May 28, 2017 9:09 pm    Post subject: Reply with quote

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 :D

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.


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
eliminating some of them already but this work will never finish.

as for what they are in general, a mismatch means an unwanted reference
from one section to another. say, accessing init code or data from
normal code/data is not good since init sections are freed up on boot,
so any reference to them must not exist from permanent sections.


Hope it's help
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum