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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ