From patchwork Thu Oct 26 09:09:40 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 117182 Delivered-To: patch@linaro.org Received: by 10.140.22.164 with SMTP id 33csp524860qgn; Thu, 26 Oct 2017 02:09:55 -0700 (PDT) X-Google-Smtp-Source: ABhQp+QpJCX4wGRUhvMoNIdM90LXevNmxQOxY6ykY5XrugOnZxha0xp5NxI6VsC3lrARfi02XqWx X-Received: by 10.84.143.100 with SMTP id 91mr3860166ply.136.1509008995633; Thu, 26 Oct 2017 02:09:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509008995; cv=none; d=google.com; s=arc-20160816; b=rm3JL/g79c1KsidtudMts2EbAiyvOyRQIiouaR0FsnkXspJFW3GNO0oWUnsdqChTmk NGF+m6074JSvYFdt11QKPrye/Mjd86yb5hJnDdew9rwyEdoAq+s0AdoAsQAmxo5loK8I IDCPq4UqAysKuyZsmv+kEJ0+qEfuMd6qtCxqPTwfyGtikTHnsp3eGAHzQgHKJFlFh6Mi Tsfwpgaou8zdPaB/8OR1qVN55OwPPJjARrW03jJCXgxXQcucTzjSODAS3BhHAoyZg93/ jzm78M3kFwivWRMyYJhYBDWRzueZGTz12/7N5O9Egq5PmZuSolePfLA/VqOdcSB3nUzS eCMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=Z4xbex9QLassNlJdt3rfL1s6OjEM9m2ZD7pLGLhHV3E=; b=QUwBkbThNwoc4lc40TCJ4aqprQEYRKnD7TshRcWYwRxrg/Uw/V/cGO1cof6GkyEo0V CNXfK2nTkjwjdRzVViovKo3LrZqUOVd/l+expIlC8YbjiSgiI7O7pobh4eMCoHwF24qg z5RWSBgWby6pcRj/oo4SUSZlS/F+o1+2eK2pyvbl71V30l1AdjqszEkLTpKi+DwG8LCA 3sHPwl1VF5sH1B3VuXDtPBMKgGDA41JKLfuX1JNUG/Qc4lb9hn9uUfAHFqguIzPeufpW ZYbOXnnHzqdnsfCVdaB1sa12q08tTa8r2cMfK0n0niKj9V2Noxc8t2f+Y4YoOd6y6QmP w5AQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y6si3046816pgp.587.2017.10.26.02.09.55; Thu, 26 Oct 2017 02:09:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932346AbdJZJJy (ORCPT + 27 others); Thu, 26 Oct 2017 05:09:54 -0400 Received: from foss.arm.com ([217.140.101.70]:44632 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751009AbdJZJJu (ORCPT ); Thu, 26 Oct 2017 05:09:50 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2F1AA15AD; Thu, 26 Oct 2017 02:09:50 -0700 (PDT) Received: from localhost.localdomain (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5EE4B3F25D; Thu, 26 Oct 2017 02:09:48 -0700 (PDT) From: Mark Rutland To: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Mark Rutland , Catalin Marinas , Kees Cook , Laura Abbott , Will Deacon Subject: [RFC PATCH 0/2] arm64: optional paranoid __{get,put}_user checks Date: Thu, 26 Oct 2017 10:09:40 +0100 Message-Id: <20171026090942.7041-1-mark.rutland@arm.com> X-Mailer: git-send-email 2.11.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, In Prague, Kees mentioned that it would be nice to have a mechanism to catch bad __{get,put}_user uses, such as the recent CVE-2017-5123 [1,2] issue with unsafe_put_user() in waitid(). These patches allow an optional access_ok() check to be dropped in arm64's __{get,put}_user() primitives. These will then BUG() if a bad user pointer is passed (which should only happen in the absence of an earlier access_ok() check). The first patch rewrites the arm64 access_ok() check in C. This gives the compiler the visibility it needs to elide redundant access_ok() checks, so in the common case: get_user() access_ok() __get_user() BUG_ON(!access_ok()) ... the compiler can determine that the second access_ok() must return true, and can elide it along with the BUG_ON(), leaving: get_user() access_ok() __get_user() ... and thus this sanity check can have no cost in the common case. The compiler doesn't always have the visibility to do this (e.g. if the two access_ok() checks are in different compilation units), but it seems to manage to do this most of the time -- In testing with v4.14-rc5 defconfig this only increases the total Image size by 4KiB. I had a go at turning this into a BUILD_BUG_ON(), to see if we could catch this issue at compile time. However, my GCC wasn't able to remove the BUILD_BUG() from some {get,put}_user cases. Maybe we can fix that, or maybe we can have some static analysis catch this at build time. It's entirely possible that I've made some catastrophic mistake in these patches; I've only build-tested them so far, and I don't currently have access to hardware to test on. I also haven't yet modified __copy_{to,from}_user and friends along similar lines, so this is incomplete. If there aren't any major objections to this approach, I can fold those in for the next spin. Thanks, Mark. [1] https://lwn.net/Articles/736348/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96ca579a1ecc943b75beba58bebb0356f6cc4b51 Mark Rutland (2): arm64: write __range_ok() in C arm64: allow paranoid __{get,put}user arch/arm64/Kconfig | 9 +++++++++ arch/arm64/include/asm/uaccess.h | 27 +++++++++++++++++++-------- 2 files changed, 28 insertions(+), 8 deletions(-) -- 2.11.0