From patchwork Thu Sep 29 07:22:32 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Huacai Chen X-Patchwork-Id: 12993627 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D33A0C6FA82 for ; Thu, 29 Sep 2022 07:23:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 31C646B0073; Thu, 29 Sep 2022 03:23:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2CBC68D0001; Thu, 29 Sep 2022 03:23:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BBA16B0075; Thu, 29 Sep 2022 03:23:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0E7AB6B0073 for ; Thu, 29 Sep 2022 03:23:53 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C9D051A1010 for ; Thu, 29 Sep 2022 07:23:52 +0000 (UTC) X-FDA: 79964283504.23.68BC8A2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id 29115C0010 for ; Thu, 29 Sep 2022 07:23:51 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1AE0E6202F; Thu, 29 Sep 2022 07:23:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80465C433D6; Thu, 29 Sep 2022 07:23:47 +0000 (UTC) From: Huacai Chen To: Arnd Bergmann , Huacai Chen Cc: loongarch@lists.linux.dev, linux-arch@vger.kernel.org, Xuefeng Li , Guo Ren , Xuerui Wang , Jiaxun Yang , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huacai Chen , Weihao Li Subject: [PATCH V2] LoongArch: Support access filter to /dev/mem interface Date: Thu, 29 Sep 2022 15:22:32 +0800 Message-Id: <20220929072232.562727-1-chenhuacai@loongson.cn> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of "SRS0=QehY=2A=loongson.cn=chenhuacai@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=QehY=2A=loongson.cn=chenhuacai@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664436232; a=rsa-sha256; cv=none; b=6oWfNi69dTIFU5yMQN7Zw3CtVWqN3e2kK/7NMaGa9VrzB/B9l5wYtQzlrrgkhNWCsk66Pu tgfP34YDIVip3W+OCUGXmQRTXgEMWbVd01WdQBWTAinr1UKCHetGhXvkoTNrrVQAHWMJpn r52MYTDZondVer92Z64HYd5mZsHkN7o= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664436232; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references; bh=aBZgcQ3xRlSDTTZ5sPelJmMypjPDL0q+pOX01IqTY4w=; b=3vPj3PR0hJMPPc4zKktQvDaTmL/DPsm0EYqcdJFV6/GDJNio/sPmpClWL2caZtb/joEX+D KE7Pa/2YDw+nJdlfENBeNbPddg2UF251yO+AqGF7yBrohhe2nw1vjek7DRxChOqJ2DZaUi sajrNQxFAU96lmqYp0wHgucUzLEBrTQ= Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of "SRS0=QehY=2A=loongson.cn=chenhuacai@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=QehY=2A=loongson.cn=chenhuacai@kernel.org" X-Rspam-User: X-Stat-Signature: 7n71r85b9cbpknr7ugqhpsyw1mr6px83 X-Rspamd-Queue-Id: 29115C0010 X-Rspamd-Server: rspam05 X-HE-Tag: 1664436231-209582 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: Accidental access to /dev/mem is obviously disastrous, but specific access can be used by people debugging the kernel. So select GENERIC_ LIB_DEVMEM_IS_ALLOWED, as well as define ARCH_HAS_VALID_PHYS_ADDR_RANGE and related helpers, to support access filter to /dev/mem interface. Signed-off-by: Weihao Li Signed-off-by: Huacai Chen --- V2: Fix build warnings reported by kernel test robot. arch/loongarch/Kconfig | 1 + arch/loongarch/include/asm/io.h | 4 ++++ arch/loongarch/mm/mmap.c | 29 +++++++++++++++++++++++++++++ 3 files changed, 34 insertions(+) diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig index fcb5f9489ffd..9c36eb29096a 100644 --- a/arch/loongarch/Kconfig +++ b/arch/loongarch/Kconfig @@ -70,6 +70,7 @@ config LOONGARCH select GENERIC_LIB_CMPDI2 select GENERIC_LIB_LSHRDI3 select GENERIC_LIB_UCMPDI2 + select GENERIC_LIB_DEVMEM_IS_ALLOWED select GENERIC_PCI_IOMAP select GENERIC_SCHED_CLOCK select GENERIC_SMP_IDLE_THREAD diff --git a/arch/loongarch/include/asm/io.h b/arch/loongarch/include/asm/io.h index 999944ea1cea..398d1a7b3dd6 100644 --- a/arch/loongarch/include/asm/io.h +++ b/arch/loongarch/include/asm/io.h @@ -107,4 +107,8 @@ extern void __memcpy_fromio(void *to, const volatile void __iomem *from, size_t #include +#define ARCH_HAS_VALID_PHYS_ADDR_RANGE +extern int valid_phys_addr_range(phys_addr_t addr, size_t size); +extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size); + #endif /* _ASM_IO_H */ diff --git a/arch/loongarch/mm/mmap.c b/arch/loongarch/mm/mmap.c index 381a569635a9..fbe1a4856fc4 100644 --- a/arch/loongarch/mm/mmap.c +++ b/arch/loongarch/mm/mmap.c @@ -3,6 +3,8 @@ * Copyright (C) 2020-2022 Loongson Technology Corporation Limited */ #include +#include +#include #include #include @@ -116,3 +118,30 @@ int __virt_addr_valid(volatile void *kaddr) return pfn_valid(PFN_DOWN(PHYSADDR(kaddr))); } EXPORT_SYMBOL_GPL(__virt_addr_valid); + +/* + * You really shouldn't be using read() or write() on /dev/mem. This might go + * away in the future. + */ +int valid_phys_addr_range(phys_addr_t addr, size_t size) +{ + /* + * Check whether addr is covered by a memory region without the + * MEMBLOCK_NOMAP attribute, and whether that region covers the + * entire range. In theory, this could lead to false negatives + * if the range is covered by distinct but adjacent memory regions + * that only differ in other attributes. However, few of such + * attributes have been defined, and it is debatable whether it + * follows that /dev/mem read() calls should be able traverse + * such boundaries. + */ + return memblock_is_region_memory(addr, size) && memblock_is_map_memory(addr); +} + +/* + * Do not allow /dev/mem mappings beyond the supported physical range. + */ +int valid_mmap_phys_addr_range(unsigned long pfn, size_t size) +{ + return !(((pfn << PAGE_SHIFT) + size) & ~(GENMASK_ULL(cpu_pabits, 0))); +}