linux-kernel - Re: [PATCH 2/2] perf/test: Fix perf test 89 on x86

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: <f5e69102-ed17-1f2d-3a09-3c7968b611ff@linux.ibm.com>
Date:   Wed, 14 Dec 2022 11:40:32 +0100
From:   Thomas Richter <tmricht@...ux.ibm.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        hca@...ux.ibm.com, gor@...ux.ibm.com, sumanthk@...ux.ibm.com,
        svens@...ux.ibm.com
Subject: Re: [PATCH 2/2] perf/test: Fix perf test 89 on x86

On 12/13/22 15:46, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 13, 2022 at 11:57:29AM +0100, Thomas Richter escreveu:
>> perf test '89: probe libc's inet_pton & backtrace it with ping'
>> fails on x86. Debugging revealed a changed stack trace for the
>> ping command using probes:
>>
>> ping 35729 [002]  8006.365063: probe_libc:inet_pton: (3ff9603e7c0)
>>                   12be50 __GI___inet_pton+0x0 (/usr/lib64/libc.so.6)
>>                   4fca main+0x139b (/usr/bin/ping)
>>
>> The line getaddrinfo.... in the call stack is gone.
>> It was introduced with glibc version 2.36.8 released
>> with Fedora 37.
>>
>> Output before on x86
>>  # ./perf test 89
>>  89: probe libc's inet_pton & backtrace it with ping   : FAILED!
>>  #
>>
>> Output after on x86:
>>  # ./perf test 89
>>  89: probe libc's inet_pton & backtrace it with ping   : Ok
>>  #
> 
> Not having at the current state of that script, that $expected may be a
> subset of the actual backtrace, i.e. will this continue working with
> the systems where that getaddrinfo line appear?
> 
> - Arnaldo
>  

No, that is not the case.
Taking this into account requires a larger rework of the call stack
checking. Not just simple line by line matching which is done now.
It also raises the question of how far to go back
in glibc history. Different versions of glibc have different call stacks.

I will rethink this...
-- 
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294