linux-kernel - Re: [PATCH 2/4] perf report: Load PE files from debug cache only

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: <20210212211750.GL1398414@kernel.org>
Date:   Fri, 12 Feb 2021 18:17:50 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Nicholas Fraser <nfraser@...eweavers.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Ian Rogers <irogers@...gle.com>,
        "Frank Ch. Eigler" <fche@...hat.com>,
        Song Liu <songliubraving@...com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Kim Phillips <kim.phillips@....com>,
        Tommi Rantala <tommi.t.rantala@...ia.com>,
        Remi Bernon <rbernon@...eweavers.com>,
        linux-kernel@...r.kernel.org,
        Ulrich Czekalla <uczekalla@...eweavers.com>,
        Huw Davies <huw@...eweavers.com>
Subject: Re: [PATCH 2/4] perf report: Load PE files from debug cache only

Em Fri, Feb 12, 2021 at 11:34:24AM -0500, Nicholas Fraser escreveu:
> Sorry, I should have been more clear in the commit message. The use case
> you outlined still works even with this patch.

Ok, I'll clarify that in the commit log then.

- Arnaldo
 
> dso__load_bfd_symbols() is called in a loop from dso__load() for a variety
> of paths. These are generated by the various DSO_BINARY_TYPEs in the
> binary_type_symtab list at the top of util/symbol.c. In each case the
> debugfile passed to dso__load_bfd_symbols() is the path to try.
> 
> One of those iterations (the first one I believe) passes the original path
> as the debugfile. If the file still exists at the original path, this is
> the one that ends up being used in case the debugcache was deleted or the
> PE file doesn't have a build-id.
> 
> A later iteration (BUILD_ID_CACHE) passes debugfile as the file in the
> debugcache if it has a build-id. Even if the file was previously loaded at
> its original path, (if I understand correctly) this load will override it
> so the debugcache file ends up being used.
> 
> Nick
> 
> 
> On 2021-02-12 7:28 a.m., Arnaldo Carvalho de Melo wrote:
> > Em Wed, Feb 10, 2021 at 02:17:38PM -0500, Nicholas Fraser escreveu:
> >> dso__load_bfd_symbols() attempts to load a DSO at its original path,
> >> then closes it and loads the file in the debug cache. This is incorrect.
> >> It should ignore the original file and work with only the debug cache.
> >> The original file may have changed or may not even exist, for example if
> >> the debug cache has been transferred to another machine via "perf
> >> archive".
> >>
> >> This fix makes it only load the file in the debug cache.
> > 
> > Well this improves your current use case and only affects PE files, so I
> > am applying, but consider a slightly different workflow:
> > 
> >  1. perf record ./foo.exe
> >  2. perf report     # works, finds the file in the ~/.debug cache, as stored
> >                     # by 'perf record'
> >  3. rm -rf ~/.debug # I need more space
> >  4. perf report     # Fails, as it looks only in the ~/.debug cache, that
> >                     # was nuked
> > 
> > 
> > So at 4 it should look at the original pathname, and hope for the best.
> > 
> > All this is moot if we have something like a build-id in PE files,
> > where we can look in any order since we'll verify the unique ID to see
> > if it is the one we need, right?
> > 
> > - Arnaldo
> >  
> >> Signed-off-by: Nicholas Fraser <nfraser@...eweavers.com>
> >> ---
> >>  tools/perf/util/symbol.c | 8 +-------
> >>  1 file changed, 1 insertion(+), 7 deletions(-)
> >>
> >> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> >> index 64a039cbba1b..aa9ae875b995 100644
> >> --- a/tools/perf/util/symbol.c
> >> +++ b/tools/perf/util/symbol.c
> >> @@ -1569,7 +1569,7 @@ int dso__load_bfd_symbols(struct dso *dso, const char *debugfile)
> >>  	u_int i;
> >>  	u64 start, len;
> >>  
> >> -	abfd = bfd_openr(dso->long_name, NULL);
> >> +	abfd = bfd_openr(debugfile, NULL);
> >>  	if (!abfd)
> >>  		return -1;
> >>  
> >> @@ -1586,12 +1586,6 @@ int dso__load_bfd_symbols(struct dso *dso, const char *debugfile)
> >>  	if (section)
> >>  		dso->text_offset = section->vma - section->filepos;
> >>  
> >> -	bfd_close(abfd);
> >> -
> >> -	abfd = bfd_openr(debugfile, NULL);
> >> -	if (!abfd)
> >> -		return -1;
> >> -
> >>  	if (!bfd_check_format(abfd, bfd_object)) {
> >>  		pr_debug2("%s: cannot read %s bfd file.\n", __func__,
> >>  			  debugfile);
> >> -- 
> >> 2.30.0
> >>
> > 

-- 

- Arnaldo