Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5140447pxu; Wed, 21 Oct 2020 14:50:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8o+JK4i6fx71V8QtcRgcB7Hynm4j2JP0aeKb2c2kSCfS5iTcHIYZaRQ7BELYAbPzodqEj X-Received: by 2002:a17:906:791:: with SMTP id l17mr5201731ejc.361.1603317047250; Wed, 21 Oct 2020 14:50:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603317047; cv=none; d=google.com; s=arc-20160816; b=TadeNfgKm1kbe2x+zpNJTfzpC82mCqcxy1XPM+XklLhWtVllVJGlI4Hjz/2pdlaZN6 fbSF5Zp/aLNW/hEIAsDVSZe3wP3323NLs5qTukP+geh+ztaCUe3rSbpTMEl6o7Pu9naE MIdcejwjdccQuzVeG45gBdbxH5IgXh/5RkzHrmhtlmQ5wGL9ZzzUSQyEqBRRplDEPuC6 dLF6Sl8FJQoWNmir57Lwa9j44I8afjpbinm4Hiud8xqey7a+KLbZu05IOr18Uj5KqK2d U7Q4gRodRu9vu/LRzS8w2BJZ5/FpKUHUplGLcuEJ2kcjoDnvd1rQ8uu2OdcbYfKYTk8w Y8cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=S+7ufuislqzXK0m1Ak/J4PVW8igwq369gehzbG0B91s=; b=Nh5y8clpqzu0LDi2+aJ3k8T2IwbaQAvjLPnJ/AESrqcPEMGuEiDlLP0FJUZqGFmy9y oNc+m7IZ59HZL/eJ3kXa8WBAUUg40/W8yYgAzYnn+OmVGohJpD6Bn+Un/s916aPzh3Hs Fo9Q+OmE9908YT5QzraHUGIWJ2H74eq40BF1OsHD4Vuz2sNgGXjkgqzmYJ4hgPMm3hWH /eOTtp8bchxSsIOPxS3hO6WYKWueT+pS0sFvZpA55Sn0Jr9k+SmgGzL+9esn97g4DfRe IFIxx1lxJITlFq7B1WmE+QvqP+uBLcwoKkLlHF/9xPaqbEXsc2E/BTeSRwWm5vIhVDhW 2Vwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=TASte01L; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k10si2244505edv.43.2020.10.21.14.50.24; Wed, 21 Oct 2020 14:50:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=TASte01L; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2502451AbgJUI6f (ORCPT + 99 others); Wed, 21 Oct 2020 04:58:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2441170AbgJUI5P (ORCPT ); Wed, 21 Oct 2020 04:57:15 -0400 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C6BFC0613D5 for ; Wed, 21 Oct 2020 01:57:15 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id h5so2080822wrv.7 for ; Wed, 21 Oct 2020 01:57:15 -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=S+7ufuislqzXK0m1Ak/J4PVW8igwq369gehzbG0B91s=; b=TASte01LfK3tJrNEskEJg0JBrkEwFReNqZJcsPAqw0ud/54iE3NFZPYAz4seclzObY 8qyaNJ7feKdYZc7R1FFJdgR6e4chx6xmBKBCGr9MetZUB65nJ+IYSxcj8fXdkIxAF9Wa 835vPJ0u8wjGgm4Lqk1+pFbsMYj81cW6UvpFg= 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=S+7ufuislqzXK0m1Ak/J4PVW8igwq369gehzbG0B91s=; b=R6UTZSuvDTBryysB3UrQ0vuSg9MrshtXStBfUmgBNN992+kst8JDYwgeScz3jOTLP7 kQXi7wpO6ykam3KhkG3vhX3YW7TXOrDZDY/HppnVvosU0GJeFXcFM3/4eB1TSJHdq16b 5unzZTRdVMlN+A8En6pM/BNefO6v5/TLNa6H/mHPn6HmLM5MXa8gkD8rKXLyOrmdv2G4 dV84Sz2cCs8nmExHgP6hRVLh3a7h0H1V/5/hKm2zYkof8fC4q43owElrqqbUqqVg3eHz 9OylsNIrCcXAJwka9A46BsbESzMj7FQ9tVpTlU2FtMAMMmr90I2+kVxlyDHoVNPUin3X EzbA== X-Gm-Message-State: AOAM530GB+/UtAGPL4VjHV/jQJUe9CvI1OBMy8XWqUbQjMZqLtdi9w+4 JG8Kixc7q3RD8m3MDZhi8dp5cw== X-Received: by 2002:a5d:6a4f:: with SMTP id t15mr3390316wrw.126.1603270634157; Wed, 21 Oct 2020 01:57:14 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id q8sm2675939wro.32.2020.10.21.01.57.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2020 01:57:13 -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 , Gerald Schaefer , Daniel Vetter , Jason Gunthorpe , Dan Williams , Kees Cook , Andrew Morton , John Hubbard , =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= , Jan Kara , Niklas Schnelle , Daniel Vetter Subject: [PATCH v3 08/16] s390/pci: Remove races against pte updates Date: Wed, 21 Oct 2020 10:56:47 +0200 Message-Id: <20201021085655.1192025-9-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20201021085655.1192025-1-daniel.vetter@ffwll.ch> References: <20201021085655.1192025-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Way back it was a reasonable assumptions that iomem mappings never change the pfn range they point at. But this has changed: - gpu drivers dynamically manage their memory nowadays, invalidating ptes with unmap_mapping_range when buffers get moved - contiguous dma allocations have moved from dedicated carvetouts to cma regions. This means if we miss the unmap the pfn might contain pagecache or anon memory (well anything allocated with GFP_MOVEABLE) - even /dev/mem now invalidates mappings when the kernel requests that iomem region when CONFIG_IO_STRICT_DEVMEM is set, see commit 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the region") Accessing pfns obtained from ptes without holding all the locks is therefore no longer a good idea. Fix this. Since zpci_memcpy_from|toio seems to not do anything nefarious with locks we just need to open code get_pfn and follow_pfn and make sure we drop the locks only after we're done. The write function also needs the copy_from_user move, since we can't take userspace faults while holding the mmap sem. v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL like before (Gerard) v3: Polish commit message (Niklas) Reviewed-by: Gerald Schaefer Signed-off-by: Daniel Vetter Cc: Jason Gunthorpe Cc: Dan Williams Cc: Kees Cook Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara 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: Niklas Schnelle Cc: Gerald Schaefer Cc: linux-s390@vger.kernel.org Cc: Niklas Schnelle Signed-off-by: Daniel Vetter --- arch/s390/pci/pci_mmio.c | 98 +++++++++++++++++++++++----------------- 1 file changed, 57 insertions(+), 41 deletions(-) diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c index 401cf670a243..1a6adbc68ee8 100644 --- a/arch/s390/pci/pci_mmio.c +++ b/arch/s390/pci/pci_mmio.c @@ -119,33 +119,15 @@ static inline int __memcpy_toio_inuser(void __iomem *dst, return rc; } -static long get_pfn(unsigned long user_addr, unsigned long access, - unsigned long *pfn) -{ - struct vm_area_struct *vma; - long ret; - - mmap_read_lock(current->mm); - ret = -EINVAL; - vma = find_vma(current->mm, user_addr); - if (!vma) - goto out; - ret = -EACCES; - if (!(vma->vm_flags & access)) - goto out; - ret = follow_pfn(vma, user_addr, pfn); -out: - mmap_read_unlock(current->mm); - return ret; -} - SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr, const void __user *, user_buffer, size_t, length) { u8 local_buf[64]; void __iomem *io_addr; void *buf; - unsigned long pfn; + struct vm_area_struct *vma; + pte_t *ptep; + spinlock_t *ptl; long ret; if (!zpci_is_enabled()) @@ -158,7 +140,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr, * We only support write access to MIO capable devices if we are on * a MIO enabled system. Otherwise we would have to check for every * address if it is a special ZPCI_ADDR and would have to do - * a get_pfn() which we don't need for MIO capable devices. Currently + * a pfn lookup which we don't need for MIO capable devices. Currently * ISM devices are the only devices without MIO support and there is no * known need for accessing these from userspace. */ @@ -176,21 +158,37 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr, } else buf = local_buf; - ret = get_pfn(mmio_addr, VM_WRITE, &pfn); + ret = -EFAULT; + if (copy_from_user(buf, user_buffer, length)) + goto out_free; + + mmap_read_lock(current->mm); + ret = -EINVAL; + vma = find_vma(current->mm, mmio_addr); + if (!vma) + goto out_unlock_mmap; + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) + goto out_unlock_mmap; + ret = -EACCES; + if (!(vma->vm_flags & VM_WRITE)) + goto out_unlock_mmap; + + ret = follow_pte_pmd(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl); if (ret) - goto out; - io_addr = (void __iomem *)((pfn << PAGE_SHIFT) | + goto out_unlock_mmap; + + io_addr = (void __iomem *)((pte_pfn(*ptep) << PAGE_SHIFT) | (mmio_addr & ~PAGE_MASK)); - ret = -EFAULT; if ((unsigned long) io_addr < ZPCI_IOMAP_ADDR_BASE) - goto out; - - if (copy_from_user(buf, user_buffer, length)) - goto out; + goto out_unlock_pt; ret = zpci_memcpy_toio(io_addr, buf, length); -out: +out_unlock_pt: + pte_unmap_unlock(ptep, ptl); +out_unlock_mmap: + mmap_read_unlock(current->mm); +out_free: if (buf != local_buf) kfree(buf); return ret; @@ -274,7 +272,9 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsigned long, mmio_addr, u8 local_buf[64]; void __iomem *io_addr; void *buf; - unsigned long pfn; + struct vm_area_struct *vma; + pte_t *ptep; + spinlock_t *ptl; long ret; if (!zpci_is_enabled()) @@ -287,7 +287,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsigned long, mmio_addr, * We only support read access to MIO capable devices if we are on * a MIO enabled system. Otherwise we would have to check for every * address if it is a special ZPCI_ADDR and would have to do - * a get_pfn() which we don't need for MIO capable devices. Currently + * a pfn lookup which we don't need for MIO capable devices. Currently * ISM devices are the only devices without MIO support and there is no * known need for accessing these from userspace. */ @@ -306,22 +306,38 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsigned long, mmio_addr, buf = local_buf; } - ret = get_pfn(mmio_addr, VM_READ, &pfn); + mmap_read_lock(current->mm); + ret = -EINVAL; + vma = find_vma(current->mm, mmio_addr); + if (!vma) + goto out_unlock_mmap; + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) + goto out_unlock_mmap; + ret = -EACCES; + if (!(vma->vm_flags & VM_WRITE)) + goto out_unlock_mmap; + + ret = follow_pte_pmd(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl); if (ret) - goto out; - io_addr = (void __iomem *)((pfn << PAGE_SHIFT) | (mmio_addr & ~PAGE_MASK)); + goto out_unlock_mmap; + + io_addr = (void __iomem *)((pte_pfn(*ptep) << PAGE_SHIFT) | + (mmio_addr & ~PAGE_MASK)); if ((unsigned long) io_addr < ZPCI_IOMAP_ADDR_BASE) { ret = -EFAULT; - goto out; + goto out_unlock_pt; } ret = zpci_memcpy_fromio(buf, io_addr, length); - if (ret) - goto out; - if (copy_to_user(user_buffer, buf, length)) + +out_unlock_pt: + pte_unmap_unlock(ptep, ptl); +out_unlock_mmap: + mmap_read_unlock(current->mm); + + if (!ret && copy_to_user(user_buffer, buf, length)) ret = -EFAULT; -out: if (buf != local_buf) kfree(buf); return ret; -- 2.28.0