linux-kernel - [PATCH 00/14] scripts/sorttable: Rewrite the accessing of the Elf data fields

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250105162211.971039541@goodmis.org>
Date: Sun, 05 Jan 2025 11:22:11 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org,
 linux-kbuild@...r.kernel.org,
 bpf <bpf@...r.kernel.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Peter Zijlstra <peterz@...radead.org>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Masahiro Yamada <masahiroy@...nel.org>,
 Nathan Chancellor <nathan@...nel.org>,
 Nicolas Schier <nicolas@...sle.eu>,
 Zheng Yejian <zhengyejian1@...wei.com>,
 Martin  Kelly <martin.kelly@...wdstrike.com>,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 Josh Poimboeuf <jpoimboe@...hat.com>
Subject: [PATCH 00/14] scripts/sorttable: Rewrite the accessing of the Elf data fields

While looking at getting rid of the place holder __ftrace_invalid_address___
from the available_filter_functions file[1], I noticed that the sorttable.[ch]
code could use a major clean up!

This series is that clean up of the scripts/sorttable.c code. The sorttable.c
was a copy from recordmcount.c which is very hard to maintain. That's because
it uses macro helpers and places the code in a header file sorttable.h to
handle both the 64 bit and 32 bit version of  the Elf structures. It also uses
_r()/r()/r2() wrappers around accessing the data which will read the 64 bit or
32 bit version of the data as well as handle endianess. If the wrong wrapper is
used, an invalid value will result, and this has been a cause for bugs in the
past. In fact the new ORC code doesn't even use it. That's fine because ORC is
only for 64 bit x86 which is the default parsing.

Instead of having a bunch of macros defined and then include the code
twice from a header, the Elf structures are each wrapped in a union.
The union holds the 64 bit and 32 bit version of the needed structure.
To access the values, helper function pointers are used instead of
defining a function. For example, instead of having:

  In sorttable.h:

     #undef Elf_Ehdr
     #undef Elf_Shdr

     #ifdef SORTTABLE_64
     # define Elf_Ehdr		Elf64_Ehdr
     # define Elf_Shdr		Elf64_Shdr
     [..]
     # define _r			r8
     #else
     # define Elf_Ehdr		Elf32_Ehdr
     # define Elf_Shdr		Elf32_Shdr
     [..]
     # define _r			r
     #endif

     [..]
     Elf_Shdr *s, *shdr = (Elf_Shdr *)((char *)ehdr + _r(&ehdr->e_shoff));

  In sorttable.c:

     #include "sorttable.h"
     #define SORTTABLE_64
     #include "sorttable.h"

Using the Unions we have just sorttable.c:

     typedef union {
	    Elf32_Ehdr	e32;
	    Elf64_Ehdr	e64;
     } Elf_Ehdr;

     typedef union {
	    Elf32_Shdr	e32;
	    Elf64_Shdr	e64;
     } Elf_Shdr;

     [..]

     static uint64_t ehdr64_shoff(Elf_Ehdr *ehdr)
     {
	    return r8(&ehdr->e64.e_shoff);
     }

     static uint64_t ehdr32_shoff(Elf_Ehdr *ehdr)
     {
	    return r(&ehdr->e32.e_shoff);
     }

     [..]
     static uint64_t (*ehdr_shoff)(Elf_Ehdr *ehdr);
     [..]

	    switch (ehdr->e32.e_ident[EI_CLASS]) {
	    case ELFCLASS32:
		    [..]
		    ehdr_shoff	= ehdr32_shoff;
		    [..]
	    case ELFCLASS65:
		    [..]
		    ehdr_shoff	= ehdr64_shoff;
		    [..]

     shdr_start = (Elf_Shdr *)((char *)ehdr + ehdr_shoff(ehdr));

The code may be a little more verbose, but the meat of the code is easier to
read, and the conversion functions live in the helper functions to make
it easier to have the fields read the proper way, and not worry how to
read the fields within the code that accesses them.

This makes the code less error prone and easier to maintain. This also
makes it easier to extend and update the sorttable code.

[1] https://lore.kernel.org/all/20250102232609.529842248@goodmis.org/

Steven Rostedt (14):
      scripts/sorttable: Remove unused macro defines
      scripts/sorttable: Remove unused write functions
      scripts/sorttable: Remove unneeded Elf_Rel
      scripts/sorttable: Have the ORC code use the _r() functions to read
      scripts/sorttable: Make compare_extable() into two functions
      scripts/sorttable: Convert Elf_Ehdr to union
      scripts/sorttable: Replace Elf_Shdr Macro with a union
      scripts/sorttable: Convert Elf_Sym MACRO over to a union
      scripts/sorttable: Add helper functions for Elf_Ehdr
      scripts/sorttable: Add helper functions for Elf_Shdr
      scripts/sorttable: Add helper functions for Elf_Sym
      scripts/sorttable: Use uint64_t for mcount sorting
      scripts/sorttable: Move code from sorttable.h into sorttable.c
      scripts/sorttable: Get start/stop_mcount_loc from ELF file directly

----
 scripts/sorttable.c | 674 +++++++++++++++++++++++++++++++++++++++++++++++-----
 scripts/sorttable.h | 497 --------------------------------------
 2 files changed, 620 insertions(+), 551 deletions(-)
 delete mode 100644 scripts/sorttable.h