From patchwork Tue Jun 20 06:59:00 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 105930 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1225452qgd; Mon, 19 Jun 2017 23:59:24 -0700 (PDT) X-Received: by 10.98.17.12 with SMTP id z12mr28938475pfi.212.1497941963927; Mon, 19 Jun 2017 23:59:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497941963; cv=none; d=google.com; s=arc-20160816; b=P1nt7G/B5SJQudRdO4S5fFd9ncNwnQaqFZgU+JI/BxtniBYlH1aZuDwtcKppKnEXxd zCBPq1GUTaIU4IKHGNT4FRHj0hZ9RDwo36ni9ZUHdG9USXqmTTW8Zh17BODVOVnECS6a FjmPJcUEt0JiCJNPJeabHsEV/d9XSuOAcy0TTzEbBlp+r7vDlmHubPByca9db3eC33Ff z5mjHbhzYEwDHTlYGEICErFQsjyqMFAcx3UVjIZEQ4nCYGrq8WmjG8tbKe6sbrXgMtGh 2FP61tHj71JuN3oFFTl+U3mrbLk3FReczaOYvsaKkrdZNHLUOR3EAsBhrS5km7FWZTm9 ZmXg== 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=vMzBTeZqbLFv8K0FzJZxj6PoQVEvqC4I/DoE6gow26s=; b=QFBg2syM0zwsWxU/r6wtBl18eI88YX7ohMEoi5IWb/sklcEzM+gfA+22F2eP2GfPL0 WYjpTWWx1/uN47MAJYXXWME1bmCImxLW9TxbZu1Q1A1niachuLYoGJdSnkTcnfovC6SR zcjAgVv+dQokzEistfNpb8JAObNih+BVyrC8crnmk404thBFkh8f57UEhvTCi0Y7MEh2 H9c1NIzquSWEdxImNjGvJcwAtnTYDsaqUxz6EfQbnYYyUC5H8/dK2VD21iobZG0ZvwG+ D1xd407Cdykb3QKGLbFB5g090J+T+vaLhfASKi39ShI/JITiUcIo7HBzuu3L7vY6wep3 gCiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=Ca/JAeTT; 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 s193si1360728pgc.360.2017.06.19.23.59.23; Mon, 19 Jun 2017 23:59:23 -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 header.b=Ca/JAeTT; 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 S1751656AbdFTG7H (ORCPT + 25 others); Tue, 20 Jun 2017 02:59:07 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:35463 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbdFTG7F (ORCPT ); Tue, 20 Jun 2017 02:59:05 -0400 Received: by mail-wm0-f48.google.com with SMTP id x70so12066287wme.0 for ; Mon, 19 Jun 2017 23:59:04 -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=vMzBTeZqbLFv8K0FzJZxj6PoQVEvqC4I/DoE6gow26s=; b=Ca/JAeTTjFJ17fp9nEtqGMFbSlgMosmGzds0xuCdjk3jqQ7L6d1EROYIrNXf6KHDOv bPdfvrg6La0/316WrQ6hD/0LRSGPoQ9YNcvUOhdJuo5MYOVD0pOseMIhrV7a/l7dNYRz Bu6uH+50ooJLMLUHenvNDm5AULZjqQz2VkNRY= 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=vMzBTeZqbLFv8K0FzJZxj6PoQVEvqC4I/DoE6gow26s=; b=rY7/qj2LSrL1wnw5mrKeAeEC6sezNb2ib3htc8uQCIoXzdoRaUmaSIXYkj0b8+g6oM C7VddWrW4ZjIGCD4lOtwyZdhWONLlkvvnyYIi1usD8PH8rcjCd9D1HCd2AtCopuskW5h RNWeHQhbVzgCOwCgUjdTfYg+A0lIM6MaGTEyPRT8sf2CriwaTaBSk7oEA3LEMKLdyK7m SYNlVc0h/tZ57UFtWfmXohVZqfr/dkjE8CrcLwjWbnLSaFDtzndLoJUT64087ZlJWJqs stLdnN/8aGDpI1VX++yp4PUHqb0urFfNZLMVZKUh4htjfJgLj4R1cVMgGfc6nTr+P0up FXVQ== X-Gm-Message-State: AKS2vOy9C5J8uBmbaM7VbRFsWTzr0NdZnLSF4ErrUmqRX0GyrNWwR3q7 ybhkKptLuwol7SJN X-Received: by 10.80.163.70 with SMTP id 64mr20466708edn.78.1497941943951; Mon, 19 Jun 2017 23:59:03 -0700 (PDT) Received: from localhost.localdomain (101-126-045-062.dynamic.caiway.nl. [62.45.126.101]) by smtp.gmail.com with ESMTPSA id f22sm6305827edf.59.2017.06.19.23.59.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Jun 2017 23:59:03 -0700 (PDT) From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, arnd@arndb.de, will.deacon@arm.com, mark.rutland@arm.com, gregkh@linuxfoundation.org Cc: Ard Biesheuvel Subject: [PATCH v3] drivers/char: kmem: disable on arm64 Date: Tue, 20 Jun 2017 08:59:00 +0200 Message-Id: <1497941940-2699-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 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 [which is the case on arm64], but the read or 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 disable the /dev/kmem interface entirely for arm64. Signed-off-by: Ard Biesheuvel --- v3: improve commit log v2: disable /dev/kmem entirely rather than bandaiding it drivers/char/Kconfig | 2 ++ 1 file changed, 2 insertions(+) -- 2.7.4 Acked-by: Mark Rutland diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 31adbebf812e..8102ee7b3247 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -17,6 +17,8 @@ config DEVMEM config DEVKMEM bool "/dev/kmem virtual device support" + # On arm64, VMALLOC_START < PAGE_OFFSET, which confuses kmem read/write + depends on !ARM64 help Say Y here if you want to support the /dev/kmem device. The /dev/kmem device is rarely used, but can be used for certain