Re: [mel:mm-vmscan-node-lru-v7r3 38/200] slub.c:undefined reference to `cache_random_seq_create'

[Kees Cook <keescook@chromium.org>]

On Mon, Jun 13, 2016 at 4:51 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Jun 13, 2016 at 2:11 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
>> On Tue, 14 Jun 2016 03:37:57 +0800 kbuild test robot <fengguang.wu@intel.com> wrote:
>>
>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/mel/linux mm-vmscan-node-lru-v7r3
>>> head:   276a5614a25ce20248f42bd4fb025b80ae0c9be1
>>> commit: 44c61fe5d7f13025a2a1f6efbbc0da75ad93ee19 [38/200] mm: SLUB freelist randomization
>>> config: x86_64-randconfig-x018-06140033 (attached as .config)
>>> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
>>> reproduce:
>>>         git checkout 44c61fe5d7f13025a2a1f6efbbc0da75ad93ee19
>>>         # save the attached .config to linux build tree
>>>         make ARCH=x86_64
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>>    mm/built-in.o: In function `init_cache_random_seq':
>>> >> slub.c:(.text+0x507dc): undefined reference to `cache_random_seq_create'
>>>    mm/built-in.o: In function `__kmem_cache_release':
>>> >> (.text+0x53979): undefined reference to `cache_random_seq_destroy'
>
> With that config, I get these errors.

The above errors were already fixed in
mm-slub-freelist-randomization-fix (moving it out of CONFIG_SLABINFO).

>
>> I don't even get that far with that .config.  With gcc-4.4.4 I get
>>
>> init/built-in.o: In function `initcall_blacklisted':
>> main.c:(.text+0x41): undefined reference to `__stack_chk_guard'
>> main.c:(.text+0xbe): undefined reference to `__stack_chk_guard'
>> init/built-in.o: In function `do_one_initcall':
>> (.text+0xeb): undefined reference to `__stack_chk_guard'
>> init/built-in.o: In function `do_one_initcall':
>> (.text+0x22b): undefined reference to `__stack_chk_guard'
>> init/built-in.o: In function `name_to_dev_t':
>> (.text+0x320): undefined reference to `__stack_chk_guard'
>> init/built-in.o:(.text+0x52e): more undefined references to `__stack_chk_guard'
>
> This, I don't. I'm scratching my head about how that's possible. The
> __stack_chk_guard is a compiler alias on x86...
>
>> Kees touched it last :)
>
> I'll take a closer look tomorrow...

Stupid question: were you doing a build for x86? This error really
shouldn't be possible since gcc defaults to tls for the guard on x86.
I don't have gcc 4.4.4 easily available, but I don't think it even has
the -mstack-protector-guard option to force this to change. (And I see
no reference to this option in the kernel tree.) AFAICT this error
should only happen when building with either
-mstack-protector-guard=global or an architecture that forces that,
along with some new code that triggers the stack protector but lacks
the symbol at link time, which also seems impossible. :P

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>