From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8435 Path: news.gmane.org!not-for-mail From: Ian Lance Taylor Newsgroups: gmane.linux.kernel,gmane.comp.lib.glibc.alpha,gmane.linux.lib.musl.general,gmane.comp.gcc.devel,gmane.comp.gnu.binutils Subject: Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers? Date: Tue, 1 Sep 2015 18:12:12 -0700 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1441156348 7546 80.91.229.3 (2 Sep 2015 01:12:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 01:12:28 +0000 (UTC) Cc: Kees Cook , "linux-kernel@vger.kernel.org" , libc-alpha , "musl@lists.openwall.com" , GCC Development , Binutils To: Andy Lutomirski Original-X-From: linux-kernel-owner@vger.kernel.org Wed Sep 02 03:12:27 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 1ZWwbC-0006iE-FN for glk-linux-kernel-3@plane.gmane.org; Wed, 02 Sep 2015 03:12:26 +0200 Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754532AbbIBBMQ (ORCPT ); Tue, 1 Sep 2015 21:12:16 -0400 Original-Received: from mail-oi0-f45.google.com ([209.85.218.45]:33978 "EHLO mail-oi0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752061AbbIBBMN (ORCPT ); Tue, 1 Sep 2015 21:12:13 -0400 Original-Received: by oiev17 with SMTP id v17so10424403oie.1 for ; Tue, 01 Sep 2015 18:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sUN3TC3ULgcEXJ43l37YSazA8QfP0gIRWXzO84k4rLs=; b=ErqYGdekw0dzcEp8oY8w4jQTOYT0y0tm0Hi13tB2aWGcNsDRtZkULLFi+TDiVFE+Ff YF0dPk4pSUVLgnbeJNA9ZHo522reJ9Jl9NnGbHTNiwMeCD7reGtP6Ns2zipr40K3ZTPI utGnMBxNjBfVIK7g0yoF4zcXHdnJgKZs8qLD6c47rBzjqyXQLCdHPQzUWRxp3bxVRXES 5J6guZ+qvrXyDRoexxgt2bi6oKjHTneLM9W790TyqoInV2D7/ML0jeR14SLmXXRsvwrR EbW/fBLieskrP1ILPNS5Q/YpPiKJymaxZNiaYLR46rXi9qrFiopx/6hnHo70Y2Y41Rnr LvTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sUN3TC3ULgcEXJ43l37YSazA8QfP0gIRWXzO84k4rLs=; b=Y4gzYXzG+Qw2s7jElx+8pzfmD06/xU99AlEa/HlkvvKS21Q85h2iOStYC4eHxDbrhM Cpt16hWYdF6mKssfFu5hpMJxl7Q+qUB+LMB6pswAo+56VesnXRC1EbY/WXDObugwtQvu Bzgsj1do5bVqRpQ1NLhrGuC0NwTObxf629qUUt6cdvtfjn+1Go8jDpoJiMEWSOpjJrAz 4StphLOoawduOOTdPNVQMPZGQtJmxRZhbpR/Gbe3ps2QpsecutGC36B/LKkDITj4o02n 7CxLiSlMX+1hDuyE/nKCp8Yd64ZDNfQghN6tRreDJYUwFrv8gVOIO1/E33yTaOquwEM4 BnqA== X-Gm-Message-State: ALoCoQnVot09mjMkkk5rwhou+d7p6PBMvJLQaanQxPDX/T4OjqfBx7sLKcB9WYGBS9jf33n3lfLr X-Received: by 10.202.168.213 with SMTP id r204mr3161313oie.44.1441156332200; Tue, 01 Sep 2015 18:12:12 -0700 (PDT) Original-Received: by 10.60.160.67 with HTTP; Tue, 1 Sep 2015 18:12:12 -0700 (PDT) In-Reply-To: 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:2030590 gmane.comp.lib.glibc.alpha:55154 gmane.linux.lib.musl.general:8435 gmane.comp.gcc.devel:141114 gmane.comp.gnu.binutils:70926 Archived-At: On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski wrote: > > 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. What sets up the vsyscall page, and what information does it have before doing so? I'm guessing it's the kernel that sets it up, and that all it can see at that point is the program headers. We could pass information using an appropriate note section. My recollection is that the linkers will turn an SHF_ALLOC note section into a PT_NOTE program header. Ian