[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=FCwtiyRGEuueD_vP+BLHHPzCpBw@mail.gmail.com>
Date: Wed, 1 Jun 2011 07:54:22 -0400
From: Brian Gerst <brgerst@...il.com>
To: Andy Lutomirski <luto@....edu>
Cc: Ingo Molnar <mingo@...e.hu>, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org, Jesper Juhl <jj@...osbits.net>,
Borislav Petkov <bp@...en8.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Jan Beulich <JBeulich@...ell.com>,
richard -rw- weinberger <richard.weinberger@...il.com>,
Mikael Pettersson <mikpe@...uu.se>,
Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH v3 08/10] x86-64: Emulate legacy vsyscalls
On Tue, May 31, 2011 at 9:16 AM, Andy Lutomirski <luto@....edu> wrote:
> There's a fair amount of code in the vsyscall page. It contains a
> syscall instruction (in the gettimeofday fallback) and who knows
> what will happen if an exploit jumps into the middle of some other
> code.
>
> Reduce the risk by replacing the vsyscalls with short magic
> incantations that cause the kernel to emulate the real vsyscalls.
> These incantations are useless if entered in the middle.
How about remapping the vsyscall page into a random page in the
modules area, and make the fixed page simply have stubs that jump to
the code in that page. That would solve the fixed address syscall
problem without any more overhead.
--
Brian Gerst
--
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