[PATCH 0/1] Fix interpretation of ARM32 CFI

[PATCH 0/1] Fix interpretation of ARM32 CFI

[Giuliano Procida]

Hi.

This patch ensures correct symbol address for ARM32 shared libraries
that have been complied with CFI.

I have no idea what the implications are for PPC64. It's also possible
the fix-up code would better belong in some kind of helper.

Feedback welcome as always!

Regards,
Giuliano.

Giuliano Procida (1):
  symtab reader: fix up alternative addresses

 src/abg-symtab-reader.cc | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

-- 
2.34.1.575.g55b058a8bb-goog

[PATCH 1/1] symtab reader: fix up alternative addresses

[Giuliano Procida]

CFI symbols need special interpretation and this work is performed by
the add_alternative_address_lookups method.

Some symbol addresses need to be "tweaked" to be correctly interpreted
and this must also happen in add_alternative_address_lookups.

In particular, this commit fixes ARM32 CFI symbol interpretation.

	* src/abg-symtab-reader.cc
	(symtab::add_alternative_address_lookups): Tweak function
	addresses in the same manner as done in symtab::load_.

Signed-off-by: Giuliano Procida <gprocida@google.com>
---
 src/abg-symtab-reader.cc | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/src/abg-symtab-reader.cc b/src/abg-symtab-reader.cc
index 0f4d0b65..04e8b23c 100644
--- a/src/abg-symtab-reader.cc
+++ b/src/abg-symtab-reader.cc
@@ -351,6 +351,7 @@ symtab::load_(Elf*	       elf_handle,
 	      elf_helpers::maybe_adjust_et_rel_sym_addr_to_abs_addr(elf_handle,
 								    sym);
 
+	  // See also symtab::add_alternative_address_lookups.
 	  if (symbol_sptr->is_function())
 	    {
 	      if (is_arm32)
@@ -581,6 +582,9 @@ symtab::update_function_entry_address_symbol_map(
 void
 symtab::add_alternative_address_lookups(Elf* elf_handle)
 {
+  const bool is_arm32 = elf_helpers::architecture_is_arm32(elf_handle);
+  const bool is_ppc64 = elf_helpers::architecture_is_ppc64(elf_handle);
+
   Elf_Scn* symtab_section = elf_helpers::find_symtab_section(elf_handle);
   if (!symtab_section)
     return;
@@ -634,6 +638,19 @@ symtab::add_alternative_address_lookups(Elf* elf_handle)
 		  elf_helpers::maybe_adjust_et_rel_sym_addr_to_abs_addr(
 		      elf_handle, sym);
 
+	      // See also symtab::load_.
+	      if (symbol_sptr->is_function())
+		{
+		  if (is_arm32)
+		    // Clear bit zero of ARM32 addresses as per "ELF for the Arm
+		    // Architecture" section 5.5.3.
+		    // https://static.docs.arm.com/ihi0044/g/aaelf32.pdf
+		    symbol_value &= ~1;
+		  else if (is_ppc64)
+		    update_function_entry_address_symbol_map(elf_handle, sym,
+							     symbol_sptr);
+		}
+
 	      const auto result =
 		  addr_symbol_map_.emplace(symbol_value, symbol_sptr);
 	      ABG_ASSERT(result.second);
-- 
2.34.1.575.g55b058a8bb-goog

Re: [PATCH 0/1] Fix interpretation of ARM32 CFI

[Mark Wielaard]

Hi Giuliano,

On Tue, 2022-01-11 at 16:34 +0000, Giuliano Procida wrote:
> This patch ensures correct symbol address for ARM32 shared libraries
> that have been complied with CFI.
> 
> I have no idea what the implications are for PPC64. It's also
> possible
> the fix-up code would better belong in some kind of helper.
> 
> Feedback welcome as always!

I am not familiar enough with the libabigail code to say this is the
correct place/way to do these fixups. But the need for fixups
themselves seem correct.

For ARM32 bit zero encodes whether an function address is THUMB or ARM,
so to get the "real" function address you have to mask bit zero.

For PPC64 (and ppc32 btw) a function symbol value will point to the
function descriptor (OPD entry) (except for .symbols) the function
descriptor will point to the actual symbol address.

elfutils has a somewhat complicated function that tries to provide you
the actual symbol value and the associated address for that symbol. But
I don't think that fits in the code here:

/* Fetch one entry from the module's symbol table and the associated
   address value.  On errors, returns NULL.  If successful, fills in
   *SYM, *ADDR and returns the string for st_name.  This works like
   gelf_getsym.  *ADDR is set to the st_value adjusted to an absolute
   value based on the module's location, when the symbol is in an
   SHF_ALLOC section.  For non-ET_REL files, if the arch uses function
   descriptors, and the st_value points to one, *ADDR will be resolved
   to the actual function entry address.  The SYM->ST_VALUE itself
   isn't adjusted in any way.  Fills in ELFP, if not NULL, with the
   ELF file the symbol originally came from.  Note that symbols can
   come from either the main, debug or auxiliary ELF symbol file
   (either dynsym or symtab).  If SHNDXP is non-null, it's set with
   the section index (whether from st_shndx or extended index table);
   in case of a symbol in a non-allocated section, *SHNDXP is instead
   set to -1.  Fills in BIAS, if not NULL, with the difference between
   addresses within the loaded module and those in symbol table of the
   ELF file.  Note that the address associated with the symbol might
   be in a different section than the returned symbol.  The section in
   the main elf file in which returned ADDR falls can be found with
   dwfl_module_address_section.  */
extern const char *dwfl_module_getsym_info (Dwfl_Module *mod, int ndx,
                                            GElf_Sym *sym, GElf_Addr *addr,
                                            GElf_Word *shndxp,
                                            Elf **elfp, Dwarf_Addr *bias)
  __nonnull_attribute__ (3, 4);

Cheers,

Mark