Hi Denys,
Great -- it sounds like the list has responded positively to the idea so far. I am not
subscribed to lmkl but I will plan to join if you think it would support adoption of your
patch.
I'll be watching the list, but please feel free to contact me about the newer version
of your patch or anything else related to this effort in the meantime.
Thanks,
Jon
-----Original Message-----
From: Denys Vlasenko [mailto:dvlasenk@redhat.com]
Sent: Thursday, June 14, 2012 7:59 AM
To: crash-catcher(a)lists.fedorahosted.org
Cc: Jonathan M. Foote; Jan Kratochvil; Josh Bressers; Steve Grubb (sgrubb(a)redhat.com);
cert(a)cert.org
Subject: Re: CERT Triage Tools 1.0 (INFO#208126) (re-send)
On 06/05/2012 02:47 PM, Jonathan M. Foote wrote:
Denys,
I have released an updated version of the CERT Triage Tools that
includes the workaround described in the previous message along with
new test cases that clear up some licensing issues that were
preventing the Tools from being packaged with Fedora. It can be found
here:
http://www.cert.org/download/triage/
Outside of this release, I have also done some preliminary
investigation into adding proper support for core files to the tools.
I was able to work around the si_addr issue (with degraded
performance, as discussed below), but I ran into another issue. I am
unaware of a GDB interface that allows the tool to access the full
process address space mapping info (along the lines of "info proc map"
in a live session). The tool can call "maint info sections,"
which I believe I can use to determine what addresses and mapped and
perhaps their permissions, but the original mapped shared object names
are absent. I plan to do further investigation here.
Yes, as of today Linux core dumps don't save this information.
But the good news, we can try to fix it :)
I sent a patch to make Linux kernel include mapped file info into core dumps:
https://lkml.org/lkml/2012/3/31/184
I can resend a newer version of this patch, if you are willing to join the lkml discussion
and lobby for this patch to be accepted. (Are you subscribed to lkml?)
We can also propose a similar patch to address si_addr problem.
If the shared object names are not available, again, it may be
possible to work around this lack of info and degrade the performance
of the tool further, but I wanted to ask -- would it be plausible to
integrate the CERT Triage Tools with ABRT in a manner where the
'exploitable' plugin could run in a GDB session with a live target?
Adding proper support for core files to the CERT Triage Tools is still
possible, but it seems like ABRT might get more mileage from the
'exploitable' plugin if it can operate on a live target.
--
vda