Re: vm86.c audit_syscall_exit() call trashes registers
From: Jeremy Fitzhardinge
Date: Fri Sep 28 2007 - 20:58:26 EST
William Cattey wrote:
> 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:
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?
> commit 49d26b6eaa8e970c8cf6e299e6ccba2474191bf5
> Author: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
> Date: Thu Dec 7 02:14:03 2006 +0100
> [PATCH] i386: Update sys_vm86 to cope with changed pt_regs and %gs
> 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 <jeremy@xxxxxxxxxxxxx>
> Signed-off-by: Andi Kleen <ak@xxxxxxx>
> Cc: Chuck Ebbert <76306.1226@xxxxxxxxxxxxxx>
> Cc: Zachary Amsden <zach@xxxxxxxxxx>
> Cc: Jan Beulich <jbeulich@xxxxxxxxxx>
> Cc: Andi Kleen <ak@xxxxxxx>
> Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
> Cc: Jason Baron <jbaron@xxxxxxxxxx>
> Cc: Chris Wright <chrisw@xxxxxxxxxxxx>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
> 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 188.8.131.52 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
> William Cattey
> Linux Platform Coordinator
> MIT Information Services & Technology
> N42-040M, 617-253-0140, wdc@xxxxxxx
> 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
>> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/