Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757610AbXI2A6Y (ORCPT ); Fri, 28 Sep 2007 20:58:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752748AbXI2A6R (ORCPT ); Fri, 28 Sep 2007 20:58:17 -0400 Received: from gw.goop.org ([64.81.55.164]:39008 "EHLO mail.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755228AbXI2A6Q (ORCPT ); Fri, 28 Sep 2007 20:58:16 -0400 Message-ID: <46FDA325.8000602@goop.org> Date: Fri, 28 Sep 2007 17:58:13 -0700 From: Jeremy Fitzhardinge User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: William Cattey CC: Andi Kleen , Chuck Anderson , linux-kernel@vger.kernel.org Subject: Re: vm86.c audit_syscall_exit() call trashes registers References: <20070814183119.GC17694@angus.ind.WPI.EDU> <78642229-39DD-4956-9385-5A3F960BFEEF@mit.edu> <20070814212858.GB23308@one.firstfloor.org> <07759638-DE7C-4341-A642-D611A897614F@MIT.EDU> <20070814214622.GE23308@one.firstfloor.org> <6655DD8B-D9C6-495D-9E22-2FDF6B375C9D@MIT.EDU> <20070814221927.GH23308@one.firstfloor.org> <9D5ACA40-5F33-4F49-8255-D51F554889E7@MIT.EDU> In-Reply-To: <9D5ACA40-5F33-4F49-8255-D51F554889E7@MIT.EDU> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4548 Lines: 124 William Cattey wrote: > Andi, > > Sorry to have taken so long to take another step with this problem. > Once my customers had a work-around, other priorities crowded out this > project. Today Chuck and I did a little more work. We'd heard that a > more recent kernel alleged to fix this stuff. Doing some digging, we > came across this: Hi, I cleaned up some completely bogus code in vm86.c. I don't have any context for your mail though: is my change causing you problems, or does it fix something for you? Thanks, J > > (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20) > > commit 49d26b6eaa8e970c8cf6e299e6ccba2474191bf5 > Author: Jeremy Fitzhardinge > Date: Thu Dec 7 02:14:03 2006 +0100 > > [PATCH] i386: Update sys_vm86 to cope with changed pt_regs and %gs > usage > > sys_vm86 uses a struct kernel_vm86_regs, which is identical to > pt_regs, but > adds an extra space for all the segment registers. Previously > this structure > was completely independent, so changes in pt_regs had to be > reflected in > kernel_vm86_regs. This changes just embeds pt_regs in > kernel_vm86_regs, and > makes the appropriate changes to vm86.c to deal with the new naming. > > Also, since %gs is dealt with differently in the kernel, this > change adjusts > vm86.c to reflect this. > > While making these changes, I also cleaned up some frankly bizarre > code which > was added when auditing was added to sys_vm86. > > Signed-off-by: Jeremy Fitzhardinge > Signed-off-by: Andi Kleen > Cc: Chuck Ebbert <76306.1226@compuserve.com> > Cc: Zachary Amsden > Cc: Jan Beulich > Cc: Andi Kleen > Cc: Al Viro > Cc: Jason Baron > Cc: Chris Wright > Signed-off-by: Andrew Morton > > Chuck and I took a stab at extracting what we thought was the relevant > change to the audit_syscall_exit code, but we must have gotten it > wrong. The EDID transfer always comes up zeros with our extract of > Fitzhardinge's patch. > > > At this point Chuck and I are trying to decide what will get us the > best testing with the least effort. (We keep planning to test with a > stock kernel, but last time that was on our TODO list, the project > languished for a month.) > > Do you have a specific stock kernel revision to recommend we try on > our test system currently running Red Hat's 2.6.18? Are we right to > presume it would be 2.6.18-0 to demonstrate failure and 2.6.20.0 to > attempt to demonstrate success? > > Are you the Andi Kleen who signed off on Fitzhardinge's patch, and if > so do you have some insight for Chuck and I about what pieces are > required to test and see if the bug really got fixed with his cleanup? > > I'd feel a lot more confident we were on the right track if I could > just correctly patch Fitzhardinge's cleanup into the test setup I have > now. > > -Bill > > ---- > > William Cattey > Linux Platform Coordinator > MIT Information Services & Technology > > N42-040M, 617-253-0140, wdc@mit.edu > http://web.mit.edu/wdc/www/ > > > On Aug 14, 2007, at 6:19 PM, Andi Kleen wrote: > >> On Tue, Aug 14, 2007 at 06:14:40PM -0400, William Cattey wrote: >>> In fact, I had begun the process of assuring myself that I could >>> indeed take a main line kernel, and install it in place of a Red Hat >>> Kernel. >> >> Should normally work. Sometimes there are incompatibilities >> with udev -- it is safest to just compile in the drivers you >> need to avoid that -- but likely it would work even without >> that on a modern distro. >> >>> Shall I check back with you after we've re-run the test after putting >>> the stock kernel on the machine? It will be a couple weeks because >>> they're moving my office on Thursday, I'm away on vacation the >>> following week, and I'm still unsure of the procedure to follow to >>> build a totally stock totally mainline kernel and put it into place >>> instead of what Red Hat has made. >> >> Better report to the list again in case others want to chime in. >> But you can put me into cc because I would need to merge >> any resulting patch anyways. >> >> -Andi > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/