[Bug libdw/30980] New: offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.
https://sourceware.org/bugzilla/show_bug.cgi?id=30980 Bug ID: 30980 Summary: offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed. Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: cebtenzzre at gmail dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 15181 --> https://sourceware.org/bugzilla/attachment.cgi?id=15181&action=edit The file that elfutils crashes on while trying to read debug info. I ran into this crash while systemd-coredump was trying to process a coredump from evolution. evolution backtrace: #0 0x in () #1 0x7f8d92ec6ba1 in compute_next_step (assistant=0x55a0bfe3ea60) at ../gtk/gtk/gtkassistant.c:1035 #2 gtk_assistant_next_page (assistant=0x55a0bfe3ea60) at ../gtk/gtk/gtkassistant.c:1610 #3 0x7f8d7a34ad5e in () at /usr/lib/evolution/libevolution-mail.so #4 0x7f8d8e356252 in e_simple_async_result_complete () at /usr/lib/evolution/libevolution-util.so #5 0x7f8d8e3562b9 in () at /usr/lib/evolution/libevolution-util.so #6 0x7f8d93834f19 in g_main_dispatch (context=0x55a0be1fefc0) at ../glib/glib/gmain.c:3476 #7 0x7f8d938932b7 in g_main_context_dispatch_unlocked (context=0x55a0be1fefc0) at ../glib/glib/gmain.c:4284 #8 g_main_context_iterate_unlocked.isra.0 (context=0x55a0be1fefc0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../glib/glib/gmain.c:4349 #9 0x7f8d93835b47 in g_main_loop_run (loop=0x55a0bed6cde0) at ../glib/glib/gmain.c:4551 #10 0x7f8d930337ed in gtk_main () at ../gtk/gtk/gtkmain.c:1329 #11 0x55a0bcea857f in main () elfutils backtrace: #5 0x7fb1fae54d26 in __assert_fail (assertion=assertion@entry=0x7fb1fa4e1c30 "mod->e_type == ET_REL", file=file@entry=0x7fb1fa4e1c26 "offline.c", line=line@entry=53, function=function@entry=0x7fb1fa4fded0 <__PRETTY_FUNCTION__.0.lto_priv.43> "dwfl_offline_section_address") at assert.c:101 #6 0x7fb1fa4c3c30 in dwfl_offline_section_address (mod=, userdata=, modname=, base=, secname=, shndx=, shdr=0x7fff255196b0, addr=0x7fff255196c0) at ../libdwfl/offline.c:53 #7 0x7fb1fa4c859c in __libdwfl_relocate_value (mod=mod@entry=0x5624c5cd80d0, elf=elf@entry=0x5624c605dc30, shstrndx=shstrndx@entry=0x7fff25519760, shndx=4, value=value@entry=0x7fff25519768) at ../libdwfl/relocate.c:72 #8 0x7fb1fa4c8772 in find_elf_build_id (mod=mod@entry=0x5624c5cd80d0, e_type=1, elf=elf@entry=0x5624c605dc30, build_id_bits=build_id_bits@entry=0x7fff25519890, build_id_elfaddr=build_id_elfaddr@entry=0x7fff25519888, build_id_len=build_id_len@entry=0x7fff25519884) at ../libdwelf/dwelf_elf_gnu_build_id.c:113 #9 0x7fb1fa4c88e3 in __libdwfl_find_elf_build_id (mod=mod@entry=0x5624c5cd80d0, elf=0x5624c605dc30, build_id_bits=build_id_bits@entry=0x7fff25519890, build_id_elfaddr=build_id_elfaddr@entry=0x7fff25519888, build_id_len=build_id_len@entry=0x7fff25519884) at ../libdwelf/dwelf_elf_gnu_build_id.c:142 #10 0x7fb1fa4c8992 in __libdwfl_find_build_id (mod=mod@entry=0x5624c5cd80d0, set=set@entry=false, elf=) at ../libdwfl/dwfl_module_build_id.c:70 #11 0x7fb1fa4c939e in validate (debuglink_crc=, check=, fd=, mod=0x5624c5cd80d0) at ../libdwfl/find-debuginfo.c:141 #12 find_debuginfo_in_path (mod=mod@entry=0x5624c5cd80d0, file_name=file_name@entry=0x5624c5cd82b0 "/usr/lib/libjavascriptcoregtk-4.1.so.0", debuglink_file=debuglink_file@entry=0x7faf25bbedc8 "crti.o.debug", debuglink_crc=debuglink_crc@entry=465747295, debuginfo_file_name=debuginfo_file_name@entry=0x5624c5cd8128) at ../libdwfl/find-debuginfo.c:326 #13 0x7fb1fa4ccfc0 in dwfl_standard_find_debuginfo (mod=0x5624c5cd80d0, userdata=, modname=, base=, file_name=0x5624c5cd82b0 "/usr/lib/libjavascriptcoregtk-4.1.so.0", debuglink_file=0x7faf25bbedc8 "crti.o.debug", debuglink_crc=465747295, debuginfo_file_name=0x5624c5cd8128) at ../libdwfl/find-debuginfo.c:386 #14 0x7fb1fa4c5b83 in find_debuginfo (mod=mod@entry=0x5624c5cd80d0) at ../libdwfl/dwfl_module_getdwarf.c:538 #15 0x7fb1fa4cfa60 in find_dw (mod=0x5624c5cd80d0) at ../libdwfl/dwfl_module_getdwarf.c:1412 #16 dwfl_module_getdwarf (mod=mod@entry=0x5624c5cd80d0, bias=0x7fff25519b88) at ../libdwfl/dwfl_module_getdwarf.c:1446 #17 0x7fb1fa4d8bd8 in dwfl_module_addrdie (mod=0x5624c5cd80d0, addr=140245923026755, bias=) at ../libdwfl/dwfl_module_addrdie.c:38 #18 0x7fb1fb0ed9e9 in frame_callback (frame=, userdata=0x7fff25519e50) at ../systemd-stable/src/shared/elf-util.c:203 #19 0x7fb1fa4de175 in dwfl_thread_getframes (thread=0x7fff25519ce0, callback=0x7fb1fb0ed920 , arg=0x7fff25519e50) at ../libdwfl/dwfl_frame.c:428 #20 0x7fb1fb0edd08 in thread_callback (thread=0x7fff25519
[Bug libdw/30980] offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.
https://sourceware.org/bugzilla/show_bug.cgi?id=30980 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- Comment on attachment 15181 --> https://sourceware.org/bugzilla/attachment.cgi?id=15181 The file that elfutils crashes on while trying to read debug info. One slightly odd thing, although probably not the real cause of this bug, is that the build-id stored in the libjavascriptcoregtk-4.1.so.0.4.10 is only 8 bytes wide: Note section [ 1] '.note.gnu.build-id' of 24 bytes at offset 0x318: Owner Data size Type GNU8 GNU_BUILD_ID Build ID: 289bbb6d9dfaf6e3 Normally they are ~20 bytes wide. Which guarantees they are globally unique. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30980] offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.
https://sourceware.org/bugzilla/show_bug.cgi?id=30980 --- Comment #2 from Mark Wielaard --- This however is really odd and might explain why we get onto an ET_REL path: $ eu-readelf -x .gnu_debuglink ~/Downloads/libjavascriptcoregtk-4.1.so.0.4.10.zst Hex dump of section [28] '.gnu_debuglink', 84 bytes at offset 0x1fbedc8: 0x 63727469 2e6f2e64 65627567 crti.o.debug 0x0010 2aa4dad4 63727462 6567696e 532e6f2e *...crtbeginS.o. 0x0020 64656275 6700 39c05e5d 63727465 debug...9.^]crte 0x0030 6e64532e 6f2e6465 62756700 6b271cc4 ndS.o.debug.k'.. 0x0040 6372746e 2e6f2e64 65627567 crtn.o.debug 0x0050 5fbdc21b_... So when looking for the separate .debug file, when we don't have a build-id match, we will search for crti.o.debug... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30980] offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.
https://sourceware.org/bugzilla/show_bug.cgi?id=30980 --- Comment #3 from Mark Wielaard --- Would you happen to know where systemd-stable/src/coredump/coredump.c and systemd-stable/src/shared/elf-util.c come from? I am trying to figure out how the dwfl has been setup that parse_core uses, but I cannot find those files or the parse_core function in current systemd. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30980] offline.c:53: dwfl_offline_section_address: Assertion `mod->e_type == ET_REL' failed.
https://sourceware.org/bugzilla/show_bug.cgi?id=30980
--- Comment #4 from Mark Wielaard ---
O, apparently systemd isn't updated on freedesktop.org anymore. So my git repo
is stale. The copy on github (sigh) does have those files and the parse_core
function.
The dwfl setup is done with:
const Dwfl_Callbacks callbacks = {
.find_elf = sym_dwfl_build_id_find_elf,
.section_address = sym_dwfl_offline_section_address,
.find_debuginfo = sym_dwfl_standard_find_debuginfo,
};
Where sym_dwfl_offline_section_address is through some magic the libdw.so
dwfl_offline_section_address.
At least that explains why dwfl_offline_section_address is called.
--
You are receiving this mail because:
You are on the CC list for the bug.
[PATCH] debuginfod PR29472: metadata queries
Hi - This patch, mostly the work of Ryan Goldberg, has undergone some decent testing alongside its systemtap consumer (which is already merged). If there's interest, I could install it speculatively on one of the fedora debuginfod servers, the one that's already running its prerequisite RPM-IMA patch (also pending). Sorry, parts of the patch are hard to read here, esp. in the debuginfod-client.c code, because it refactors several complicated query functions significantly. (It has to support both one-winner and query-all styles to upstream servers.) The code is also all in the users/fche/try-pr29472 branch. Before a final commit, might nuke the ChangeLog bits and copy key content over into the git commit message. commit 8dd1108b6779b8efd5e4037e0653de7702839cc8 Author: Frank Ch. Eigler Date: Tue Apr 11 23:35:25 2023 -0400 PR29472: debuginfod: add metadata query webapi, C api, client This patch extends the debuginfod API with a "metadata query" operation. It allows clients to request an enumeration of file names known to debuginfod servers, returning a JSON response including the matching buildids. This lets clients later download debuginfo for a range of versions of the same named binaries, in case they need to to prospective work (like systemtap-based live-patching). It also lets server operators implement prefetch triggering operations for popular but slow debuginfo slivers like kernel vdso.debug files on fedora. Implementation requires a modern enough json-c library, namely 0.11, which dates from 2014. Without that, debuginfod client/server bits will refuse to build. % debuginfod-find metadata file /bin/ls % debuginfod-find metadata glob "/usr/local/bin/c*" Documentation and testing are included. Signed-off-by: Ryan Goldberg Signed-off-by: Frank Ch. Eigler diff --git a/ChangeLog b/ChangeLog index b3b1a8ebc93a..72205e970060 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2023-04-12 Ryan Golberg , Frank Ch. Eigler + + PR29472: debuginfod metadata query + * NEWS: Mention this. + * configure.ac: Look for json-c library. + 2023-08-14 Ryan Goldberg * configure.ac (ENABLE_IMA_VERIFICATION): Look for librpm, libimaevm and libcrypto diff --git a/NEWS b/NEWS index 53c717eba546..281bbb6d5e47 100644 --- a/NEWS +++ b/NEWS @@ -7,6 +7,8 @@ debuginfod: Schema change (reindexing required, sorry!) for a 60% part of the sqlite index; also, more deliberate sqlite -wal management during scanning using the --scan-checkpoint option. + +debuginfod: New API for metadata queries: file name -> buildid. Version 0.189 "Don't deflate!" diff --git a/config/elfutils.spec.in b/config/elfutils.spec.in index 2e962bb40d07..8b5a08b076f7 100644 --- a/config/elfutils.spec.in +++ b/config/elfutils.spec.in @@ -31,6 +31,8 @@ BuildRequires: pkgconfig(libmicrohttpd) >= 0.9.33 BuildRequires: pkgconfig(libcurl) >= 7.29.0 BuildRequires: pkgconfig(sqlite3) >= 3.7.17 BuildRequires: pkgconfig(libarchive) >= 3.1.2 +# For debugindod metadata query +BuildRequires: pkgconfig(json-c) >= 0.11 # For tests need to bunzip2 test files. BuildRequires: bzip2 @@ -42,6 +44,8 @@ BuildRequires: bsdtar BuildRequires: curl # For run-debuginfod-response-headers.sh test case BuildRequires: socat +# For run-debuginfod-find-metadata.sh +BuildRequires: jq # For debuginfod rpm IMA verification BuildRequires: rpm-devel diff --git a/configure.ac b/configure.ac index bedd99e3b8a4..52257cf65d6c 100644 --- a/configure.ac +++ b/configure.ac @@ -851,9 +851,6 @@ AS_IF([test "x$enable_libdebuginfod" != "xno"], [ enable_libdebuginfod=yes # presume success PKG_PROG_PKG_CONFIG PKG_CHECK_MODULES([libcurl],[libcurl >= 7.29.0],[],[enable_libdebuginfod=no]) - if test "x$enable_libdebuginfod" = "xno"; then -AC_MSG_ERROR([dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.]) - fi else AC_MSG_NOTICE([building (bootstrap) dummy libdebuginfo library]) fi @@ -886,9 +883,7 @@ AS_IF([test "x$enable_debuginfod" != "xno"], [ PKG_CHECK_MODULES([oldlibmicrohttpd],[libmicrohttpd < 0.9.51],[old_libmicrohttpd=yes],[old_libmicrohttpd=no]) PKG_CHECK_MODULES([sqlite3],[sqlite3 >= 3.7.17],[],[enable_debuginfod=no]) PKG_CHECK_MODULES([libarchive],[libarchive >= 3.1.2],[],[enable_debuginfod=no]) -if test "x$enable_debuginfod" = "xno"; then - AC_MSG_ERROR([dependencies not found, use --disable-debuginfod to disable.]) -fi +PKG_CHECK_MODULES([jsonc],[json-c >= 0.11],[],[enable_debuginfod=no]) ]) AS_IF([test "x$enable_debuginfod" != "xno"],AC_DEFINE([ENABLE_DEBUGINFOD],[1],[Build debuginfod])) diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog index f4d98c2e93bc..6cc8920c1f03 100644 --- a/debuginfod/ChangeLo
[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30978 --- Comment #4 from Frank Ch. Eigler --- Note that the main problem with this sort of scheme is not the checksum (whether CRC or a hash). That part can help provide some assurance against accidental corruption. (Plus you'd need external checksums for source files, which can't get additional ELF doohickeys inserted. But you'd need crypto signatures on those hashes in order to protect against deliberate corruption anywhere between the original build system and your client. That in turn requires distribution of crypto keys. It goes well beyond the objcopy stuff. I'm not sure whether the debian ecosystem has started thinking about this stuff, but when/if they do, debuginfod should be adaptable to pass on whatever assurances are possible. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30978 --- Comment #5 from Dominique Martinet --- debian has kept .gnu_debuglink (like fedora), so if we extend that to store a more reliable hash I believe that process should be fairly straightforward as they already must have an objcopy --add-gnu-debuglink command somewhere that could just be updated I haven't seen anything about IMA on debian though, so that'd likely come much later -- You are receiving this mail because: You are on the CC list for the bug.
