From patchwork Fri Jun 9 16:32:28 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 103535 Delivered-To: patch@linaro.org Received: by 10.140.91.77 with SMTP id y71csp291141qgd; Fri, 9 Jun 2017 09:33:12 -0700 (PDT) X-Received: by 10.98.93.217 with SMTP id n86mr43820390pfj.113.1497025992371; Fri, 09 Jun 2017 09:33:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497025992; cv=none; d=google.com; s=arc-20160816; b=F/p0SXw9HoYMhfsB2AD6vYz+Dj79Tmjve1LHkX81YxsRl5KcOzWVu3jlf49/xj1VYO EtKY6MnwWzVU0PCPZnhSWWc5owktoh/oKsD5FEO4jthQsd4+tFOQKTBhYUIdl05sEwXh g3EZMVS+VrFCuONclOVdP43x7q6hxr+s62n8H+Q7VLBkL8Y4nabvB3yE+x2RBxpiFqbg OdHVWsexuoH9m9rfyWCu/uearsB7779bxJ98vHJjWU5RJnTHzF8d+2ASv4p/pMJUs6Bm WmiIOgOhGqC4TyNL2JpPC54sr/AO5MzVLJCdbBRhkHqJ7BZMpzkGI0MVmh7E7oFUjGk2 oTTg== 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 :dkim-signature:arc-authentication-results; bh=mgb5Py2UNy1XoJ3M2i736gnIx9CsBNxZGqUEfwbFeSY=; b=z5rhQUZsmOkEbOq75d/9sKEahui+XikKfLXyMxyqv4ZIY/jo7LrQkR/kfW+HjISwkk FzMxnbFY3o3ybOeEXqu/rCN/BFVQhtWqqx5Ikkm/wyL+aAfldobuTWSzx78CytuGhXQm CzyxtpFoMcTWNsP0QuYIiB7TFMLkHbwpD0fbY9P2ZBg1xlTChWyVf6gTwTYfEgVklIEb azyDE/z7GwOnTNF7q66myAW6TbrR5An0qRjgbDfskTSFOXkhlJBqqY7/6O6VpQl4Lutw LlqQscsg7oNvBbcSmfrdcHmweb1pY4Wv95HcsAjMEx1gaGK7IV0/H7Y457jbFEFfPUjD s7pQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m5si1228654pli.193.2017.06.09.09.33.12; Fri, 09 Jun 2017 09:33:12 -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; dkim=pass header.i=@linaro.org; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751780AbdFIQcy (ORCPT + 25 others); Fri, 9 Jun 2017 12:32:54 -0400 Received: from mail-wr0-f176.google.com ([209.85.128.176]:36429 "EHLO mail-wr0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751701AbdFIQcw (ORCPT ); Fri, 9 Jun 2017 12:32:52 -0400 Received: by mail-wr0-f176.google.com with SMTP id v111so38819790wrc.3 for ; Fri, 09 Jun 2017 09:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=mgb5Py2UNy1XoJ3M2i736gnIx9CsBNxZGqUEfwbFeSY=; b=VHj+2AN9WhSmcP5gPXMijN5f+pizPWZf97fSD1+lQIhU+ATATusnF2Pe/OpjM8Kt67 npipLoiHGPJjXRh8FRFYWuOL2loZuZeOJLeL+3JTgg3hKEqLygCpRh/RmhwN16kc9L0q tAbDJUJeh8h6bbOcKqZFqirF+3f2zf96foM5A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=mgb5Py2UNy1XoJ3M2i736gnIx9CsBNxZGqUEfwbFeSY=; b=csVdMFGaAdZxaYXyWELtjDQlSsXxLxxQMhzc1XS9JbhfbQf5Ldq6UjxqueIjO1CwxM JJXtYjf+9O2hrBwmcK8MF+tpf/ixfNsqFlahVCXlM4EtLPb499I3YmxH3IaCL4EvUx48 SQoqxfdxuqZT+1/2Zd+MMAfB+1DV8v8O7OZD0Npt95h/Tf40dGpJXjpvFe5NwDmouxQO 9mk1u/U/8h0yae0L5jljfSzDYDilfebDhbJWmsc0T+rQxbOZJkjRJjUnEYd5Nkm2J9KF paTS3JXppaqaxjPRkN6Mhl92BzobmOg1Ewe2BntB90EdDxTsmRI/2je2sYHaFB/6KQh9 JU7w== X-Gm-Message-State: AKS2vOzkArW+7ESQZz62/bECh07A6fLO6kYUmqPl4LYPXYzdre3mlq3I rn9BzolxY3cezgbU X-Received: by 10.28.45.205 with SMTP id t196mr417054wmt.14.1497025959707; Fri, 09 Jun 2017 09:32:39 -0700 (PDT) Received: from localhost.localdomain ([160.168.49.111]) by smtp.gmail.com with ESMTPSA id m14sm211823wmi.2.2017.06.09.09.32.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 09:32:38 -0700 (PDT) From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org Cc: will.deacon@arm.com, mark.rutland@arm.com, Ard Biesheuvel Subject: [RFC PATCH] drivers/char: kmem: disable read/write if VMALLOC_START < PAGE_OFFSET Date: Fri, 9 Jun 2017 16:32:28 +0000 Message-Id: <20170609163228.446-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As it turns out, arm64 deviates from other architectures in the way it maps the VMALLOC region: on most (all?) other architectures, it resides strictly above the kernel's direct mapping of DRAM, but on arm64, this is the other way around. For instance, for a 48-bit VA configuration, we have modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB) vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB) ... vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum) 0xffff7e0000000000 - 0xffff7e0003ff0000 ( 63 MB actual) memory : 0xffff800000000000 - 0xffff8000ffc00000 ( 4092 MB) This has mostly gone unnoticed until now, but it does appear that it breaks an assumption in the kcore read/write code, which does something like if (p < (unsigned long) high_memory) { ... use straight copy_[to|from]_user() using p as virtual address ... } ... if (count > 0) { ... use vread/vwrite for accesses past high_memory ... } The first condition will inadvertently hold for the VMALLOC region if VMALLOC_START < PAGE_OFFSET, but the read/write will subsequently fail the virt_addr_valid() check, resulting in a -ENXIO return value. Given how kmem seems to be living in borrowed time anyway, and given the fact that nobody noticed that the read/write interface is broken on arm64 in the first place, let's not bother trying to fix it, but simply fail such calls with a warning if VMALLOC_START < PAGE_OFFSET. (Note that kmem's mmap() interface is not affected by this) Signed-off-by: Ard Biesheuvel --- This is just an RFC. There may be better ways to deal with this, including disabling /dev/kmem altogether on arm64. drivers/char/mem.c | 8 ++++++++ 1 file changed, 8 insertions(+) -- 2.9.3 diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 6e0cbe092220..c90ca6703dd5 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -408,6 +408,10 @@ static ssize_t read_kmem(struct file *file, char __user *buf, char *kbuf; /* k-addr because vread() takes vmlist_lock rwlock */ int err = 0; + /* the code below assumes VMALLOC_START > PAGE_OFFSET */ + if (WARN_ON_ONCE(VMALLOC_START < PAGE_OFFSET)) + return -ENXIO; + read = 0; if (p < (unsigned long) high_memory) { low_count = count; @@ -484,6 +488,10 @@ static ssize_t do_write_kmem(unsigned long p, const char __user *buf, ssize_t written, sz; unsigned long copied; + /* the code below assumes VMALLOC_START > PAGE_OFFSET */ + if (WARN_ON_ONCE(VMALLOC_START < PAGE_OFFSET)) + return -ENXIO; + written = 0; #ifdef __ARCH_HAS_NO_PAGE_ZERO_MAPPED /* we don't have page 0 mapped on sparc and m68k.. */