Re: vm86.c audit_syscall_exit() call trashes registers

[Jeremy Fitzhardinge <jeremy@goop.org>]

William Cattey wrote:
> Your fix seems to have remedied a problem we are having with EDID
> fetches through vm86.c.  At the present moment, we're trying to
> understand your cleanup so as to back port it to an earlier rev of the
> kernel (2.6.18).
>
> 3 questions for you:
>
> 1. Are we correct in understanding that your cleanup only touched
> vm86.c and vm86.h?
>
> 2. Do you remember your changes well enough from back when you made
> them in December 2006 to be able to point out the changes solely made
> to the audit calls?
>
> 3. Does correct operation of vm86.c in the 2.6 kernel require all of
> your changes, or just the subset that affects the audit calls?

It was only a small part of the patch.  I think it was basically this
hunk (hand-edited, so this won't apply directly):

@@ -306,19 +334,18 @@ static void do_sys_vm86(struct kernel_vm
        tsk->thread.screen_bitmap = info->screen_bitmap;
        if (info->flags & VM86_SCREEN_BITMAP)
                mark_screen_rdonly(tsk->mm);
        __asm__ __volatile__("xorl %eax,%eax; movl %eax,%fs; movl %eax,%gs\n\t");
-       __asm__ __volatile__("movl %%eax, %0\n" :"=r"(eax));
 
        /*call audit_syscall_exit since we do not exit via the normal paths */
        if (unlikely(current->audit_context))
-               audit_syscall_exit(AUDITSC_RESULT(eax), eax);
+               audit_syscall_exit(AUDITSC_RESULT(0), 0);
 

 

This is certainly a bogus piece of code, and it could result in more or
less random values of eax being passed to audit_syscall_exit().    But I
don't know if it will have any bearing on your EDID problem; the rest of
the patch is related to the introduction of using %gs as the base for
the per-processor data area, and shouldn't cause any functional change
to sys_vm86(), but its possible I fixed some other bug in the process.

    J