lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 11 Apr 2019 14:15:36 -0400
From:   Sinan Kaya <Okaya@...nel.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Josh Triplett <josh@...htriplett.org>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Adrian Reber <adrian@...as.de>,
        Richard Guy Briggs <rgb@...hat.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Petr Mladek <pmladek@...e.com>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Mikulas Patocka <mpatocka@...hat.com>,
        Robin Murphy <robin.murphy@....com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Changbin Du <changbin.du@...el.com>
Subject: Re: [PATCH v3] init: Do not select DEBUG_KERNEL by default

On 4/11/2019 1:48 AM, Masahiro Yamada wrote:
>> I was going by what Kconfig tells me
>>
>> Symbol: KALLSYMS_ALL [=n]
>>    Depends on: DEBUG_KERNEL [=n] && KALLSYMS [=y]
> Lots of features have 'depends on DEBUG_KERNEL'.
> What is special about KALLSYMS_ALL here?

I had to do some learning about KALLSYSM_ALL. Based on my limited
searching, KALLSYMS_ALL allows you to locate the symbol location
at runtime from the kernel.

Without KALLSYM_ALL, you can only locate the kernel code only. With
KALLSYMS_ALL, you can locate the symbols for any data structure
including kernel modules.

I'm not a KALLSYMS person but based on my search, I'd consider
KALLSYMS_ALL a debug feature as it is today.

kernel/kallsyms.c:              else if (IS_ENABLED(CONFIG_KALLSYMS_ALL))
kernel/livepatch/Kconfig:       depends on KALLSYMS_ALL
kernel/module.c:#ifdef CONFIG_KALLSYMS_ALL
kernel/module.c:#ifndef CONFIG_KALLSYMS_ALL

lib/Kconfig.debug:      select KALLSYMS_ALL
     config LOCKDEP
             bool
             depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
             select KALLSYMS
             select KALLSYMS_ALL

lib/Kconfig.debug:      select KALLSYMS_ALL
     config LATENCYTOP
             bool "Latency measuring infrastructure"
             select KALLSYMS
             select KALLSYMS_ALL

scripts/link-vmlinux.sh:        if [ -n "${CONFIG_KALLSYMS_ALL}" ]; then

Powered by blists - more mailing lists