From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8449 Path: news.gmane.org!not-for-mail From: Brian Gerst 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: Wed, 2 Sep 2015 09:57:26 -0400 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 1441202259 18990 80.91.229.3 (2 Sep 2015 13:57:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 13:57:39 +0000 (UTC) Cc: "musl@lists.openwall.com" , Kees Cook , gcc@gcc.gnu.org, libc-alpha , "linux-kernel@vger.kernel.org" , Binutils To: Andy Lutomirski Original-X-From: libc-alpha-return-62893-glibc-alpha=m.gmane.org@sourceware.org Wed Sep 02 15:57:37 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 1ZX8Xe-0001nr-SM for glibc-alpha@plane.gmane.org; Wed, 02 Sep 2015 15:57:35 +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:date :message-id:subject:from:to:cc:content-type; q=dns; s=default; b= BK3HqkSttyGgkqoakskeLuoqgX65S0iADeNuzWbBscJEqPAZrDzw/B/wB0pmVy7I +8bqZ2BGToMzB3cNPCGe0dJosWs5YYxA5C8vwnwXy8uhMV3zaGdgsletvhIjjEk2 ijswvbiGLQQrKdieykjCdDZDNTuke67YWL3ssF5q9FE= 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:date :message-id:subject:from:to:cc:content-type; s=default; bh=3gF8w 3/DyyiaDXXLmRL6MibfZKs=; b=xbF62mri1B8BR+g2IRVsYfes7V4XDGo6mecRs h8NT5H7JNtZzgVBeeZUnM4mBjlhMDyOJyjbjcWI9vxX0IhJGFOdKKov3FjZMYaCQ JPlxsbGq/oiYpu550dnso19sjAMn+o/dcGo+FykJwULuRFa2MPJSDFboXG95IGiN PiBMAo= Original-Received: (qmail 103513 invoked by alias); 2 Sep 2015 13:57:30 -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 103479 invoked by uid 89); 2 Sep 2015 13:57:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ob0-f173.google.com X-Received: by 10.60.96.194 with SMTP id du2mr22256403oeb.2.1441202246178; Wed, 02 Sep 2015 06:57:26 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:55173 gmane.linux.lib.musl.general:8449 gmane.comp.gcc.devel:141133 gmane.linux.kernel:2030957 gmane.comp.gnu.binutils:70944 Archived-At: On Tue, Sep 1, 2015 at 10:21 PM, Andy Lutomirski wrote: > 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. Sure, you can turn off emulation per-process. But the page mapping will be the same for every process because it is in the kernel part of the page tables which is shared by all processes. -- Brian Gerst