From patchwork Wed Oct 7 16:44:23 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 11821179 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 26D8014D5 for ; Wed, 7 Oct 2020 16:45:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0101C21582 for ; Wed, 7 Oct 2020 16:45:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="BrDuHver" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728806AbgJGQpi (ORCPT ); Wed, 7 Oct 2020 12:45:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728503AbgJGQou (ORCPT ); Wed, 7 Oct 2020 12:44:50 -0400 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C94B9C0613D7 for ; Wed, 7 Oct 2020 09:44:48 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id p15so3042273wmi.4 for ; Wed, 07 Oct 2020 09:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=nwvirki0A8lJPE+AYl74w0fQ2EaO5tAbqC5bxM8kl0c=; b=BrDuHver6w7p5ZRQIzaxr9X28nldTZHPs6TeyR3rufkPUprK+7Pd7YvnCY9V+/ntoj rZAaEGBxdMEd6l9H14pKva/3vm5MWV5Hx2NleOTAHYs4Cd1KzpFCG+Sm6tIWC/JSTsWT wFRHzHOiKTlq+UBh4t8T/9Kw/KRf+ey2pudIg= 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=nwvirki0A8lJPE+AYl74w0fQ2EaO5tAbqC5bxM8kl0c=; b=P0xMP/avrLVtCoeTVdjQObv9Dq43h3kxPAtjIwz6+n1MeoNCYDYkxbil807GXIZNDs 9zhl6BnYe+4MpwgMBh9xBQ5BbXeiHUbtpo2CKHhbkNaNUCE8BgeWBZYkruw9eeMQbasS nDV08mKO4i0jIR3+PnYbpZnHDT3rLIY5wQ16CGjQa0oxgmY3TCXPAVVZ9LGM/3bkMMiE ESJSKbbsNI2S2AvFiF9OP2KaOw9VOnIWwziygdoFwIsReUJsQ9c0Dw7PsHbdW2ix7GO4 ZDStYmpAgxU4ngv0svIdDrVBSDxyie/pxtCb5U2h0XSDP9MdvnYUDGe1h53tGNcXD0a7 e6dA== X-Gm-Message-State: AOAM531TOCu5FoSPAD1BYVvMO1yRJTibBnTB1V2EuRfTLZWKHmtKpI3K mRHrjge27Ij3r1Kfzxs03tzL3w== X-Google-Smtp-Source: ABdhPJw1zUoIbUqRt+OcQIxyRCGoJAtVTtOUoH3PCLKd4mzA2jl8YcAArzeHuhJ7i3WhTCjkjS4Rxg== X-Received: by 2002:a7b:c08c:: with SMTP id r12mr4042397wmh.184.1602089087475; Wed, 07 Oct 2020 09:44:47 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id z191sm3332280wme.40.2020.10.07.09.44.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2020 09:44:46 -0700 (PDT) From: Daniel Vetter To: DRI Development , LKML Cc: kvm@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org, linux-s390@vger.kernel.org, Daniel Vetter , Daniel Vetter , Jason Gunthorpe , Kees Cook , Dan Williams , Andrew Morton , John Hubbard , =?utf-8?b?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Bjorn Helgaas , linux-pci@vger.kernel.org Subject: [PATCH 10/13] PCI: revoke mappings like devmem Date: Wed, 7 Oct 2020 18:44:23 +0200 Message-Id: <20201007164426.1812530-11-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20201007164426.1812530-1-daniel.vetter@ffwll.ch> References: <20201007164426.1812530-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the region") /dev/kmem zaps ptes when the kernel requests exclusive acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is the default for all driver uses. Except there's two more ways to access pci bars: sysfs and proc mmap support. Let's plug that hole. For revoke_devmem() to work we need to link our vma into the same address_space, with consistent vma->vm_pgoff. ->pgoff is already adjusted, because that's how (io_)remap_pfn_range works, but for the mapping we need to adjust vma->vm_file->f_mapping. Usually that's done at ->open time, but that's a bit tricky here with all the entry points and arch code. So instead create a fake file and adjust vma->vm_file. Note this only works for ARCH_GENERIC_PCI_MMAP_RESOURCE. But that seems to be a subset of architectures support STRICT_DEVMEM, so we should be good. The only difference in access checks left is that sysfs pci mmap does not check for CAP_RAWIO. But I think that makes some sense compared to /dev/mem and proc, where one file gives you access to everything and no ownership applies. Signed-off-by: Daniel Vetter Cc: Jason Gunthorpe Cc: Kees Cook Cc: Dan Williams Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: Bjorn Helgaas Cc: linux-pci@vger.kernel.org --- drivers/char/mem.c | 16 +++++++++++++++- drivers/pci/mmap.c | 3 +++ include/linux/ioport.h | 2 ++ 3 files changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/char/mem.c b/drivers/char/mem.c index abd4ffdc8cde..5e58a326d4ee 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -810,6 +810,7 @@ static loff_t memory_lseek(struct file *file, loff_t offset, int orig) } static struct inode *devmem_inode; +static struct vfsmount *devmem_vfs_mount; #ifdef CONFIG_IO_STRICT_DEVMEM void revoke_devmem(struct resource *res) @@ -843,6 +844,20 @@ void revoke_devmem(struct resource *res) unmap_mapping_range(inode->i_mapping, res->start, resource_size(res), 1); } + +struct file *devmem_getfile(void) +{ + struct file *file; + + file = alloc_file_pseudo(devmem_inode, devmem_vfs_mount, "devmem", + O_RDWR, &kmem_fops); + if (IS_ERR(file)) + return NULL; + + file->f_mapping = devmem_indoe->i_mapping; + + return file; +} #endif static int open_port(struct inode *inode, struct file *filp) @@ -1010,7 +1025,6 @@ static struct file_system_type devmem_fs_type = { static int devmem_init_inode(void) { - static struct vfsmount *devmem_vfs_mount; static int devmem_fs_cnt; struct inode *inode; int rc; diff --git a/drivers/pci/mmap.c b/drivers/pci/mmap.c index b8c9011987f4..63786cc9c746 100644 --- a/drivers/pci/mmap.c +++ b/drivers/pci/mmap.c @@ -7,6 +7,7 @@ * Author: David Woodhouse */ +#include #include #include #include @@ -64,6 +65,8 @@ int pci_mmap_resource_range(struct pci_dev *pdev, int bar, vma->vm_pgoff += (pci_resource_start(pdev, bar) >> PAGE_SHIFT); vma->vm_ops = &pci_phys_vm_ops; + fput(vma->vm_file); + vma->vm_file = devmem_getfile(); return io_remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, vma->vm_end - vma->vm_start, diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 6c2b06fe8beb..83238cba19fe 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -304,8 +304,10 @@ struct resource *request_free_mem_region(struct resource *base, #ifdef CONFIG_IO_STRICT_DEVMEM void revoke_devmem(struct resource *res); +struct file *devm_getfile(void); #else static inline void revoke_devmem(struct resource *res) { }; +static inline struct file *devmem_getfile(void) { return NULL; }; #endif #endif /* __ASSEMBLY__ */