Re: [PATCH] RFC: come up with startswith function.

2021-04-21 Thread Martin Liška
On 4/20/21 1:43 PM, Mark Wielaard wrote:
> Hi Martin,
> 
> On Mon, 2021-04-19 at 15:18 +0200, Martin Liška wrote:
>> I made similar changes to binutils some time ago and I would like to
>> come up with the same function for elfutils. Note that current
>> construct
>> is quite error prone, I found for instance these 2 bad usages:
>>
>> diff --git a/libdwfl/relocate.c b/libdwfl/relocate.c
>> index 88b5211d..b6de3510 100644
>> --- a/libdwfl/relocate.c
>> +++ b/libdwfl/relocate.c
>> @@ -518,7 +518,7 @@ relocate_section (Dwfl_Module *mod, Elf
>> *relocated, const GElf_Ehdr *ehdr,
>> Nothing to do here.  */
>>  return DWFL_E_NOERROR;
>>  
>> -  if (strncmp (tname, ".zdebug", strlen ("zdebug")) == 0)
>> +  if (strncmp (tname, ".zdebug", strlen (".zdebug")) == 0)
>>  elf_compress_gnu (tscn, 0, 0);
>>  
>>if ((tshdr->sh_flags & SHF_COMPRESSED) != 0)
>> @@ -539,7 +539,7 @@ relocate_section (Dwfl_Module *mod, Elf
>> *relocated, const GElf_Ehdr *ehdr,
>>if (sname == NULL)
>>  return DWFL_E_LIBELF;
>>  
>> -  if (strncmp (sname, ".zdebug", strlen ("zdebug")) == 0)
>> +  if (strncmp (sname, ".zdebug", strlen (".zdebug")) == 0)
>>  elf_compress_gnu (scn, 0, 0);
>>  
>>if ((shdr->sh_flags & SHF_COMPRESSED) != 0)
> 
> Urgh. Thanks for finding this!
> 
>> I'm not convinced about function declaration in system.h. Is it a
>> proper location?
> 
> Yes, I think it is.
> 
>> And the function is not used in debuginfod/debuginfod-client.c and
>> debuginfod/debuginfod.cxx.
>> I would need another decl for these, am I right?
> 
> I think they both can simply include system.h (might want to double
> check the -I search path in debuginfod/Makefile.am) because system.h
> should be stand-alone, you don't need to link to anything else.

All right, there was a different problem I had:

In file included from ../lib/system.h:39,

 from debuginfod.cxx:40:

../lib/system.h: In function ‘ssize_t write_retry(int, const void*, size_t)’:

../lib/system.h:135:56: error: pointer of type ‘void *’ used in arithmetic 
[-Werror=pointer-arith]

  135 |   ssize_t ret = TEMP_FAILURE_RETRY (write (fd, buf + recvd, len - 
recvd));

  |^~~


I fixed that in the attached patch.

> 
> Maybe for debuginfod.cxx there is a better C++ way for strings. But if
> it uses C strings, then it could also simply include system.h.

Apparently, it's not using strncmp with a string objects.

Is the patch ready to be installed?
Thanks,
Martin

> 
> Thanks,
> 
> Mark
> 

>From 4be9bec67e52ee6f011197951bb8810713be3eae Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 19 Apr 2021 14:33:36 +0200
Subject: [PATCH] Come up with startswith function.

backends/ChangeLog:

	* aarch64_symbol.c (aarch64_data_marker_symbol): Use startswith.
	* arm_symbol.c (arm_data_marker_symbol): Likewise.

debuginfod/ChangeLog:

	* debuginfod-client.c (debuginfod_query_server): Use startswith.
	(debuginfod_add_http_header): Likewise.
	* debuginfod.cxx: Likewise.

lib/ChangeLog:

	* system.h (startswith): New function.
	(pwrite_retry): Cast to char *.
	(write_retry): Likewise.
	(pread_retry): Likewise.

libasm/ChangeLog:

	* libasmP.h (asm_emit_symbol_p): Use startswith.

libdw/ChangeLog:

	* dwarf_begin_elf.c (check_section): Use startswith.

libdwfl/ChangeLog:

	* dwfl_frame.c (dwfl_attach_state): Use startswith.
	* dwfl_module_getdwarf.c (find_symtab): Likewise.
	* linux-kernel-modules.c: Likewise.
	* linux-pid-attach.c (linux_proc_pid_is_stopped): Likewise.
	(dwfl_linux_proc_attach): Likewise.
	* relocate.c (resolve_symbol): Likewise.
	(relocate_section): Likewise.

libebl/ChangeLog:

	* eblobjnotetypename.c (ebl_object_note_type_name): Use startswith.
	* eblopenbackend.c (default_debugscn_p): Likewise.

src/ChangeLog:

	* elfclassify.c (run_classify): Use startswith.
	* elfcompress.c (process_file): Likewise.
	* nm.c (show_symbols_sysv): Likewise.
	* readelf.c (print_debug): Likewise.
	(handle_notes_data): Likewise.
	(dump_data_section): Likewise.
	(print_string_section): Likewise.
	* strip.c (remove_debug_relocations): Likewise.

tests/ChangeLog:

	* dwelf_elf_e_machine_string.c (main): Use startswith.
	* dwelfgnucompressed.c (main): Likewise.
	* elfgetchdr.c (main): Likewise.
	* elfputzdata.c (main): Likewise.
	* vdsosyms.c (module_callback): Likewise.
---
 backends/aarch64_symbol.c  |  4 +++-
 backends/arm_symbol.c  |  4 +++-
 debuginfod/debuginfod-client.c |  4 ++--
 debuginfod/debuginfod.cxx  |  9 +
 lib/system.h   | 15 ---
 libasm/libasmP.h   |  2 +-
 libdw/dwarf_begin_elf.c|  4 +++-
 libdwfl/dwfl_frame.c   |  4 +++-
 libdwfl/dwfl_module_getdwarf.c |  4 ++--
 libdwfl/linux-kernel-modules.c |  4 ++--
 libdwfl/linux-pid-attach.c |  6 --
 libdwfl/relocate.c |  8 +---
 libebl/eblobjnotetypename.c|  5 +++--
 libebl/e

[Bug debuginfod/27758] security idea: DEBUGINFOD_VERIFY mode

2021-04-21 Thread fweimer at redhat dot com via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27758

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #4 from Florian Weimer  ---
And it should be possible to use the Content-Length header to verify that the
data does not have an excessive size (something that is not possible with just
the hash itself).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/27758] security idea: DEBUGINFOD_VERIFY mode

2021-04-21 Thread fche at redhat dot com via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27758

--- Comment #5 from Frank Ch. Eigler  ---
(In reply to Vitaly Chikunov from comment #3)
> Instead of `X-Debuginfod-Hash` you can use `ETag` where you can put anything
> including sha256 (can be prescribed in webapi description), then GET request
> with `If-None-Match` + tag value (which is a hash) will return just 304 if
> the hash is not changed. So HEAD request is not needed too.

That's a good idea, except in the case of an older [current] debuginfod that
doesn't understand If-None-Match, and would just resend the entire content
every time.  But at least it's not a security problem, just a performance one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.