[Bug translator/4886] New: stap should validate debuginfo files

[Bug translator/4886] New: stap should validate debuginfo files

[mmlnx at us dot ibm dot com]

As far as I can tell, stap relies solely on file/directory names to determine
which debuginfo files to use.  It does not validate that, upon finding a match,
the debuginfo file is actually valid for the running kernel.  I confirmed this
by renaming an invalid vmlinux with the name stap expected to find for the
running kernel, then running a script.  I saw no errors up through compiling the
module, but once the module loaded the system crashed.

Stap should do some level of validation of the debuginfo files it uses, perhaps
by comparing the dwarf addresses to the addresses in /proc/kallsyms.  If they
don't match something's wrong.  It may be sufficient to check a small set of
well-known symbols rather than validating every address referenced in the script.

-- 
           Summary: stap should validate debuginfo files
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mmlnx at us dot ibm dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-08-02 21:06 -------
(In reply to comment #0)
> As far as I can tell, stap relies solely on file/directory names to determine
> which debuginfo files to use.  It does not validate that, upon finding a match,
> the debuginfo file is actually valid for the running kernel. 

It does a very limited amount of such checking at translation time.  It
could do more.  We could e.g. extract init/version.c's init_uts_ns from the
object file, and compare it to the module init-time utsname() results.

Once the new build-id code is pervasive, it can be used as a stronger
match check too.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-08-09 15:55 -------
idea from call: assert "uname -v" match with value pulled out of debuginfo file.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-08-15 19:25 -------
Just a note: this likely wouldn't help the kernel case (where vmlinux is
unstripped), but for modules, it may help to change src/tapsets.cxx's
initialization of debuginfo_path to have a "+" instead of "-" at the front.
That activates (weakish) CRC checking of the debuginfo against the stripped
base file. 

Just in case, would you mind testing that change with your wrong-vmlinux
scenario?

diff -r1.205 tapsets.cxx
668c668
<     static char debuginfo_path_arr[] = "-:.debug:/usr/lib/debug";
---
>     static char debuginfo_path_arr[] = "+:.debug:/usr/lib/debug";


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[mmlnx at us dot ibm dot com]

------- Additional Comments From mmlnx at us dot ibm dot com  2007-08-19 05:17 -------
I tried your CRC suggestion with the wrong-vmlinux and it didn't help.  Still
didn't generate any errors until the module loaded and crashed the system.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[roland at gnu dot org]

------- Additional Comments From roland at gnu dot org  2007-08-19 20:11 -------
The CRC check serves only to validate that a separate debuginfo file matches a
corresponding stripped file.  In the case of vmlinux, we do not normally have
any stripped file on hand, only the unstripped file complete with debuginfo. 
Hence, there are no two things here to compare.  

In contrast, validation based on build IDs has the same bits to compare in at
least two places (and maybe three), the additional one being the running kernel
itself.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-09-04 03:24 -------
*** Bug 2638 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2007-09-19 05:57 -------
(In reply to comment #2)
> idea from call: assert "uname -v" match with value pulled out of debuginfo file.
> 

I tried this way.

[root@dhcp-beijing-cdc-10-182-121-14 wjhuang]# uname -v
#4 SMP Tue Sep 11 05:20:10 EDT 2007

[root@dhcp-beijing-cdc-10-182-121-14 wjhuang]# strings
/boot/vmlinux-2.6.22.6.debug |grep "Linux version"
Linux version 2.6.22.6 (root@dhcp-beijing-cdc-10-182-121-14.cn.oracle.com) (gcc
version 4.1.1 20070105 (Red Hat 4.1.1-52)) #4 SMP Tue Sep 11 05:20:10 EDT 2007

There is something matched. But it depends on uname and strings tools.



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2007-09-19 09:30 -------
> There is something matched. But it depends on uname and strings tools.

To avoid utilizing strings tool directedly, a replacement is eu-strings included
in elfutils. Since elfutils source is needed in building systemtap, it is easy
to extract code to implement this function.






-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-09-19 11:25 -------
(In reply to comment 
> [root@dhcp-beijing-cdc-10-182-121-14 wjhuang]# uname -v
> #4 SMP Tue Sep 11 05:20:10 EDT 2007
> 
> [root@dhcp-beijing-cdc-10-182-121-14 wjhuang]# strings
> /boot/vmlinux-2.6.22.6.debug |grep "Linux version"
> Linux version 2.6.22.6 (root@dhcp-beijing-cdc-10-182-121-14.cn.oracle.com) (gcc

That's a good hack, but the host uname -v does not enter into it.  We need to
match the translate-time vmlinux/vmlinuz codes with the one at the run time
(probe module load).


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2007-09-20 03:08 -------
Created an attachment (id=2013)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2013&action=view)
Test program for uname

Sorry, couldn't catch you. But I found `uname -v` is not difficult to reach. In
fact, there is such function provided in gcc lib. 

extern int uname (struct utsname *__name) __THROW;

I wrote a simple program to test it and found many info printed.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-09-20 17:19 -------
> Sorry, couldn't catch you. But I found `uname -v` is not difficult to reach.

My point is that it does not matter what "uname -v" says on the machine where
stap is being run.  Think about cross-compilation as the normal mode.  What we
need to assert is that the vmlinux debug image's embedded uname-v matches the
uname-v at probe execution time.  The hosts's uname-v value doesn't matter.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2007-09-21 07:41 -------
> What we  need to assert is that the vmlinux debug image's embedded uname-v
matches the uname-v at probe execution time.

How about this way:
   1. stap incorporates uname -v embedded in vmlinux to module after compilation
   2. staprun checks the stored info in module matched the running kernel before
loading it into kernel.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-10-16 18:23 -------
http://sourceware.org/ml/systemtap/2007-q4/msg00163.html

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-05-20 19:30 -------
*** Bug 6534 has been marked as a duplicate of this bug. ***

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files with build-id

[fche at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|stap should validate        |stap should validate
                   |debuginfo files             |debuginfo files with build-
                   |                            |id


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4886] stap should validate debuginfo files with build-id

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-10-10 20:25 -------
Wenji's code is in the tree.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=4886

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.