[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E947BC9.7040805@mit.edu>
Date: Tue, 11 Oct 2011 10:24:25 -0700
From: Andrew Lutomirski <luto@....EDU>
To: Ingo Molnar <mingo@...e.hu>
CC: richard -rw- weinberger <richard.weinberger@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Adrian Bunk <bunk@...sta.de>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: [RFC] fixing the UML failure root cause
On 10/10/2011 11:22 PM, Ingo Molnar wrote:
>
> * Andrew Lutomirski <luto@....edu> wrote:
>
>>> Andrew?
>>
>> I think I know what the root cause is and I have most of a patch to
>> fix it. It doesn't compile (yet), it's a little less trivial than
>> I'd like for something this late in the -rc cycle, and it adds 16
>> bytes to thread_struct (ugh!).
>>
>> I think I can make a follow-up patch that removes 32 bytes of
>> per-thread state to restore my karma, though, but that will
>> definitely not be 3.1 material.
>
> Ok, i've queued up the vsyscall=native patch in tip:x86/urgent for
> now - we can re-try in v3.2 (perhaps) if a satisfactory solution is
> found.
Getting full cause information for uaccess failure was messy enough that
I gave up. There are a *lot* of uaccess failure paths to work through.
So here's a different approach. It's not perfect: it always blames
SEGV_MAPERR instead of SEGV_ACCERR. I implemented it for vgettimeofday
but not the other two vsyscalls.
What do you think of this approach? If it seems good, I'll finish the
patch and submit it.
With this patch applied, UML appears to work, but it fills the log with
exploit attempt warnings. Any ideas on what to do about that?
--Andy
>
> Thanks,
>
> Ingo
View attachment "vsyscall_hack.patch" of type "text/plain" (3034 bytes)
Powered by blists - more mailing lists