From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AEE41C56201 for ; Wed, 4 Nov 2020 08:44:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 512C9208C7 for ; Wed, 4 Nov 2020 08:44:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="SO6a9eIH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728256AbgKDIoV (ORCPT ); Wed, 4 Nov 2020 03:44:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727812AbgKDIoT (ORCPT ); Wed, 4 Nov 2020 03:44:19 -0500 Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9A89C061A4D for ; Wed, 4 Nov 2020 00:44:15 -0800 (PST) Received: by mail-oi1-x244.google.com with SMTP id m13so12330220oih.8 for ; Wed, 04 Nov 2020 00:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ycqoIkcF9lPtiJBVMgjq7zwCX8Gyu6JCtVXT12jKTV8=; b=SO6a9eIH6r+EzFThZ6MTARjwHEtx6LFHOpOvFgwKmnw7LjZXHcgycyhZfUmdSwXoni 9VPCbgc6ODqmZSPJVN4eXwn3IqpRr3uXKNjrMKGfBOBHLutZLHhso+mS3OiPqxM7Q6/l K5a5NNqZWoxju2yJSN+OURI61y0XID3dk0Roo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ycqoIkcF9lPtiJBVMgjq7zwCX8Gyu6JCtVXT12jKTV8=; b=S8bCfPK0wQxdm37ulmQZGO0dGuJAcNZmiUcdEJTKLXw+NpY8QlJ0MlVAyLWghs1Tes rf3OjsMA/IS5cY9hp0QBm2kdGISo8+Qbj/AAlR6koOZSh/PesDnuZkkZ34rG2i3IaAEY qGlb98TpVcv5hny0B43TRg4WyOCpZzZlfe0/oWUHWqkIhZ7T6AAwIUj/BLsYMyh3Z+Cy HfrERmEgoj+5uZd6ds4NdoT/yYDLIwdgkaBgRsk6xTJelclePT575xq27RjmFdyYJB7M oK8aTYIdf5Obe7ntQdnhxpzexJQxHeEY3jshsBN96mIteWkqpC0PxQUaTsrw7iUZqzzw N3kA== X-Gm-Message-State: AOAM532RRWUDL6nt5A4psTeK9mDzrntrToob8qFzhTBpkBfaOTHUqQ5I sOgAgqsvRfEfsKNegap7tKpjMRhAQRQXM7C9MJ5Z+A== X-Google-Smtp-Source: ABdhPJzFeuCQlV5NJZ+3HUxdvXgtCAFGX/0rEF7qnn1uI6qUI3Z5/MsHqFAcH2CxUPAQE20CBPAAF7SeJ5phPHzYaRc= X-Received: by 2002:aca:b141:: with SMTP id a62mr1813813oif.101.1604479455139; Wed, 04 Nov 2020 00:44:15 -0800 (PST) MIME-Version: 1.0 References: <20201030100815.2269-12-daniel.vetter@ffwll.ch> <20201103212840.GA266427@bjorn-Precision-5520> In-Reply-To: From: Daniel Vetter Date: Wed, 4 Nov 2020 09:44:04 +0100 Message-ID: Subject: Re: [PATCH v5 11/15] PCI: Obey iomem restrictions for procfs mmap To: Dan Williams Cc: Bjorn Helgaas , DRI Development , LKML , KVM list , Linux MM , Linux ARM , linux-samsung-soc , "Linux-media@vger.kernel.org" , Daniel Vetter , Jason Gunthorpe , Kees Cook , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Bjorn Helgaas , Linux PCI Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 3, 2020 at 11:09 PM Dan Williams wrote: > On Tue, Nov 3, 2020 at 1:28 PM Bjorn Helgaas wrote: > > On Fri, Oct 30, 2020 at 11:08:11AM +0100, Daniel Vetter wrote: > > > There's three ways to access PCI BARs from userspace: /dev/mem, sysfs > > > files, and the old proc interface. Two check against > > > iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM, > > > this starts to matter, since we don't want random userspace having > > > access to PCI BARs while a driver is loaded and using it. > > > > > > Fix this by adding the same iomem_is_exclusive() check we already have > > > on the sysfs side in pci_mmap_resource(). > > > > > > References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges") > > > Signed-off-by: Daniel Vetter > > > > This is OK with me but it looks like IORESOURCE_EXCLUSIVE is currently > > only used in a few places: > > > > e1000_probe() calls pci_request_selected_regions_exclusive(), > > ne_pci_probe() calls pci_request_regions_exclusive(), > > vmbus_allocate_mmio() calls request_mem_region_exclusive() > > > > which raises the question of whether it's worth keeping > > IORESOURCE_EXCLUSIVE at all. I'm totally fine with removing it > > completely. > > Now that CONFIG_IO_STRICT_DEVMEM upgrades IORESOURCE_BUSY to > IORESOURCE_EXCLUSIVE semantics the latter has lost its meaning so I'd > be in favor of removing it as well. Still has some value since it enforces exclusive access even if the config isn't enabled, and iirc e1000 had some fun with userspace tools clobbering the firmware and bricking the chip. Another thing I kinda wondered, since pci maintainer is here: At least in drivers/gpu I see very few drivers explicitly requestion regions (this might be a historical artifact due to the shadow attach stuff before we had real modesetting drivers). And pci core doesn't do that either, even when a driver is bound. Is this intentional, or should/could we do better? Since drivers work happily without reserving regions I don't think "the drivers need to remember to do this" will ever really work out well. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6488FC2D0A3 for ; Wed, 4 Nov 2020 08:45:54 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CCF7B208C7 for ; Wed, 4 Nov 2020 08:45:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lswvbjsC"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="SO6a9eIH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CCF7B208C7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wdOK4GDe/WALeaQrTgi+M7ImQBbnHdnvSWMCBDEmbDg=; b=lswvbjsCvXncpOKIePe0k4jTI eSXIsTIvoGqcnrtxeT3MFoJH9sRKAqd5n9lWscpsO+jw4GlOePDoH6lt99kiRDM+cFHcBenceKHjm J5QY/In77OjghQ5y2YVd6oEPYTORaNmVCP/+G0iBgBCkxchVqUnMn1D4EhR+tRrHHawOtlNJE3w4D Iz0s6i76e1E4vzNgVBC1Y3Rcdtr2IERNHgncHmKgvxY/9JrCm4kQgJJfeDrq2H3pJewsrQuvPgNRi BnecF7+h518hii8WyDSKlut5A+YZiUZrjBdqHUY1who5rO7I+xGCN89kkdA6+mKmuh8PkUObUJ7+y X5laJAIHw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kaEP1-0001Tg-TM; Wed, 04 Nov 2020 08:44:24 +0000 Received: from mail-oi1-x243.google.com ([2607:f8b0:4864:20::243]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kaEOw-0001Pf-7j for linux-arm-kernel@lists.infradead.org; Wed, 04 Nov 2020 08:44:21 +0000 Received: by mail-oi1-x243.google.com with SMTP id s21so21443153oij.0 for ; Wed, 04 Nov 2020 00:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ycqoIkcF9lPtiJBVMgjq7zwCX8Gyu6JCtVXT12jKTV8=; b=SO6a9eIH6r+EzFThZ6MTARjwHEtx6LFHOpOvFgwKmnw7LjZXHcgycyhZfUmdSwXoni 9VPCbgc6ODqmZSPJVN4eXwn3IqpRr3uXKNjrMKGfBOBHLutZLHhso+mS3OiPqxM7Q6/l K5a5NNqZWoxju2yJSN+OURI61y0XID3dk0Roo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ycqoIkcF9lPtiJBVMgjq7zwCX8Gyu6JCtVXT12jKTV8=; b=HxOtZaVnNMWqu0o4wcdOvenTLT/5ywyfiLp9R8xWlIMiPz8JNUTEJlBBQAr8tQqlOq +ZeeWyT6k18t/7M7rUmwfpDkF3aIOGrEWKM+19BrH40AOz0pQllOo8GQ93PU4zWsgphj ohUJObVVmNCL+vJmCqNkF2F9UhxzRfsk884lU1vu/D44GWujTO23Mca6XMNhAsYQ6Qyr jzolwDQhLhEPEQCMOxUx7fs3yd6RNVQ3EwvcDAzxd//IL77+kTEIKggEssgmsmfEH5uF Wuh8HYfDQeDcUNe+qMBQ8sOVqQ2pycWbSsuGN6pC0DyEUAfdCxOp+Jc9rN8dQouHt05o 5xew== X-Gm-Message-State: AOAM533FiASzIEdIYsPkDqB8J6Zr+SQdLk32dIHDrhI3rjZYfL6w7tUH iVBsJ75/Cfqv6RyPlO77PVGEIvcM66yGKH87DWYcVA== X-Google-Smtp-Source: ABdhPJzFeuCQlV5NJZ+3HUxdvXgtCAFGX/0rEF7qnn1uI6qUI3Z5/MsHqFAcH2CxUPAQE20CBPAAF7SeJ5phPHzYaRc= X-Received: by 2002:aca:b141:: with SMTP id a62mr1813813oif.101.1604479455139; Wed, 04 Nov 2020 00:44:15 -0800 (PST) MIME-Version: 1.0 References: <20201030100815.2269-12-daniel.vetter@ffwll.ch> <20201103212840.GA266427@bjorn-Precision-5520> In-Reply-To: From: Daniel Vetter Date: Wed, 4 Nov 2020 09:44:04 +0100 Message-ID: Subject: Re: [PATCH v5 11/15] PCI: Obey iomem restrictions for procfs mmap To: Dan Williams X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201104_034418_608502_408A2793 X-CRM114-Status: GOOD ( 24.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-samsung-soc , Jan Kara , Kees Cook , KVM list , Jason Gunthorpe , John Hubbard , LKML , DRI Development , Linux MM , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Bjorn Helgaas , Linux PCI , Bjorn Helgaas , Daniel Vetter , Andrew Morton , Linux ARM , "Linux-media@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Nov 3, 2020 at 11:09 PM Dan Williams wrote: > On Tue, Nov 3, 2020 at 1:28 PM Bjorn Helgaas wrote: > > On Fri, Oct 30, 2020 at 11:08:11AM +0100, Daniel Vetter wrote: > > > There's three ways to access PCI BARs from userspace: /dev/mem, sysfs > > > files, and the old proc interface. Two check against > > > iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM, > > > this starts to matter, since we don't want random userspace having > > > access to PCI BARs while a driver is loaded and using it. > > > > > > Fix this by adding the same iomem_is_exclusive() check we already have > > > on the sysfs side in pci_mmap_resource(). > > > > > > References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges") > > > Signed-off-by: Daniel Vetter > > > > This is OK with me but it looks like IORESOURCE_EXCLUSIVE is currently > > only used in a few places: > > > > e1000_probe() calls pci_request_selected_regions_exclusive(), > > ne_pci_probe() calls pci_request_regions_exclusive(), > > vmbus_allocate_mmio() calls request_mem_region_exclusive() > > > > which raises the question of whether it's worth keeping > > IORESOURCE_EXCLUSIVE at all. I'm totally fine with removing it > > completely. > > Now that CONFIG_IO_STRICT_DEVMEM upgrades IORESOURCE_BUSY to > IORESOURCE_EXCLUSIVE semantics the latter has lost its meaning so I'd > be in favor of removing it as well. Still has some value since it enforces exclusive access even if the config isn't enabled, and iirc e1000 had some fun with userspace tools clobbering the firmware and bricking the chip. Another thing I kinda wondered, since pci maintainer is here: At least in drivers/gpu I see very few drivers explicitly requestion regions (this might be a historical artifact due to the shadow attach stuff before we had real modesetting drivers). And pci core doesn't do that either, even when a driver is bound. Is this intentional, or should/could we do better? Since drivers work happily without reserving regions I don't think "the drivers need to remember to do this" will ever really work out well. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3D47C388F7 for ; Wed, 4 Nov 2020 08:44:18 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 194D721556 for ; Wed, 4 Nov 2020 08:44:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="SO6a9eIH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 194D721556 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 77FB589E26; Wed, 4 Nov 2020 08:44:16 +0000 (UTC) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id CAFD889E26 for ; Wed, 4 Nov 2020 08:44:15 +0000 (UTC) Received: by mail-oi1-x244.google.com with SMTP id 9so21395613oir.5 for ; Wed, 04 Nov 2020 00:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ycqoIkcF9lPtiJBVMgjq7zwCX8Gyu6JCtVXT12jKTV8=; b=SO6a9eIH6r+EzFThZ6MTARjwHEtx6LFHOpOvFgwKmnw7LjZXHcgycyhZfUmdSwXoni 9VPCbgc6ODqmZSPJVN4eXwn3IqpRr3uXKNjrMKGfBOBHLutZLHhso+mS3OiPqxM7Q6/l K5a5NNqZWoxju2yJSN+OURI61y0XID3dk0Roo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ycqoIkcF9lPtiJBVMgjq7zwCX8Gyu6JCtVXT12jKTV8=; b=dGanibfMB/qAO+TBMPtC2ZEIXPvLS71CgRCRMXSL9ulVs+/V9SZTq2pIauD5K9VbSD mr0zxr4Gj3y0xpaRMM2ICwpxGr4C0mo8BX0sAOG+iAdMIIs60ffer7qrrLzxvIC2QBY0 k43JfW7L/leeT8ngTAWv9WaxwF+tUqfrOnJAaFPWXsKxJ1jqKNqNm+dSb10HBo390wtP uJ/kkKLPghSllvjZUUcUMmcdn9Q1cnDW8O7yAxyfIO2bh42xMZLF/OJ6V/PyDqyiLRZY GY3JQC6R02SE1VjlBHRmFmoHzK7nnJbJiyBhKUBB79e5aE38bgAT98ueXvOkZ70PritL Yjsw== X-Gm-Message-State: AOAM531g1/XGx7A9JDLLs11Fbor33cf4g2n71xeAb2soJ8cfqmylqGzK TpjgMysaMsK2UnvW6pDDlZpJxyVhfWt9eIwPGCjiNTN+eeDFag== X-Google-Smtp-Source: ABdhPJzFeuCQlV5NJZ+3HUxdvXgtCAFGX/0rEF7qnn1uI6qUI3Z5/MsHqFAcH2CxUPAQE20CBPAAF7SeJ5phPHzYaRc= X-Received: by 2002:aca:b141:: with SMTP id a62mr1813813oif.101.1604479455139; Wed, 04 Nov 2020 00:44:15 -0800 (PST) MIME-Version: 1.0 References: <20201030100815.2269-12-daniel.vetter@ffwll.ch> <20201103212840.GA266427@bjorn-Precision-5520> In-Reply-To: From: Daniel Vetter Date: Wed, 4 Nov 2020 09:44:04 +0100 Message-ID: Subject: Re: [PATCH v5 11/15] PCI: Obey iomem restrictions for procfs mmap To: Dan Williams X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-samsung-soc , Jan Kara , Kees Cook , KVM list , Jason Gunthorpe , John Hubbard , LKML , DRI Development , Linux MM , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Bjorn Helgaas , Linux PCI , Bjorn Helgaas , Daniel Vetter , Andrew Morton , Linux ARM , "Linux-media@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Nov 3, 2020 at 11:09 PM Dan Williams wrote: > On Tue, Nov 3, 2020 at 1:28 PM Bjorn Helgaas wrote: > > On Fri, Oct 30, 2020 at 11:08:11AM +0100, Daniel Vetter wrote: > > > There's three ways to access PCI BARs from userspace: /dev/mem, sysfs > > > files, and the old proc interface. Two check against > > > iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM, > > > this starts to matter, since we don't want random userspace having > > > access to PCI BARs while a driver is loaded and using it. > > > > > > Fix this by adding the same iomem_is_exclusive() check we already have > > > on the sysfs side in pci_mmap_resource(). > > > > > > References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges") > > > Signed-off-by: Daniel Vetter > > > > This is OK with me but it looks like IORESOURCE_EXCLUSIVE is currently > > only used in a few places: > > > > e1000_probe() calls pci_request_selected_regions_exclusive(), > > ne_pci_probe() calls pci_request_regions_exclusive(), > > vmbus_allocate_mmio() calls request_mem_region_exclusive() > > > > which raises the question of whether it's worth keeping > > IORESOURCE_EXCLUSIVE at all. I'm totally fine with removing it > > completely. > > Now that CONFIG_IO_STRICT_DEVMEM upgrades IORESOURCE_BUSY to > IORESOURCE_EXCLUSIVE semantics the latter has lost its meaning so I'd > be in favor of removing it as well. Still has some value since it enforces exclusive access even if the config isn't enabled, and iirc e1000 had some fun with userspace tools clobbering the firmware and bricking the chip. Another thing I kinda wondered, since pci maintainer is here: At least in drivers/gpu I see very few drivers explicitly requestion regions (this might be a historical artifact due to the shadow attach stuff before we had real modesetting drivers). And pci core doesn't do that either, even when a driver is bound. Is this intentional, or should/could we do better? Since drivers work happily without reserving regions I don't think "the drivers need to remember to do this" will ever really work out well. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel