# gcc-ing new kernel: undefined reference to `____ilog2_NaN'

## majoron

Hi,

I'm installing a hardened system on a virtual machine.

The default gcc is gcc-7.3.0 and the hardened kernel that gets installed with "emerge sys-kernel/hardened-sources" is linux-4.8.17-hardened-r2

But there is a problem when I try to compile the kernel during the installation process:

```

# make && make modules_install

...

  LINK    vmlinux

  LD      vmlinux.o

  MODPOST vmlinux.o

WARNING: modpost: Found 6839 writable function pointer(s).

To see full details build your kernel with:

'make CONFIG_DEBUG_SECTION_MISMATCH=y'

  GEN     .version

  CHK     include/generated/compile.h

  UPD     include/generated/compile.h

  CC      init/version.o

  LD      init/built-in.o

kernel/built-in.o: In function `update_wall_time':

(.text+0x6da07): undefined reference to `____ilog2_NaN'

make: *** [Makefile:953: vmlinux] Error 1

```

It looks to me like this and this, though not completely sure...

In any case: what should I do?

I know that I can install another kernel, but as I have interest in having a secure system, what kernel should I use instead?

TIA

----------

## eccerr0r

1. Use an older gcc than 7.3

2. Hand apply the patch that Linus wrote.

3. Use a newer kernel if you don't really use all the features in the "hardened" kernel.

I'm not sure... did the meltdown patches get backported to hardened kernels? ... if not, are they really more "secure"?

----------

## toralf

/me thinks, that a 4.8.x hardened kernel isn't more secure than a current vanilla

----------

## majoron

 *toralf wrote:*   

> /me thinks, that a 4.8.x hardened kernel isn't more secure than a current vanilla

 

Hi, /me.

Can you ellaborate on this, please? In the gentoo docs it is written that hardened sources bring some additional security enhancements...

----------

## majoron

 *eccerr0r wrote:*   

> 1. Use an older gcc than 7.3
> 
> 2. Hand apply the patch that Linus wrote.
> 
> 3. Use a newer kernel if you don't really use all the features in the "hardened" kernel.
> ...

 

Thank you.

I prefer to go to number 3. My question was in the direction of what kernel version should I use if the default hardened is the only stable option and is not working.

----------

## eccerr0r

Honestly security is a focus in *every* kernel - there's no reason to leave a security hole in any kernel release unless it was unintentional or they were working on it.  It's just that some kernels like grsec tried to take security to another level making it harder to exploit if a bug was found in the kernel itself.  But it still doesn't cover everything either.

I would think just going to the regular vanilla/gentoo-sources kernels is good enough, especially if it's just a home server, and even business servers...

----------

## majoron

 *eccerr0r wrote:*   

> Honestly security is a focus in *every* kernel - there's no reason to leave a security hole in any kernel release unless it was unintentional or they were working on it.  It's just that some kernels like grsec tried to take security to another level making it harder to exploit if a bug was found in the kernel itself.  But it still doesn't cover everything either.
> 
> I would think just going to the regular vanilla/gentoo-sources kernels is good enough, especially if it's just a home server, and even business servers...

 

Ok, thank you. 

I get your point but, what are hardened sources for?

----------

## Hu

As above, hardened sources were intended to have features that made exploiting a bug difficult (or ideally, impossible), even once you knew the bug existed and how it worked.  For example, making mutable data non-executable means that an attacker cannot load his exploit code into a data area, then trigger a bug to jump to it.  When he does, the program will simply crash because the data is marked non-executable.

Mainline kernels fix bugs as they are recognized as such.  In any project this large, bugs are inevitable.  The question is whether the bugs, once discovered, can be abused to violate system security.  Your choice here is between an outdated kernel with known vulnerabilities, but special patches that might make exploiting the known bugs harder, or a current kernel without well known vulnerabilities, but also without (as many) countermeasures to make exploiting the not-currently-known bugs difficult.

----------

