From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8450 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.kernel,gmane.linux.lib.musl.general,gmane.comp.lib.glibc.alpha,gmane.comp.gcc.devel,gmane.comp.gnu.binutils Subject: Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers? Date: Wed, 2 Sep 2015 07:08:05 -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 1441202929 30018 80.91.229.3 (2 Sep 2015 14:08:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 14:08:49 +0000 (UTC) Cc: "musl@lists.openwall.com" , Kees Cook , libc-alpha , gcc@gcc.gnu.org, "linux-kernel@vger.kernel.org" , Binutils To: Brian Gerst Original-X-From: linux-kernel-owner@vger.kernel.org Wed Sep 02 16:08:43 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 1ZX8iP-00083M-RC for glk-linux-kernel-3@plane.gmane.org; Wed, 02 Sep 2015 16:08:42 +0200 Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753120AbbIBOI3 (ORCPT ); Wed, 2 Sep 2015 10:08:29 -0400 Original-Received: from mail-ob0-f172.google.com ([209.85.214.172]:32890 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751451AbbIBOI2 (ORCPT ); Wed, 2 Sep 2015 10:08:28 -0400 Original-Received: by obbbh8 with SMTP id bh8so8770273obb.0 for ; Wed, 02 Sep 2015 07:08:27 -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=Hq047qdQ8/w+49KZV6WCcqb/zSUmYJKIy/HKAxz3VaI=; b=Fa2sbKwXDDXKCqN12HeejRfiOYacRH1ERjC6rTOEt4PwCQB4WPS0O73pgu90aCHLJP uSLnfmpXz3KsfysaPS3ZvQfr/MKFQEMHX6dnWFmJ1uqqvrRqMFoprzC+sLaf7B2eAgKp TBm8tnc+WkBOrgQ2+pVnVNekThEK6O3GTpnjod2vVck6jKElfwzx+P1X15YpB6CwlBF2 5N+7pR7M3+g7c0kujrkXDFj3k59bDauWlToOjZIA5O1LK2pfyGWnws6OBfZR5QOpyjwK gPvIyXnLHzYWWkQx27lMMlzPhg/7ZuaGJoAI+H3q6KTuzUYVd18Ji5q1cUevpHw33XPT iFuA== X-Gm-Message-State: ALoCoQngTB0tTLYCnfFmNibnQtELgNt1Esc7Uo+pSylcyGNXeZegFz0LkiwdUvxyF2O89jbX4eOX X-Received: by 10.182.158.231 with SMTP id wx7mr20390879obb.53.1441202907702; Wed, 02 Sep 2015 07:08:27 -0700 (PDT) Original-Received: by 10.202.57.214 with HTTP; Wed, 2 Sep 2015 07:08:05 -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:2030963 gmane.linux.lib.musl.general:8450 gmane.comp.lib.glibc.alpha:55174 gmane.comp.gcc.devel:141134 gmane.comp.gnu.binutils:70945 Archived-At: On Sep 2, 2015 6:57 AM, "Brian Gerst" wrote: > > 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. True, but I don't think that means that the mapping has to be readable in all processes. Once it's the only user-readable mapping in the top 512 GB, we can turn off user access to the whole top 512 GB. The only other user accessible thing in the top 512GB (and the only other user accessible thing in a kernel address at all) is the KVM pvclock mapping. We should turn that off, too, because it's exploitable in more or less the same way as the vsyscall page. --Andy