Date:	Fri, 28 Sep 2007 21:13:11 -0400
From:	William Cattey <wdc@....EDU>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Andi Kleen <andi@...stfloor.org>, Chuck Anderson <cra@....EDU>,
	linux-kernel@...r.kernel.org
Subject: Re: vm86.c audit_syscall_exit() call trashes registers

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?

Thanks in advance,

-Bill Cattey

----

William Cattey
Linux Platform Coordinator
MIT Information Services & Technology

N42-040M, 617-253-0140, wdc@....edu
http://web.mit.edu/wdc/www/


On Sep 28, 2007, at 8:58 PM, Jeremy Fitzhardinge wrote:

> 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 <jeremy@...p.org>
>> 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 <jeremy@...source.com>
>>     Signed-off-by: Andi Kleen <ak@...e.de>
>>     Cc: Chuck Ebbert <76306.1226@...puserve.com>
>>     Cc: Zachary Amsden <zach@...are.com>
>>     Cc: Jan Beulich <jbeulich@...ell.com>
>>     Cc: Andi Kleen <ak@...e.de>
>>     Cc: Al Viro <viro@...iv.linux.org.uk>
>>     Cc: Jason Baron <jbaron@...hat.com>
>>     Cc: Chris Wright <chrisw@...s-sol.org>
>>     Signed-off-by: Andrew Morton <akpm@...l.org>
>>
>> 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@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists