linux-kernel - perf test "object code reading" occasionally fails

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 11 Dec 2014 15:22:49 +0100
From:	Jan Stancek <jstancek@...hat.com>
To:	linux-kernel@...r.kernel.org
CC:	acme@...hat.com, jolsa@...nel.org, dsahern@...il.com,
	cjashfor@...ux.vnet.ibm.com, dsahern@...il.com, fweisbec@...il.com,
	mingo@...nel.org, namhyung@...nel.org, paulus@...ba.org,
	a.p.zijlstra@...llo.nl, adrian.hunter@...el.com
Subject: perf test "object code reading" occasionally fails

Hi,

I see this testcase occasionally failing. After reproducing it with
verbose output and checking objdump output I found at least 3 scenarios
where data read from objdump output does not match:

1. same byte is repeated in objdump output
Note that byte at ffffffff815cf071 is in output twice

    ffffffff815cf06e <sysret_check+0x4b>:
    ffffffff815cf06e:       24 2f                   and    $0x2f,%al
    ffffffff815cf070:       00 0f                   add    %cl,(%rdi)

    ffffffff815cf071 <sysret_careful>:
    ffffffff815cf071:       0f ba e2 03             bt     $0x3,%edx
    ffffffff815cf075:       73 11                   jae

2. objdump output can span across multiple sections
For example in case of libcrc32c.ko and start_address=8 .text
sections ends at 6b, but test continues to read output from
.init.text:

Disassembly of section .text:
  0000000000000008 <crc32c+0x8>:
     8:	48 89 e5             	mov    %rsp,%rbp
     b:	53                   	push   %rbx
     c:	8b 01                	mov    (%rcx),%eax
  ...
    6b:	90                   	nop

  Disassembly of section .init.text:
  0000000000000008 <init_module+0x8>:
     8:	00 00                	add    %al,(%rax)
     a:	00 00                	add    %al,(%rax)
     c:	48 89 e5             	mov    %rsp,%rbp

3. gaps in output
For example, note that byte at ffffffff81670500 is missing:

ffffffff816704fe <sysret_check+0x4b>:
ffffffff816704fe:	7b 34                	jnp    ffffffff81670534 <sysret_signal+0x1c>
	...

ffffffff81670501 <sysret_careful>:
ffffffff81670501:	0f ba e2 03          	bt     $0x3,%edx
ffffffff81670505:	73 11                	jae    ffffffff81670518 <sysret_signal>

My idea to fix this (attached) was to change objdump output reading
from sequential to offset-based - to take into account offset of
each line. And if offset starts going backwards, stop reading.

Comments/other ideas are welcome.

Regards,
Jan

View attachment "perf_test23.patch" of type "text/x-patch" (4037 bytes)