linux-kernel - Re: [PATCH v2 01/19] tools: Add gendwarfksyms

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <80e7994d-f82e-4f2a-b233-d4f9d6900698@suse.com>
Date: Wed, 28 Aug 2024 14:31:05 +0200
From: Petr Pavlu <petr.pavlu@...e.com>
To: Sami Tolvanen <samitolvanen@...gle.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
 Luis Chamberlain <mcgrof@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Matthew Maurer <mmaurer@...gle.com>, Alex Gaynor <alex.gaynor@...il.com>,
 Wedson Almeida Filho <wedsonaf@...il.com>, Gary Guo <gary@...yguo.net>,
 Neal Gompa <neal@...pa.dev>, Hector Martin <marcan@...can.st>,
 Janne Grunau <j@...nau.net>, Asahi Linux <asahi@...ts.linux.dev>,
 linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-modules@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v2 01/19] tools: Add gendwarfksyms

On 8/26/24 20:47, Sami Tolvanen wrote:
> On Mon, Aug 26, 2024 at 10:42 AM Petr Pavlu <petr.pavlu@...e.com> wrote:
>> On 8/15/24 19:39, Sami Tolvanen wrote:
>>> [...]
>>> +int main(int argc, const char **argv)
>>> +{
>>> +     unsigned int n;
>>> +
>>> +     if (parse_options(argc, argv) < 0)
>>> +             return usage();
>>> +
>>> +     for (n = 0; n < object_count; n++) {
>>> +             Dwfl *dwfl;
>>> +             int fd;
>>> +
>>> +             fd = open(object_files[n], O_RDONLY);
>>> +             if (fd == -1) {
>>> +                     error("open failed for '%s': %s", object_files[n],
>>> +                           strerror(errno));
>>> +                     return -1;
>>> +             }
>>> +
>>> +             dwfl = dwfl_begin(&callbacks);
>>> +             if (!dwfl) {
>>> +                     error("dwfl_begin failed for '%s': %s", object_files[n],
>>> +                           dwarf_errmsg(-1));
>>> +                     return -1;
>>> +             }
>>> +
>>> +             if (!dwfl_report_offline(dwfl, object_files[n], object_files[n],
>>> +                                      fd)) {
>>> +                     error("dwfl_report_offline failed for '%s': %s",
>>> +                           object_files[n], dwarf_errmsg(-1));
>>> +                     return -1;
>>> +             }
>>> +
>>> +             dwfl_report_end(dwfl, NULL, NULL);
>>> +
>>> +             if (dwfl_getmodules(dwfl, &process_modules, NULL, 0)) {
>>> +                     error("dwfl_getmodules failed for '%s'",
>>> +                           object_files[n]);
>>> +                     return -1;
>>> +             }
>>
>> I see that libdwfl has also directly function dwfl_nextcu(). Would it
>> make sense to use it to simplify the code?
> 
> How do you propose using the function? This loop goes through multiple
> input files, should we need them, and we iterate through all the CUs
> in process_modules.

I was thinking it could be possible to replace the code to traverse
modules and their their CUs, that is functions process_modules() and
process_module(), with dwfl_nextcu(). However, I now notice that more
work is added in subsequent patches to process_modules() so this
wouldn't quite work.

I would then only suggest to change some function names in the current
code. Function process_modules() is a callback to process a single
module and so it would be better to name it process_module(). The
present function process_module() actually processes a compilation unit
DIE so I would rename it to something like process_cu().

On 8/15/24 19:39, Sami Tolvanen wrote:
> +int process_module(Dwfl_Module *mod, Dwarf *dbg, Dwarf_Die *cudie)
> +{
> +	struct state state = { .mod = mod, .dbg = dbg };
> +
> +	return check(process_die_container(
> +		&state, cudie, process_exported_symbols, match_all));
> +}

Mostly a minor suggestion too.. Looking at the entire series, state.mod
ends up unused and state.dbg is only used in process_cached() where it
could be possibly replaced by doing dwarf_cu_getdwarf(die->cu)?

Removing these two members from the state struct would then allow to
instantiate a new state in process_exported_symbols() for each processed
symbol. That looks cleaner than changing state.sym and resetting some
parts of the state as the function walks over the exported symbols.

-- 
Thanks,
Petr