ww07 - Agenda


Gabriele Paoloni
 

Hi All

Today we'll continue the investigation on the Telltale Safety App address space as per KSR_002 doc

Thanks
Gab


Igor Stoppa
 

Hello,
followup wrt identification of symbols used by an empty program, since it was pulling in libc.

The program "test.c":

int main()
{
        while (1); /* Infinite loop */
        return 0;
}

gcc test.c -o test

My initial thought of using prelink did not work, because apparently prelink has been bitrotting at least since 2017.
Admittedly, also yours truly had not used it since 2010. For some reason, it's still around, though.

Anyways, there are various other ways to obtain the desired information.
One of them is to use nm:

nm -D test
                 w __cxa_finalize@....5
                 w __gmon_start__
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 U __libc_start_main@...

From man nm:
[...]
           "U" The symbol is undefined.
[...]
           "W"                                                                                                                                                                                    
           "w" The symbol is a weak symbol that has not been specifically tagged as a weak object symbol.  When a weak defined symbol is linked with a normal defined symbol, the normal          
               defined symbol is used with no error.  When a weak undefined symbol is linked and the symbol is not defined, the value of the symbol is determined in a system-specific manner     
               without error.  On some systems, uppercase indicates that a default value has been specified.                                                                                      
[...]

Those weak housekeeping symbols seem to be the reason why libc is being pulled in.

--
igor


Gabriele Paoloni
 

Hi Igor

On Mon, Feb 21, 2022 at 9:00 AM Igor Stoppa via lists.elisa.tech <istoppa=nvidia.com@...> wrote:
Hello,
followup wrt identification of symbols used by an empty program, since it was pulling in libc.

The program "test.c":

int main()
{
        while (1); /* Infinite loop */
        return 0;
}

gcc test.c -o test

My initial thought of using prelink did not work, because apparently prelink has been bitrotting at least since 2017.
Admittedly, also yours truly had not used it since 2010. For some reason, it's still around, though.

Anyways, there are various other ways to obtain the desired information.
One of them is to use nm:

nm -D test
                 w __cxa_finalize@....5
                 w __gmon_start__
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 U __libc_start_main@...

From man nm:
[...]
           "U" The symbol is undefined.
[...]
           "W"                                                                                                                                                                                    
           "w" The symbol is a weak symbol that has not been specifically tagged as a weak object symbol.  When a weak defined symbol is linked with a normal defined symbol, the normal          
               defined symbol is used with no error.  When a weak undefined symbol is linked and the symbol is not defined, the value of the symbol is determined in a system-specific manner     
               without error.  On some systems, uppercase indicates that a default value has been specified.                                                                                      
[...]

Those weak housekeeping symbols seem to be the reason why libc is being pulled in.

Thanks a lot for your analysis. Interestingly I have now compiled the dummy program using
"gcc -nostdlib test1.c"
The compilation succeeded and I ran the program; the resulting maps is:
[gpaoloni@fedora test]$ cat /proc/17846/maps
00400000-00401000 r--p 00000000 00:21 9889982                            /home/gpaoloni/test/a.out
00401000-00402000 r-xp 00001000 00:21 9889982                            /home/gpaoloni/test/a.out
00402000-00403000 r--p 00002000 00:21 9889982                            /home/gpaoloni/test/a.out
7ffde680e000-7ffde682f000 rw-p 00000000 00:00 0                          [stack]
7ffde68da000-7ffde68de000 r--p 00000000 00:00 0                          [vvar]
7ffde68de000-7ffde68e0000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]


Now the mappings, as expected, do not show any glibc one.
We can see a read only area where we have the code and the exception handling frame. As next steps I will try to understand
where and how these mappings are maintained within the Kernel.

Thanks
Gab


--
igor


Igor Stoppa
 

Hi,

> As next steps I will try to understand where and how these mappings are maintained within the Kernel.

struct task_struct contains

struct mm_struct *mm

and

struct mm_struct *active_mm

which are the memory maps used by a process (and its threads)

--
igor