☝ Buildbot (Sourceware): elfutils - worker cancelled (main)
A cancelled build has been detected on builder elfutils-debian-amd64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#/builders/52/builds/316 Build state: worker cancelled Revision: (unknown) Worker: bb3 Build Reason: (unknown) Blamelist: Aaron Merey Steps: - 0: worker_preparation ( cancelled ) A cancelled build has been detected on builder elfutils-fedora-x86_64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#/builders/59/builds/317 Build state: worker cancelled Revision: (unknown) Worker: bb2-2 Build Reason: (unknown) Blamelist: Aaron Merey Steps: - 0: worker_preparation ( cancelled ) A cancelled build has been detected on builder elfutils-opensusetw-x86_64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#/builders/88/builds/281 Build state: worker cancelled Revision: (unknown) Worker: bbo2 Build Reason: (unknown) Blamelist: Aaron Merey Steps: - 0: worker_preparation ( cancelled ) A cancelled build has been detected on builder elfutils-opensuseleap-x86_64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#/builders/90/builds/282 Build state: worker cancelled Revision: (unknown) Worker: bb1-1 Build Reason: (unknown) Blamelist: Aaron Merey Steps: - 0: worker_preparation ( cancelled ) A cancelled build has been detected on builder elfutils-rawhide-x86_64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#/builders/140/builds/263 Build state: worker cancelled Revision: (unknown) Worker: bb1-2 Build Reason: (unknown) Blamelist: Aaron Merey Steps: - 0: worker_preparation ( cancelled )
[Bug debuginfod/31620] debuginfod should not require ssl support from libcurl
https://sourceware.org/bugzilla/show_bug.cgi?id=31620 --- Comment #6 from Frank Ch. Eigler --- Note that the "modern way" is not necessarily the desirable way. If the old way will keep working, I'd rather use that than a using a version-conditionalized query. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] libdw: dwarf_getsrcfiles should not imply dwarf_getsrclines
On Thu, Apr 11, 2024 at 5:55 AM Mark Wielaard wrote: > > All looks good BTW. Please do push (if possible with the above change). Thanks Mark, pushed as commit d4b0848be5f575ff9464fee12ce7be416e4fb392 Aaron
[Bug libdw/27405] libdw_get_srcfiles should not imply srclines
https://sourceware.org/bugzilla/show_bug.cgi?id=27405 Aaron Merey changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Aaron Merey --- Fixed in the following commit: commit d4b0848be5f575ff9464fee12ce7be416e4fb392 Author: Aaron Merey Date: Mon Mar 25 15:57:25 2024 -0400 libdw: dwarf_getsrcfiles should not imply dwarf_getsrclines dwarf_getsrcfiles causes line data to be read in addition to file data. This is wasteful for programs which only need file or directory names. Debuginfod server is one such example. Fix this by moving the srcfile reading in read_srclines into a separate function read_srcfiles. This change improves debuginfod server's max resident set size by up to 75% during rpm indexing. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [rfc] [patch] PR28204: debuginfod ima signature verification
Hi - > > IOW, without a "permissive" mode being available at all, we could not > > ask users to enable this new code at all for our own federated > > servers, nor even for fedora. That's because no server can guarantee > > the availability of signatures for all content they can serve. > > I don't understand why you say we cannot ask users to enable the ima > checking code. Isn't the goal to make sure that the user only gets > ima-signed/verified files for the distro they are debugging/analyzing > on? Especially if a server can also provide non-verifiable files, then > you would want to have strict checking to make sure. The goal of dealing with 100% verified files is nice in theory, but the question is what to do with the exceptions. We know there will be exceptions (when debugging older binaries, or when the server has a hickup, or when debugging other distro's binaries from a container, or ...). In the absence of a "permissive" type mode, those exceptions result in a failure. Curing those requires the user to turn off signature checking entirely and restart whatever servers/clients are affected. > [...] I think I simply don't understand what the thread model is > that ima:permissive guards against. In the absence of deliberately hostile servers that would strip X-DEBUGINFOD-FILE-SIGNATURE, this mode provides ima:enforcing level security for those servers & files that have verifiable info and ima:ignore level (non) security for those that don't. It's as if DEBUGINFOD_URLS="ima:enforcing HTTP:FOO ima:ignore HTTP:FOO" except that cannot work with the current client code (because of parallelism tie-breaking & dupe elimination). > It seems not to protect against the main thing you want to do ima > checking for. You only want debuginfod-client to provide files that > are signed and can be verified. No, I am not so absolutist with the goal. "Best effort" would be my default. If you wish to use only ima:enforcing, you'd be welcome to. > > > And you can implement a simpler error-detection mode that can work > > > in more cases (by using the executable .gnu_debuglink CRC) > > > > No, we already know that this is incapable of checking e.g. source > > files. And there is no separate CRC for executables vs. debuginfo > > files. And note that this provides zero protection in the same threat > > model above (as the CRC field could be MITM'd). > > Sure. I guess if you don't enforce ima checking you can just rely on > https. And it is kind of the point that this is similar to the threat > model that "permissive" guards against (random, bit flipping, > accidential replacement of files). [...] It is "similar" but strictly less protective. > > > [...] > > > One "big picture" question is whether this should be a per server URL > > > policy or something that is enabled/disabled for all server URLs? > > > That makes it less "flexible" but should simplify things a bit for the > > > user (and the server urls parsing). > > > > Blame some guy named Mark for getting Ryan to build that out last year. :-) > > > > https://sourceware.org/pipermail/elfutils-devel/2023q3/006299.html > > Sorry. I see back then I also didn't get use case for the "permissive" > policy. But yes, it might have been a mistake to suggest different > policies per URL/server. A single global policy setting would be even worse, without an available "permissive" setting. It would not be possible to handle exceptions without a reconfiguration/restart. - FChE
Re: [rfc] [patch] PR28204: debuginfod ima signature verification
Hi Frank, On Wed, Apr 10, 2024 at 05:01:36PM -0400, Frank Ch. Eigler wrote: > > > - to drop "permissive" mode > > > > We discussed a bit on irc about "wording". But I think it isn't really > > how it is worded, but that there is just different features. What is > > called "enforcing" is an authenticity scheme. While "permissive" is > > more like an (optional) error-detecting mode. IMHO it makes sense to > > simply separate those. > > For the record, on IRC, I presented these two additional arguments: > > > in the case of federated debuginfod servers, such as > debuginfod.elfutils.org, a user is stuck with "ignore" mode > operation, because not all upstream servers will have ima > signatures to pass. this sacrifices all possible assurance that > could come from the federated server relaying ima signatures from > those servers that have them > > even in non-federated cases such as fedoraproject.org, the ideal > case for "enforcing" mode as a default, it will fail the moment > the user happens to try to debug some pre-fedora-38 binary that > may be sitting on the system --- because those rpms just don't > have signatures available at all > > for both these scenarios, the original "permissive" mode would be > suitable > > > IOW, without a "permissive" mode being available at all, we could not > ask users to enable this new code at all for our own federated > servers, nor even for fedora. That's because no server can guarantee > the availability of signatures for all content they can serve. I don't understand why you say we cannot ask users to enable the ima checking code. Isn't the goal to make sure that the user only gets ima-signed/verified files for the distro they are debugging/analyzing on? Especially if a server can also provide non-verifiable files, then you would want to have strict checking to make sure. > > That way you don't have a authentication scheme that is easily > > defeated (when put in "permissive" mode). > > This "easily defeated" theory needs a threat model. It sounds like > you are thinking of > - an evil debuginfod instance that > - you trust enough to list in DEBUGINFOD_URLS > - but not enough to label it with "ima:enforcing" > - which may strip the X-DEBUGINFOD-FILE-SIGNATURE header" en route > then yeah, but sounds far-fetched rather than easy. I think I simply don't understand what the thread model is that ima:permissive guards against. It seems not to protect against the main thing you want to do ima checking for. You only want debuginfod-client to provide files that are signed and can be verified. > > And you can implement a simpler error-detection mode that can work > > in more cases (by using the executable .gnu_debuglink CRC) > > No, we already know that this is incapable of checking e.g. source > files. And there is no separate CRC for executables vs. debuginfo > files. And note that this provides zero protection in the same threat > model above (as the CRC field could be MITM'd). Sure. I guess if you don't enforce ima checking you can just rely on https. And it is kind of the point that this is similar to the threat model that "permissive" guards against (random, bit flipping, accidential replacement of files). Relying on https and CRC checking seems simpler to understand for that. But you are right that there isn't really anyhing for the main executables. For the source files you could check the lenght and time stamps (or the MD5 sums if added by the DWARF producer). > > [...] > > One "big picture" question is whether this should be a per server URL > > policy or something that is enabled/disabled for all server URLs? > > That makes it less "flexible" but should simplify things a bit for the > > user (and the server urls parsing). > > Blame some guy named Mark for getting Ryan to build that out last year. :-) > > https://sourceware.org/pipermail/elfutils-devel/2023q3/006299.html Sorry. I see back then I also didn't get use case for the "permissive" policy. But yes, it might have been a mistake to suggest different policies per URL/server. Cheers, Mark
Re: [PATCH] libdw: dwarf_getsrcfiles should not imply dwarf_getsrclines
Hi Aaron, On Wed, Apr 10, 2024 at 04:43:53PM -0400, Aaron Merey wrote: > > > - /* Pass the file data structure to the caller. */ > > > - if (filesp != NULL) > > > -*filesp = files; > > > + const char **newdirs = (void *) >info[nnewfiles]; > > > + const char **prevdirs = (void *) >info[nprevfiles]; > > > + > > > + /* Copy prevdirs to newdirs. */ > > > + for (size_t n = 0; n < ndirs; n++) > > > + newdirs[n] = prevdirs[n]; > > > > Again slightly off indentation. > > But I also don't fully follow the prevdirs/newdirs copying. > > Why is this? No newdirs are defined here, are there? > > Maybe I don't understand the data-structure used here. > > The directories are the same but we still need to copy them so that > dwarf_getsrcdirs can find newfiles' dir names. > > Dwarf_Files is an unusual structure since it doesn't contain a member > specifically for the array of dirnames. Instead they're stored at > the end of the Dwarf_Fileinfo array member. Aha. Thanks for explaining. Clearly I should not try to review code if I don't understand the underlying data structures. > > So testfile-define-file is actually testfile36.debug but with a new > > line program? How did you edit/insert that one? > > I used xxd to create a hexdump of testfile36.debug and modified the line > program by hand with a text editor. I converted the modified hexdump > back to a binary with xxd -r. > > I chose testfile36.debug because its .debug_line includes multiple > directory and file names. It also contains a single short line program > that was easy to replace with two DW_LNE_define_file opcodes without > corrupting things. Fun. Could you add a small description to tests/run-get-files.sh where testfile-define-file is use so future hackers know how the file was created? All looks good BTW. Please do push (if possible with the above change). Thanks, Mark
