From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8447 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.kernel,gmane.comp.lib.glibc.alpha,gmane.linux.lib.musl.general,gmane.comp.gcc.devel,gmane.comp.gnu.binutils Subject: Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers? Date: Wed, 2 Sep 2015 01:22:06 -0400 Message-ID: <20150902052206.GJ17773@brightrain.aerifal.cx> References: <20150902025440.GG17773@brightrain.aerifal.cx> <20150902041815.GH17773@brightrain.aerifal.cx> <20150902045523.GI17773@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1441171353 22663 80.91.229.3 (2 Sep 2015 05:22:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 05:22:33 +0000 (UTC) Cc: Kees Cook , "linux-kernel@vger.kernel.org" , libc-alpha , "musl@lists.openwall.com" , gcc@gcc.gnu.org, Binutils To: Andy Lutomirski Original-X-From: linux-kernel-owner@vger.kernel.org Wed Sep 02 07:22:28 2015 Return-path: Envelope-to: glk-linux-kernel-3@plane.gmane.org Original-Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZX0V9-0005go-EW for glk-linux-kernel-3@plane.gmane.org; Wed, 02 Sep 2015 07:22:27 +0200 Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751134AbbIBFWQ (ORCPT ); Wed, 2 Sep 2015 01:22:16 -0400 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:42990 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750776AbbIBFWP (ORCPT ); Wed, 2 Sep 2015 01:22:15 -0400 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1ZX0Uo-0002Nc-00; Wed, 02 Sep 2015 05:22:06 +0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Xref: news.gmane.org gmane.linux.kernel:2030658 gmane.comp.lib.glibc.alpha:55166 gmane.linux.lib.musl.general:8447 gmane.comp.gcc.devel:141126 gmane.comp.gnu.binutils:70936 Archived-At: On Tue, Sep 01, 2015 at 10:03:27PM -0700, Andy Lutomirski wrote: > On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker wrote: > > On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote: > >> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote: > >> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote: > >> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote: > >> >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote: > >> >> >> Hi all- > >> >> >> > >> >> >> Linux has a handful of weird features that are only supported for > >> >> >> backwards compatibility. The big one is the x86_64 vsyscall page, but > >> >> >> uselib probably belongs on the list, too, and we might end up with > >> >> >> more at some point. > >> >> >> > >> >> >> I'd like to add a way that new programs can turn these features off. > >> >> >> In particular, I want the vsyscall page to be completely gone from the > >> >> >> perspective of any new enough program. This is straightforward if we > >> >> >> add a system call to ask for the vsyscall page to be disabled, but I'm > >> >> >> wondering if we can come up with a non-syscall way to do it. > >> >> >> > >> >> >> I think that the ideal behavior would be that anything linked against > >> >> >> a sufficiently new libc would be detected, but I don't see a good way > >> >> >> to do that using existing toolchain features. > >> >> >> > >> >> >> Ideas? We could add a new phdr for this, but then we'd need to play > >> >> >> linker script games, and I'm not sure that could be done in a clean, > >> >> >> extensible way. > >> >> > > >> >> > Is there a practical problem you're trying to solve? My understanding > >> >> > is that the vsyscall nonsense is fully emulated now and that the ways > >> >> > it could be used as an attack vector have been mitigated. > >> >> > >> >> They've been mostly mitigated, but not fully. See: > >> >> > >> >> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html > >> > > >> > That looks like it would be mitigated by not having any mapping there > >> > at all and having the kernel just catch the page fault and emulate > >> > rather than filling it with trapping opcodes for the kernel to catch. > >> > > >> > >> Oddly, that causes a compatibility problem. There's a program called > >> pin that does dynamic instrumentation and actually expects to be able > >> to read the targets of calls. The way that Linux handles this now is > > > > Um, do people seriously need to do this dynamic instrumentation on > > ancient obsolete binaries? This sounds to me like confused > > requirements. > > Unclear. They certainly did, and I got a bug report, the first time > around. That was a couple years ago. > > I suppose we could have a sysctl that you need to set to enable that > use case. OTOH, I think that, as long as we have a way to distinguish > new and old binaries, it's not that much harder to twiddle vsyscall > readability per process than it is to twiddle vsyscall executability > per process. But we don't have a (reasonable) way to distinguish new and old binaries, at least not at the right point in history. If we're adding a new header or whatnot, only bleeding-edge binaries will benefit from it. All existing binaries from the past N years that don't need the vsyscall nonsense will still get it unnecessarily, and still be subject to the risks. This has me wondering if there's any point in trying to solve the problem on the granularity of individual programs. Users running all-new binaries (that would benefit from a header flag) can just remove vsyscall support entirely from their kernels. Users with a mix binaries of various ages will likely still have the vsyscall risk in most programs, _including_ many newer binaries that have no use for vsyscall but lack the new header. BTW, since the only calls to vsyscall are from glibc, it seems to me that the only ways vsyscall can be needed are: 1. The user is running old glibc, in which case all dynamic-linked programs need it. 2. The user is running old static-linked glibc binaries. Almost nobody does this. During the era of vsyscall, static linking was all but deprecated. 3. The user is running old binaries using a custom library path with old glibc in it. This is almost certainly just a bogus setup since glibc's symbol versioning is supposed to make old binaries run fine with a newer libc.so. None of these seem to be use cases that we should be engineering complex solutions for. For case 1, the solution wouldn't help anyway since all programs need vsyscall. For cases 2 and 3, if the user wants to harden their system so that newer binaries are not affected by vsyscall, they should just remove vsyscall and fix their old binaries/libraries. In case 2, in particular, you can assume the ability to re-link with an updated glibc; otherwise, there's an LGPL violation going on. Rich