From patchwork Tue Nov 9 02:35:53 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12609577 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79298C433F5 for ; Tue, 9 Nov 2021 02:35:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 23E2A619A6 for ; Tue, 9 Nov 2021 02:35:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 23E2A619A6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BC1756B0110; Mon, 8 Nov 2021 21:35:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B497D6B0111; Mon, 8 Nov 2021 21:35:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A11B66B0112; Mon, 8 Nov 2021 21:35:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0106.hostedemail.com [216.40.44.106]) by kanga.kvack.org (Postfix) with ESMTP id 8894A6B0111 for ; Mon, 8 Nov 2021 21:35:55 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 51AD87889C for ; Tue, 9 Nov 2021 02:35:55 +0000 (UTC) X-FDA: 78787826670.10.9BC4CF1 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf17.hostedemail.com (Postfix) with ESMTP id F2D02F0007AF for ; Tue, 9 Nov 2021 02:35:54 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id D6A25619BB; Tue, 9 Nov 2021 02:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1636425354; bh=x/2M/nFRhAByDW8f0OwzqySNc8QpWV6+Ngkvq3tu6NM=; h=Date:From:To:Subject:In-Reply-To:From; b=zQMKaDoKvTh9QUq5/Ju2oyVb3IaQ9ptW8MA4WF8icqTcXSfsO0NYaYlEy0QE7wxLW MAznVhRlR+UAT7xr6XF5agVLDyu+voV1mh20f424wc3hIJE3lJ4l7vHY83yLD+Arvo HwoPNln2WZxCKlpRxnlXaHtN+W/Pp2I5A/KixhLk= Date: Mon, 08 Nov 2021 18:35:53 -0800 From: Andrew Morton To: akpm@linux-foundation.org, andy.shevchenko@gmail.com, arnd@arndb.de, dan.j.williams@intel.com, david@redhat.com, gregkh@linuxfoundation.org, guohanjun@huawei.com, jasowang@redhat.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, mst@redhat.com, rafael.j.wysocki@intel.com, torvalds@linux-foundation.org Subject: [patch 84/87] virtio-mem: disallow mapping virtio-mem memory via /dev/mem Message-ID: <20211109023553.XYnDzjGJh%akpm@linux-foundation.org> In-Reply-To: <20211108183057.809e428e841088b657a975ec@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: F2D02F0007AF X-Stat-Signature: xy3t3mrm11tzn978spmof9s5jk9dfkrx Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=zQMKaDoK; dmarc=none; spf=pass (imf17.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1636425354-737232 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: David Hildenbrand Subject: virtio-mem: disallow mapping virtio-mem memory via /dev/mem We don't want user space to be able to map virtio-mem device memory directly (e.g., via /dev/mem) in order to have guarantees that in a sane setup we'll never accidentially access unplugged memory within the device-managed region of a virtio-mem device, just as required by the virtio-spec. As soon as the virtio-mem driver is loaded, the device region is visible in /proc/iomem via the parent device region. From that point on user space is aware of the device region and we want to disallow mapping anything inside that region (where we will dynamically (un)plug memory) until the driver has been unloaded cleanly and e.g., another driver might take over. By creating our parent IORESOURCE_SYSTEM_RAM resource with IORESOURCE_EXCLUSIVE, we will disallow any /dev/mem access to our device region until the driver was unloaded cleanly and removed the parent region. This will work even though only some memory blocks are actually currently added to Linux and appear as busy in the resource tree. So access to the region from user space is only possible a) if we don't load the virtio-mem driver. b) after unloading the virtio-mem driver cleanly. Don't build virtio-mem if access to /dev/mem cannot be restricticted -- if we have CONFIG_DEVMEM=y but CONFIG_STRICT_DEVMEM is not set. Link: https://lkml.kernel.org/r/20210920142856.17758-4-david@redhat.com Signed-off-by: David Hildenbrand Reviewed-by: Dan Williams Acked-by: Michael S. Tsirkin Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Hanjun Guo Cc: Jason Wang Cc: "Rafael J. Wysocki" Signed-off-by: Andrew Morton --- drivers/virtio/Kconfig | 1 + drivers/virtio/virtio_mem.c | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) --- a/drivers/virtio/Kconfig~virtio-mem-disallow-mapping-virtio-mem-memory-via-dev-mem +++ a/drivers/virtio/Kconfig @@ -101,6 +101,7 @@ config VIRTIO_MEM depends on MEMORY_HOTPLUG depends on MEMORY_HOTREMOVE depends on CONTIG_ALLOC + depends on EXCLUSIVE_SYSTEM_RAM help This driver provides access to virtio-mem paravirtualized memory devices, allowing to hotplug and hotunplug memory. --- a/drivers/virtio/virtio_mem.c~virtio-mem-disallow-mapping-virtio-mem-memory-via-dev-mem +++ a/drivers/virtio/virtio_mem.c @@ -2672,8 +2672,10 @@ static int virtio_mem_create_resource(st if (!name) return -ENOMEM; + /* Disallow mapping device memory via /dev/mem completely. */ vm->parent_resource = __request_mem_region(vm->addr, vm->region_size, - name, IORESOURCE_SYSTEM_RAM); + name, IORESOURCE_SYSTEM_RAM | + IORESOURCE_EXCLUSIVE); if (!vm->parent_resource) { kfree(name); dev_warn(&vm->vdev->dev, "could not reserve device region\n");