[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries

https://sourceware.org/bugzilla/show_bug.cgi?id=30978 --- Comment #3 from Dominique Martinet --- Interesting, thanks for the link! The implementation hurdle is a bit higher than updating the already-used objcopy command I was suggesting (won't be available for distros like debian that don't ship

[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries

https://sourceware.org/bugzilla/show_bug.cgi?id=30978 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment

Re: [PATCH 07/16] lib: Add eu_tsearch and eu_tfind

Hi Mark, I think having unique per-root locks might be a good idea. From a brief test, I saw around 70 roots created when parsing the test file I have been using. I have an initial idea for this that I don't think will be too complicated. I will go over my idea with John to get his input and then

Re: [PATCH 13/16] libdw: Make libdw_findcu thread-safe

Hi Mark, For the call to __libdw_intern_next_unit in __libdw_findcu, I have updated the locking to the per struct drawf lock. Although I have not encountered a data race report regarding the call to __libdw_intern_next_unit in dwarf_formref_die, I have also placed the updated locking there as well

Re: [PATCH 12/16] libdw: Make libdw_find_split_unit thread-safe

Hi Mark, As per your suggestion, I have placed the lock around the entire __libdw_find_split_unit function call. On Wed, Oct 11, 2023 at 12:17 PM Mark Wielaard wrote: > Hi Heather, > > On Tue, Oct 10, 2023 at 03:42:56PM +0200, Mark Wielaard wrote: > > From: Heather McIntyre > > > > * (tr

Re: [PATCH 11/16] libdw: Add locking around __libdw_dieabbrev for dwarf_hasattr

Hi Mark, I see now that this is incomplete considering the other places that also call this function. I do agree that global locking may be heavy if 1) implemented in all of these locations, or 2) implemented directly in __libdw_dieabbrev. We could use atomics here directly in __libdw_dieabbrev. I

[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries

https://sourceware.org/bugzilla/show_bug.cgi?id=30978 --- Comment #1 from Dominique Martinet --- Relevant part of the fedora-devel thread at the time, justifying there'd be interest in distros: https://www.mail-archive.com/devel@lists.fedoraproject.org/msg166474.html (sorry for double-update, to

Re: [PATCH 10/16] libdw: make dwarf_getalt thread-safe

Since it wasn't too complicated to do, I implemented a dwarf object lock (per struct dwarf lock) instead of having the static global lock. As per your suggestion, I placed the lock over the whole dwarf_getalt function, so now find_debug_altlink is called with the lock already acquired. In addition,

Re: [PATCH 09/16] src: Use eu-search in nm and findtextrel.

Thank you for pointing out that changes to these two files are not needed due to them being single threaded utilities. I reverted the changes and ran some tests. Works just fine with the original search.h, tsearch, and tfind. On Tue, Oct 10, 2023 at 4:26 PM Mark Wielaard wrote: > Hi Heather, > >

[Bug debuginfod/30978] New: debuginfod-client security: optionally(?) verify downloaded binaries

https://sourceware.org/bugzilla/show_bug.cgi?id=30978 Bug ID: 30978 Summary: debuginfod-client security: optionally(?) verify downloaded binaries Product: elfutils Version: unspecified Status: UNCONFIRMED Severi

Re: [PATCH 04/16] libelf: Fix deadlock in elf_cntl

You are right. I changed the code to just rely on if (__libelf_readall (elf) == NULL) and this seems to work just fine. On Tue, Oct 10, 2023 at 10:23 AM Mark Wielaard wrote: > Hi Heather, > > On Tue, 2023-10-10 at 15:42 +0200, Mark Wielaard wrote: > > From: Heather McIntyre > > > > * libe

Re: [PATCH 03/16] libelf: Fix deadlock in __libelf_readall

You are right that if elf->map_address != NULL then the acquired wrlock is not unlocked. The rwlock_unlock that was there initially was removed due to deadlocking when returning from inside the if statement, but this was not correct. However, adding ‘else rwlock_unlock (elf->lock)’ at the end of th

Re: [PATCH 02/16] libelf: Make elf_version thread-safe

John and I discussed that atomic_compare_exchange_strong could have been used here. I see that this has been pushed to the main branch, but I can make the change to the atomic operation if you think that is a better option. Best, Heather On Tue, Oct 10, 2023 at 9:00 AM Mark Wielaard wrote: > Hi

Re: [PATCH] Fix thread-safety for elfutils

Hi Heather, On Sat, 2023-10-14 at 13:29 -0500, Heather McIntyre wrote: > I have a quick query regarding how you'd prefer to handle these changes. > Would you like me to implement some of the recommended modifications and > commit them (if possible), or would you prefer that I simply leave > comm