linux-kernel - Re: [RFC PATCH 0/2] Add basic support for PE binary format

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]

Date:   Mon, 1 Jun 2020 12:01:34 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Rémi Bernon <rbernon@...eweavers.com>
Cc:     linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [RFC PATCH 0/2] Add basic support for PE binary format

Em Mon, Jun 01, 2020 at 01:19:13PM +0200, Rémi Bernon escreveu:
> Hi,
> 
> I'm currently trying to improve compatibility between Wine and perf, and
> I would like to have you opinion on this approach.

Interesting!
 
> The main problem is that Wine uses PE binary format for most of its code
> (and of course the Windows application it runs are also using PE binary
> format), and perf is currently unable to parse them to get the symbol
> table or even to find the debug file location from build_id or
> .gnu_debuglink section.

Unfortunate
 
> I know that there's the possibility to use a perfmap file to map address
> ranges to symbols, but it requires the runtime to generate it. And in
> this case the information is already there in the PE files, just not in
> a format that perf supports.

Right, IMHO the right approach is to abstract away these details and use
whatever PE has to offer.
 
> I also have some alternate ways to make it work, using perf-specific
> tweaks in Wine for instance. But I believe that having better support of
> PE binary format in perf could be generally useful, although for now
> Wine is the only use-case I know.

Agreed.
 
> This first starts using libbfd to parse the build_id and .gnu_debuglink
> section, to make sure perf gets the debug file location even if the code
> modules are in PE binary format.

Right, one thing I'd ask is for you to add to the tree a very simple PE
file, with debug info, a build-id, and then introduce a new 'perf test'
entry that uses the functions you're adding to read and check its
whatever the build-id is there, so that we keep testing this regularly,
please take a look at tools/perf/tests/ to see how to add a new test.
 
> Then, as Wine also generates debug files in PE or PDB format by default,
> it also tries to use libbfd to parse the symbol table from the debug
> file if libelf failed.
> 
> Of course, advanced features will still lack, but this makes it possible
> to have perf report symbols and source-level annotations for any Windows
> code running in Wine, assuming the modules aren't stripped.

Thanks for working on this, right now I'm doing the final touches for
this merge window, but surely I'll get back to this for 5.9, please
remind me if this falls thru the cracks,

- Arnaldo

> Cheers,
> 
> Rémi Bernon (2):
>   perf dso: Use libbfd to read build_id and .gnu_debuglink section
>   perf symbols: Try reading the symbol table with libbfd
> 
>  tools/perf/util/symbol-elf.c |  65 +++++++++++++++++-
>  tools/perf/util/symbol.c     | 124 +++++++++++++++++++++++++++++++++++
>  2 files changed, 186 insertions(+), 3 deletions(-)
> 
> -- 
> 2.26.1
> 

-- 

- Arnaldo