[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWNqFuCCGoh2C72F4ZOoXXSNXtxAzN6eDiQZZXF_U2mbw@mail.gmail.com>
Date: Fri, 5 Jan 2018 10:47:15 -0800
From: Andy Lutomirski <luto@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Kees Cook <keescook@...omium.org>,
Peter Zijlstra <peterz@...radead.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC] selftests/x86: Add test_vsyscall
On Fri, Jan 5, 2018 at 10:23 AM, Borislav Petkov <bp@...en8.de> wrote:
> On Fri, Jan 05, 2018 at 09:53:16AM -0800, Andy Lutomirski wrote:
>> emulate_noread would avoid one exploit technique that Kees saw
>> somewhere. And per-process disablement would let a system remain
>> compatible with old binaries without reducing security for newer
>> binaries.
>
> Or we can simply say new binaries can switch to the vdso. Because this
> way, vsyscall will never really be phased out - new shit will simply
> keep using it.
As far as I know, new binaries don't use vsycall. The holdouts were
musl and Go, and both are fixed.
The remaining problem is that, for certain classes of userspace bugs,
an attacker can take advantage of the vsyscall page's existence at a
fixed address to cause mischief. So opting out of having it be there
could be helpful to mitigate attacks.
Powered by blists - more mailing lists