From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8441 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: Tue, 1 Sep 2015 22:54:40 -0400 Message-ID: <20150902025440.GG17773@brightrain.aerifal.cx> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1441162506 31242 80.91.229.3 (2 Sep 2015 02:55:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 02:55:06 +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 04:55:05 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 1ZWyCW-0003E1-It for glk-linux-kernel-3@plane.gmane.org; Wed, 02 Sep 2015 04:55:04 +0200 Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752280AbbIBCyy (ORCPT ); Tue, 1 Sep 2015 22:54:54 -0400 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:42971 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752061AbbIBCyw (ORCPT ); Tue, 1 Sep 2015 22:54:52 -0400 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1ZWyC8-00020S-00; Wed, 02 Sep 2015 02:54:40 +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:2030630 gmane.comp.lib.glibc.alpha:55160 gmane.linux.lib.musl.general:8441 gmane.comp.gcc.devel:141120 gmane.comp.gnu.binutils:70930 Archived-At: 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. If this is not the case, I have what sounds like an elegant solution, if it works: presumably affected versions of glibc that used this used it for all syscalls, so if the process has made any normal syscalls before using the vsyscall addresses, you can assume it's a bug/attack and and just raise SIGSEGV. If there are corner cases this doesn't cover, maybe the approach can still be adapted to work; it's cleaner than introducing header cruft, IMO. Rich