From: Chuck Anderson <cra@WPI.EDU>
To: linux-kernel@vger.kernel.org
Cc: wdc@mit.edu
Subject: vm86.c audit_syscall_exit() call trashes registers
Date: Tue, 14 Aug 2007 14:31:19 -0400 [thread overview]
Message-ID: <20070814183119.GC17694@angus.ind.WPI.EDU> (raw)
Please Cc: any replies, as we are not subscribed to linux-kernel.
Thanks.
Somewhere around 2.6.16.12 a call to audit_syscall_exit was added to
vm86.c:
static void do_sys_vm86(struct kernel_vm86_struct *info, struct task_struct *tsk)
{
struct tss_struct *tss;
+ long eax;
/*
* make sure the vm86() system call doesn't try to do anything silly
*/
@@ -305,13 +307,19 @@ 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(current, AUDITSC_RESULT(eax), eax);
+
__asm__ __volatile__(
- "xorl %%eax,%%eax; movl %%eax,%%fs; movl %%eax,%%gs\n\t"
"movl %0,%%esp\n\t"
"movl %1,%%ebp\n\t"
"jmp resume_userspace"
: /* no outputs */
- :"r" (&info->regs), "r" (task_thread_info(tsk)) : "ax");
+ :"r" (&info->regs), "r" (task_thread_info(tsk)));
/* we never return here */
}
This appears to have caused intermittent data corruption of the
results of the vm86() call that the X server uses to get EDID data
from the monitor via the VESA BIOS. After removing the
audit_syscall_exit() call, the problems mentioned in these bugzillas
disappear:
Fetch of EDID 128 byte buffer by X server through vm86 INT 10 call is flaky.
http://bugzilla.kernel.org/show_bug.cgi?id=8633
RHEL 5 fails to get EDID data from monitor and sets low resolution
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236416
If I'm reading correctly, it appears that the code above trashes the
%fs and %gs registers, or otherwise doesn't leave them at zero before
returning from the system call as the old code did. Is this a correct
analysis? How should this be fixed?
Thanks.
-Chuck
next reply other threads:[~2007-08-14 19:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-14 18:31 Chuck Anderson [this message]
2007-08-14 20:42 ` Andi Kleen
2007-08-14 20:52 ` William Cattey
2007-08-14 21:28 ` Andi Kleen
2007-08-14 21:37 ` William Cattey
[not found] ` <20070814214622.GE23308@one.firstfloor.org>
[not found] ` <6655DD8B-D9C6-495D-9E22-2FDF6B375C9D@MIT.EDU>
[not found] ` <20070814221927.GH23308@one.firstfloor.org>
2007-09-25 23:38 ` William Cattey
2007-09-29 0:58 ` Jeremy Fitzhardinge
2007-09-29 1:13 ` William Cattey
2007-09-29 6:06 ` Jeremy Fitzhardinge
2007-09-29 6:09 ` Jeremy Fitzhardinge
2007-10-01 22:30 ` William Cattey
2007-10-01 23:49 ` Jeremy Fitzhardinge
2007-10-02 16:44 ` Chuck Ebbert
2007-10-04 23:58 ` William Cattey
2007-10-05 0:10 ` Chuck Ebbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070814183119.GC17694@angus.ind.WPI.EDU \
--to=cra@wpi.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=wdc@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome