From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8437 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.comp.lib.glibc.alpha,gmane.linux.lib.musl.general,gmane.comp.gcc.devel,gmane.linux.kernel,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:21:01 -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 1441160494 3943 80.91.229.3 (2 Sep 2015 02:21:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 02:21:34 +0000 (UTC) Cc: "musl@lists.openwall.com" , Kees Cook , gcc@gcc.gnu.org, libc-alpha , "linux-kernel@vger.kernel.org" , Binutils To: Brian Gerst Original-X-From: libc-alpha-return-62878-glibc-alpha=m.gmane.org@sourceware.org Wed Sep 02 04:21:30 2015 Return-path: Envelope-to: glibc-alpha@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZWxg1-00066K-NZ for glibc-alpha@plane.gmane.org; Wed, 02 Sep 2015 04:21:30 +0200 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=t33w ftjbe80Na0gfyhscwKJeHBS6woTKarN3tf3R1a5I6YOKr4igKj3PtTNrKX5HMXeO mxzgJ/Zb2aST8o8oM0ZK4dQvhfzbpKcfcoaJ65DtODoYd9jbhgvIhqs/Mb8b0+7l LhUxc0R6RxvmUj5cIdvv1mSK3M0UmV72PFdN/4U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; s=default; bh=84Jc9M7nSL KjWFu+WPKB1jjO0m4=; b=I8EXU16XLjvN0yesvmG2oF9OXuH6+T5Pi+U96fmR5e sVAnSSp6X1Q/+g7SL2C6i4/wFo1cciqo9t2YkEjalmvwQXZxhQoTqgsAyeigMEYL O8fV2jFSzuLqXjB2x9hswRFqjR4eQDiTIXta9IQ5NuWMk+C0kszI1LL/UJZ6ZJeo 8= Original-Received: (qmail 85032 invoked by alias); 2 Sep 2015 02:21:25 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 85008 invoked by uid 89); 2 Sep 2015 02:21:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f177.google.com 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=th7/D5uvqKJi2S6cWXixGG0AwkwoUdyltnihISjywaE=; b=RX1J6D1xtvhXSslFD+7bMtPq5zJwUg7ePUS6DB3k8YVyaeaG81UBCPowFD/hPjDkO6 ltN3nHyM7BExX1tZ+lguGda1TfX4fxK8/iulOXNDQKBD1sOzHtCU1ObwWE3SGw/Mt8QS Ij3WJsrtdDUrstgW9ntAwToXmaBDF1rrp45nNy3EWDJXn7+EG33mnV7NGyQP/OWYuA9A LowATM6eBxm6RsPARrDGUryhbvHLABKF5ccsIVyT/Lyac0e75gT+ZLiprsuLyPYhJqcY Ie9hh8r0AP7GPq2dfuEYA/YtUvR0SC1aQAFR9sfl80h4MCG0MKWLE39gx7RW3g8nvY2s W1tw== X-Gm-Message-State: ALoCoQncjjo9/bwXuYv47QKhsm7ErRyogj5XXUDjrIRNkRe0yuqgRZLl5/G26icYYpbqekiGTLog X-Received: by 10.60.96.194 with SMTP id du2mr20569118oeb.2.1441160481126; Tue, 01 Sep 2015 19:21:21 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:55158 gmane.linux.lib.musl.general:8437 gmane.comp.gcc.devel:141118 gmane.linux.kernel:2030613 gmane.comp.gnu.binutils:70928 Archived-At: On Sep 1, 2015 6:53 PM, "Brian Gerst" wrote: > > On Tue, Sep 1, 2015 at 8:51 PM, 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. > > > The vsyscall page is mapped in the fixmap region, which is shared > between all processes. You can't turn it off for an individual > process. Why not? We already emulate all attempts to execute it, and that's trivial to turn of per process. Project Zero pointed out that read access is a problem, too, but we can flip the U/S bit in the pgd once we evict pvclock from the fixmap. And we definitely need to evict pvclock from the fixmap regardless. --Andy