| 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
| ||
|
Date: Tue, 3 Jul 2007 15:16:05 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 06/10] Immediate Value - i386 Optimization
* H. Peter Anvin (hpa@...or.com) wrote:
> What is not clear to me is the exact code that is generated by these
> macros. Nor can I find it anywhere in the documentation.
>
> Could you please describe this in some detail? In particular, it seems
> that the uses of these are largely as branch targets, where the extra
> indirection over modifying the jump target directly seems wasted.
>
Hi Peter,
I understand your concern. If you find a way to let the code be compiled
by gcc, put at the end of the functions (never being a branch target)
and then, dynamically, get the address of the branch instruction and
patch it, all that in cooperation with gcc, I would be glad to hear from
it. What I found is that gcc lets us do anything that touches
variables/registers in an inline assembly, but does not permit to place
branch instructions ourselves; it does not expect the execution flow to
be changed in inline asms.
Here is an objdump of the interesting bits on an immediate value placed
in scheddule (inline schedule_debug).
00000000 <schedule>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 57 push %edi
4: 56 push %esi
5: 53 push %ebx
6: 83 ec 40 sub $0x40,%esp
9: b8 01 00 00 00 mov $0x1,%eax
e: e8 fc ff ff ff call f <schedule+0xf>
13: e8 fc ff ff ff call 14 <schedule+0x14>
18: 89 45 dc mov %eax,0xffffffdc(%ebp)
1b: b8 00 00 00 00 mov $0x0,%eax
20: 8b 4d dc mov 0xffffffdc(%ebp),%ecx
23: 8b 14 8d 00 00 00 00 mov 0x0(,%ecx,4),%edx
2a: 01 d0 add %edx,%eax
2c: 89 45 d0 mov %eax,0xffffffd0(%ebp)
2f: b8 00 00 00 00 mov $0x0,%eax
34: c7 44 02 04 01 00 00 movl $0x1,0x4(%edx,%eax,1)
3b: 00
3c: 8b 5d d0 mov 0xffffffd0(%ebp),%ebx
3f: 8b 9b f0 03 00 00 mov 0x3f0(%ebx),%ebx
45: 89 5d c8 mov %ebx,0xffffffc8(%ebp)
48: 81 c3 94 01 00 00 add $0x194,%ebx
4e: 89 5d cc mov %ebx,0xffffffcc(%ebp)
51: 8b 45 c8 mov 0xffffffc8(%ebp),%eax
54: 8b 40 14 mov 0x14(%eax),%eax
57: 85 c0 test %eax,%eax
59: 0f 89 30 03 00 00 jns 38f <schedule+0x38f>
5f: 89 e0 mov %esp,%eax
61: 25 00 e0 ff ff and $0xffffe000,%eax
66: 8b 40 14 mov 0x14(%eax),%eax
69: 25 ff ff ff ef and $0xefffffff,%eax
6e: 83 e8 01 sub $0x1,%eax
71: 0f 85 fb 02 00 00 jne 372 <schedule+0x372>
<branch site>
77: b8 00 00 00 00 mov $0x0,%eax
7c: 85 c0 test %eax,%eax
7e: 0f 85 16 03 00 00 jne 39a <schedule+0x39a>
here, we just loaded 0 in eax (movl used to make sure we populate the
whole register so we do not stall the pipeline)a
When we activate the site,
line 77 becomes: b8 01 00 00 00 mov $0x1,%eax
</branch site>
84: 8b 45 d0 mov 0xffffffd0(%ebp),%eax
87: e8 fc ff ff ff call 88 <schedule+0x88>
8c: 8b 4d c8 mov 0xffffffc8(%ebp),%ecx
8f: 8b 41 04 mov 0x4(%ecx),%eax
92: f0 0f ba 70 08 02 lock btrl $0x2,0x8(%eax)
...
<profile_hit inline function>
39a: 8b 55 04 mov 0x4(%ebp),%edx
39d: b9 01 00 00 00 mov $0x1,%ecx
3a2: b8 02 00 00 00 mov $0x2,%eax
3a7: e8 fc ff ff ff call 3a8 <schedule+0x3a8>
3ac: e9 d3 fc ff ff jmp 84 <schedule+0x84>
</profile_hit inline function>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists