Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note
Hi Luca, On Sat, 2022-03-26 at 18:19 +, Luca Boccassi wrote: > > Already working on the updated script, the native type is exactly > > the > > approach I was taking, this works fine on a Debian machine on s390x > > (and also on x86_64), eg: > > > > -BYTE(0x04) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of > > Owner including NUL */ > > -BYTE(0x47) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of > > Value including NUL */ > > -BYTE(0x7e) BYTE(0x1a) BYTE(0xfe) BYTE(0xca) /* Note ID */ > > +LONG(0x04) /* Length of > > Owner including NUL */ > > +LONG(0x0047)/* Length of > > Value including NUL */ > > +LONG(0xcafe1a7e)/* Note ID */ > > > > The rest of the fields are C strings so no change needed, I > > believe. > > > > Does this look right to you as well? > > Here's the fix: > > https://src.fedoraproject.org/rpms/package-notes/pull-request/3# > > Now it's up to the Fedora folks what to do with it. I tested the > updated script on Debian x86_64 and s390x, and it all works as > intended. Sorry again for the breakage! Yes, that looks correct. Note that the example on https://systemd.io/COREDUMP_PACKAGE_METADATA/ also uses BYTEs for everything, instead of LONGs for the namesz, descsz and type words. This also seems to make sure everything is aligned (at 4 bytes). An ELF note is defined as an array of (4 byte) words. Where the first 3 (n_namesz, n_descsz, n_type) have a special interpretation. Your name string is also exactly 4 bytes "FDO\0", so you don't need any extra padding to make the start of the descriptor be aligned. And since you don't add any other notes to the section you don't need to explicitly pad the description. The linker should take care of that in case it merges note sections/segments. Still I would really recommend trying to add native support to linkers for package notes, just like they support build-ids by default. That also makes it easier for the linker to simply merge the notes. Trying to do this with inserting a linker script really feels very fragile. Cheers, Mark
Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note
On Mon, 2022-03-28 at 11:57 +0200, Mark Wielaard wrote: > Hi Luca, > > On Sat, 2022-03-26 at 18:19 +, Luca Boccassi wrote: > > > Already working on the updated script, the native type is exactly > > > the > > > approach I was taking, this works fine on a Debian machine on s390x > > > (and also on x86_64), eg: > > > > > > -BYTE(0x04) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of > > > Owner including NUL */ > > > -BYTE(0x47) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of > > > Value including NUL */ > > > -BYTE(0x7e) BYTE(0x1a) BYTE(0xfe) BYTE(0xca) /* Note ID */ > > > +LONG(0x04) /* Length of > > > Owner including NUL */ > > > +LONG(0x0047)/* Length of > > > Value including NUL */ > > > +LONG(0xcafe1a7e)/* Note ID */ > > > > > > The rest of the fields are C strings so no change needed, I > > > believe. > > > > > > Does this look right to you as well? > > > > Here's the fix: > > > > https://src.fedoraproject.org/rpms/package-notes/pull-request/3# > > > > Now it's up to the Fedora folks what to do with it. I tested the > > updated script on Debian x86_64 and s390x, and it all works as > > intended. Sorry again for the breakage! > > Yes, that looks correct. Note that the example on > https://systemd.io/COREDUMP_PACKAGE_METADATA/ also uses BYTEs for > everything, instead of LONGs for the namesz, descsz and type words. > > This also seems to make sure everything is aligned (at 4 bytes). An ELF > note is defined as an array of (4 byte) words. Where the first 3 > (n_namesz, n_descsz, n_type) have a special interpretation. Your name > string is also exactly 4 bytes "FDO\0", so you don't need any extra > padding to make the start of the descriptor be aligned. And since you > don't add any other notes to the section you don't need to explicitly > pad the description. The linker should take care of that in case it > merges note sections/segments. Fix for the doc is queued too: https://github.com/systemd/systemd/pull/22879 > Still I would really recommend trying to add native support to linkers > for package notes, just like they support build-ids by default. That > also makes it easier for the linker to simply merge the notes. Trying > to do this with inserting a linker script really feels very fragile. Yes, that would definitely be ideal. But a bit of a chicken-and-egg: we had to get the spec established before there's any realistic change of getting a full new feature merged in BFD, but we can't get it established if we can't use it anywhere. This way we can 'bootstrap' ourselves, and once the idea and usage is more widely accepted, we have a good case to do just that. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Issue 46094 in oss-fuzz: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in elf_compress_gnu
Status: New Owner: CC: elfut...@sourceware.org, da...@adalogics.com, evv...@gmail.com, izz...@google.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Security_Severity-Medium Proj-elfutils Reported-2022-03-28 Type: Bug-Security New issue 46094 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in elf_compress_gnu https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=46094 Detailed Report: https://oss-fuzz.com/testcase?key=4725021634854912 Project: elfutils Fuzzing Engine: libFuzzer Fuzz Target: fuzz-libdwfl Job Type: libfuzzer_msan_elfutils Platform Id: linux Crash Type: Use-of-uninitialized-value Crash Address: Crash State: elf_compress_gnu check_section dwarf_begin_elf Sanitizer: memory (MSAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_elfutils&range=202203161800:20220317 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4725021634854912 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 46094 in oss-fuzz: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in elf_compress_gnu
Comment #1 on issue 46094 by evv...@gmail.com: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in elf_compress_gnu https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=46094#c1 It was reported in https://sourceware.org/bugzilla/show_bug.cgi?id=29000 -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 46095 in oss-fuzz: elfutils:fuzz-libelf: Use-of-uninitialized-value in elf_compress_gnu
Status: New Owner: CC: elfut...@sourceware.org, da...@adalogics.com, evv...@gmail.com, izz...@google.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Security_Severity-Medium Proj-elfutils Reported-2022-03-28 Type: Bug-Security New issue 46095 by ClusterFuzz-External: elfutils:fuzz-libelf: Use-of-uninitialized-value in elf_compress_gnu https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=46095 Detailed Report: https://oss-fuzz.com/testcase?key=6467719510228992 Project: elfutils Fuzzing Engine: libFuzzer Fuzz Target: fuzz-libelf Job Type: libfuzzer_msan_elfutils Platform Id: linux Crash Type: Use-of-uninitialized-value Crash Address: Crash State: elf_compress_gnu fuzz_logic_one fuzz-libelf.c Sanitizer: memory (MSAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_elfutils&range=202203240610:202203241200 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6467719510228992 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 46095 in oss-fuzz: elfutils:fuzz-libelf: Use-of-uninitialized-value in elf_compress_gnu
Comment #1 on issue 46095 by evv...@gmail.com: elfutils:fuzz-libelf: Use-of-uninitialized-value in elf_compress_gnu https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=46095#c1 It was reported in https://sourceware.org/bugzilla/show_bug.cgi?id=29000 as well. To avoid duplicates like this the fuzz target should probably be trimmed a bit: https://github.com/google/oss-fuzz/pull/7395#issuecomment-1079246630 -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[PATCH] Avoid dlopen on debuginfod-client when not configured
Loading debuginfod-client is expensive, especially when
FIPS is enabled, as it goes through time intensive self-checks
on load. Avoid dlopen() when no debuginfo url is set.
Signed-off-by: Dirk Müller
---
libdwfl/ChangeLog | 5 +
libdwfl/debuginfod-client.c | 12 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index 9c5c8517..1ec13f30 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,8 @@
+2022-03-28 Dirk Müller
+
+ * debuginfod-client.c (__libdwfl_debuginfod_init): Skip dlopen
+ if debuginfod url is unset.
+
2022-02-18 Mark Wielaard
* image-header.c (__libdw_image_header): Assign header values for
diff --git a/libdwfl/debuginfod-client.c b/libdwfl/debuginfod-client.c
index 99b66b6e..af9d1363 100644
--- a/libdwfl/debuginfod-client.c
+++ b/libdwfl/debuginfod-client.c
@@ -101,7 +101,17 @@ __libdwfl_debuginfod_end (debuginfod_client *c)
void __attribute__ ((constructor))
__libdwfl_debuginfod_init (void)
{
- void *debuginfod_so = dlopen(DEBUGINFOD_SONAME, RTLD_LAZY);
+ void *debuginfod_so;
+
+ /* Is there any server we can query? If not, don't do any work,
+ just return with ENOSYS. Don't even access the cache. */
+ char *urls_envvar = getenv(DEBUGINFOD_URLS_ENV_VAR);
+ if (urls_envvar == NULL || urls_envvar[0] == '\0')
+{
+ return;
+}
+
+ debuginfod_so = dlopen(DEBUGINFOD_SONAME, RTLD_LAZY);
if (debuginfod_so != NULL)
{
--
2.35.1
