linux-kernel - [PATCH 0/1] Introduce CONFIG_DEBUG_INFO

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20231004165804.659482-1-stephen.s.brennan@oracle.com>
Date:   Wed,  4 Oct 2023 09:58:03 -0700
From:   Stephen Brennan <stephen.s.brennan@...cle.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Stephen Brennan <stephen.s.brennan@...cle.com>,
        linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-debuggers@...r.kernel.org
Subject: [PATCH 0/1] Introduce CONFIG_DEBUG_INFO_IKCONFIG

Hello,

CONFIG_IKCONFIG is really nice, in particular, for debuggers. Interpreting data
structures becomes much easier if you know how the kernel was configured.
However, most distributions end up disabling it because it consumes quite a bit
of kernel memory at runtime when built-in. The result is that debuggers have to
find workarounds, like checking for the existence of symbols which would only be
present on certain configurations. However, this isn't always possible.

Building CONFIG_IKCONFIG=m is supposed to address this: users get the choice to
load the module if they want it, and if not, the .ko is there so that a tool
could read it with logic like "scripts/extract-ikconfig". In practice, this
leads to a few issues. First, many distributions still end up disabling this
option, and second, debuggers are more and more frequently relying on "build ID"
to fetch the corresponding debug information. This means that they may not have
the entire debuginfo package containing configs.ko - they only have the vmlinux
and modules corresponding to what was actually loaded in the kernel. So we are
once again stuck with expecting users to load a module containing a blob of data
that can't be paged out.

I'd like to propose an alternative, which I named CONFIG_DEBUG_INFO_IKCONFIG.
When IKCONFIG is not built-in, this adds the gzipped kernel configuration to a
new section on the vmlinux file: .debug_linux_ikconfig. Since it is named with
the ".debug" prefix, it is stripped out of any bootable images, but remains in
the debug info vmlinux file. It can still be used with scripts/extract-ikconfig.
But now, debuggers can hope to find configuration information automatically,
without asking users to dedicate runtime memory to holding this information.

The hope is that this will be enabled by most distributions since it has no
runtime cost and a very minimal cost for debuginfo (which is usually on the
order of hundreds of megabytes, not a few tens of kilobytes).

Thanks,
Stephen

Stephen Brennan (1):
  kernel/config: Introduce CONFIG_DEBUG_INFO_IKCONFIG

 include/asm-generic/vmlinux.lds.h |  3 ++-
 kernel/Makefile                   |  1 +
 kernel/configs-debug.S            | 18 ++++++++++++++++++
 lib/Kconfig.debug                 | 14 ++++++++++++++
 4 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 kernel/configs-debug.S

-- 
2.39.3