From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8438 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.kernel,gmane.linux.lib.musl.general,gmane.comp.gcc.devel,gmane.comp.lib.glibc.alpha,gmane.comp.gnu.binutils Subject: Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers? Date: Tue, 1 Sep 2015 19:23:38 -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 1441160654 6386 80.91.229.3 (2 Sep 2015 02:24:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 02:24:14 +0000 (UTC) Cc: "musl@lists.openwall.com" , gcc@gcc.gnu.org, Kees Cook , libc-alpha , "linux-kernel@vger.kernel.org" , Binutils To: Ian Lance Taylor Original-X-From: linux-kernel-owner@vger.kernel.org Wed Sep 02 04:24:12 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 1ZWxid-0007kS-Dl for glk-linux-kernel-3@plane.gmane.org; Wed, 02 Sep 2015 04:24:11 +0200 Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752660AbbIBCYA (ORCPT ); Tue, 1 Sep 2015 22:24:00 -0400 Original-Received: from mail-ob0-f180.google.com ([209.85.214.180]:35291 "EHLO mail-ob0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751169AbbIBCX6 (ORCPT ); Tue, 1 Sep 2015 22:23:58 -0400 Original-Received: by obuk4 with SMTP id k4so15555634obu.2 for ; Tue, 01 Sep 2015 19:23:58 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type; bh=x84U8y/PePATtIAG51ux6/n+i72MCq1F1WvmKOFBiq4=; b=mmIVCms5gnZeXd/t+4Fp8Zw9cYkx4a50tuLK9WjWJ3Fk2/W+IEqJy/kjZezGEjkDPR CSVJeyKAgIW5NYPIYHF3u256B0j57TVDNuNqYvfRDdwQ5Azz8PYlMYoV37BcINL16jMR o0SGhqHuO/V9Ilwg55uwablNWTLWpSyUDVCzwzuzbbyhPgviPerLpqYUwHd1/MbM48Dx QAp2dGXQ7SFSsJ7i9lWyoGJXRW2/2wjiq1Au+EgKXAz0gkpSyurYfHLuGrZLMenP1lxu YdE2uKgmewDv156BxsOxcHz4xFWzD8bLPGydrxlzA//5YC6aay0HjuHzC88a2P2/I8wT XjdA== X-Gm-Message-State: ALoCoQm7uQGW9iduLqGXtK+BjSSFSYjfBudnfYrKw0OC1xZuDdA1cEBm3H8o0PFMeOJBySZeYaPg X-Received: by 10.182.231.194 with SMTP id ti2mr20322248obc.80.1441160638027; Tue, 01 Sep 2015 19:23:58 -0700 (PDT) Original-Received: by 10.202.57.214 with HTTP; Tue, 1 Sep 2015 19:23:38 -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:2030615 gmane.linux.lib.musl.general:8438 gmane.comp.gcc.devel:141119 gmane.comp.lib.glibc.alpha:55159 gmane.comp.gnu.binutils:70929 Archived-At: On Sep 1, 2015 6:12 PM, "Ian Lance Taylor" wrote: > > 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. Currently it's global and nothing thinks about it per-process at all. The kernel can do whatever it likes going forward, subject to backwards compatibility. Doing something at ELF load time is probably the right approach. > > 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. Oh, interesting. I'll check that. Glibc and competitors could add notes to their statically-linked bits. The unpleasant case is a new dynamic binary linked against an old libc, but that might be irrelevant in practice. After all, I think that a lot of libc competitors never supported the vsyscall page at all, and even glibc isn't really backwards compatible that way. We could also require that both the binary and interpreter have the note, which would more or less solve the backwards compatibility issue. --Andy