[lkml]   [2011]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls
On Sun, Jun 5, 2011 at 3:30 PM, Ingo Molnar <> wrote:
> * Andy Lutomirski <luto@MIT.EDU> wrote:
>> This patch is not perfect: the vread_tsc and vread_hpet functions
>> are still at a fixed address.  Fixing that might involve making
>> alternative patching work in the vDSO.
> Can you see any problem with them? Here is how they are looking like
> currently:
> ffffffffff600100 <vread_tsc>:
> ffffffffff600100:       55                      push   %rbp
> ffffffffff600101:       48 89 e5                mov    %rsp,%rbp
> ffffffffff600104:       66 66 90                data32 xchg %ax,%ax
> ffffffffff600107:       66 66 90                data32 xchg %ax,%ax
> ffffffffff60010a:       0f 31                   rdtsc
> ffffffffff60010c:       89 c1                   mov    %eax,%ecx
> ffffffffff60010e:       48 89 d0                mov    %rdx,%rax
> ffffffffff600111:       48 8b 14 25 28 0d 60    mov    0xffffffffff600d28,%rdx
> ffffffffff600118:       ff
> ffffffffff600119:       48 c1 e0 20             shl    $0x20,%rax
> ffffffffff60011d:       48 09 c8                or     %rcx,%rax
> ffffffffff600120:       48 39 d0                cmp    %rdx,%rax
> ffffffffff600123:       73 03                   jae    ffffffffff600128 <vread_tsc+0x28>
> ffffffffff600125:       48 89 d0                mov    %rdx,%rax
> ffffffffff600128:       5d                      pop    %rbp
> ffffffffff600129:       c3                      retq
> ffffffffff60012a <vread_hpet>:
> ffffffffff60012a:       55                      push   %rbp
> ffffffffff60012b:       48 89 e5                mov    %rsp,%rbp
> ffffffffff60012e:       8b 04 25 f0 f0 5f ff    mov    0xffffffffff5ff0f0,%eax
> ffffffffff600135:       89 c0                   mov    %eax,%eax
> ffffffffff600137:       5d                      pop    %rbp
> ffffffffff600138:       c3                      retq
> There's no obvious syscall instruction in them that i can see. No
> 0x0f 0x05 pattern (even misaligned), no 0xcd-anything.

I can't see any problem, but exploit writers are exceedingly clever,
and maybe someone has a use for a piece of the code that isn't a
syscall. Just as a completely artificial example, here's some buggy

void buggy_function()

long should_be_insecure()
return 0; // We don't want to be exploitable.

int main()
if (should_be_insecure())
chmod("/etc/passwd", 0666); // Live on the edge!

Assume that this code has frame pointers omitted but no other
optimizations. An exploit could set attacher_controlled_pointer to
0xffffffffff60012e. Then buggy_function will call the last bit of
vread_hpet, which will set eax to something nonzero, pop the return
address (i.e. the pointer to should_be_insecure) off the stack, then
return to main. main checks the return value, decides it's nonzero,
and roots the system.

Of course, this is totally artificial and I haven't double-checked my
math, but it's kind of fun to be paranoid.

> We could even 'tie down' the actual assembly by moving this all to a
> .S - this way we protect against GCC accidentally generating
> something dangerous in there. I suggested that before.

I have no problem with that suggestion, except that once the current
series makes it into -tip I intend to move vread_tsc and vread_hpet to
the vDSO. So leaving them alone for now saves work, and they'll be
more maintainable later if they're written in C.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-06-05 22:05    [W:0.267 / U:17.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site