From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A55CD17E918; Tue, 5 Nov 2024 16:27:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730824024; cv=none; b=YFqX7W8kYZF798V2VWpFemDmLzQYCZasEjdXIYrUIOA5Lx07JoOp/S497gPkEJIzW6h06nYwFHR3sckvizavgqAT8lB8w3bCMZNIqhDbQ4ifVLyec8nuwZcKzmIu74DEcJiPjsD9sk8++RlY10H7R0YUoml4njfmCA2zkamZtVs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730824024; c=relaxed/simple; bh=zLwVcEjh9yWNXilTeR+g455DWA7UySuShh8IESXwvGY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Kg6VDPHaXLaNMxqSkH6m3dk7eYKhoigQAC0z2NuRykAVMZR9uhKGjmhz5DvJ+tQRfXH2Aug4rqnhQM8hz175HQUO7vnyhrI4Gpy+4xJujWS1GC2Yg/YQW3FN2DN8Wwv90Fd9g7LKsMNJF3eQfU/iUczXOpU1OYx4CZR/MQS+coI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l2GqNkwT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="l2GqNkwT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED80DC4CECF; Tue, 5 Nov 2024 16:27:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730824024; bh=zLwVcEjh9yWNXilTeR+g455DWA7UySuShh8IESXwvGY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=l2GqNkwTrMZhZ1ZDZUSs6eFUDXePYn9gzOno71yKgNycLbkXK8TsDEvRwPATmJALs q0YU9s3xAXUMCDuGIJ1DBak4vL0uKKGqRioqKNMwYRoQghkAGRnAQNlmQReIFNs2oA xYODkhIej1U8k31XPM1prEcuiuFyOBQZAHqs0J7ajR4N+CyDCpxtZGs9e3SRyaiLOW 9YdvNRK8sgLH1IiQVmB2fpDoTrM8Myfq19GjVSdppzPNIb+QcOQBgZC8+BAjgAtYP1 5DcmSEn7T2VDz9rn1xTK/5ZIBCw0ffjrKnNVGWfI/XrHpC7OKzHShgrSrboAVlq/6B X6t/zNfDelveg== Date: Tue, 5 Nov 2024 18:26:55 +0200 From: Leon Romanovsky To: Bjorn Helgaas Cc: Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , linux-pci@vger.kernel.org, Ariel Almog , Aditya Prabhune , Hannes Reinecke , Heiner Kallweit , Arun Easi , Jonathan Chocron , Bert Kenward , Matt Carlson , Kai-Heng Feng , Jean Delvare , Alex Williamson , linux-kernel@vger.kernel.org Subject: Re: [PATCH] PCI/sysfs: Fix read permissions for VPD attributes Message-ID: <20241105162655.GG311159@unreal> References: <20241105075130.GD311159@unreal> <20241105152455.GA1472398@bhelgaas> Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241105152455.GA1472398@bhelgaas> On Tue, Nov 05, 2024 at 09:24:55AM -0600, Bjorn Helgaas wrote: > On Tue, Nov 05, 2024 at 09:51:30AM +0200, Leon Romanovsky wrote: > > On Mon, Nov 04, 2024 at 06:10:27PM -0600, Bjorn Helgaas wrote: > > > On Sun, Nov 03, 2024 at 02:33:44PM +0200, Leon Romanovsky wrote: > > > > On Fri, Nov 01, 2024 at 11:47:37AM -0500, Bjorn Helgaas wrote: > > > > > On Fri, Nov 01, 2024 at 04:33:00PM +0200, Leon Romanovsky wrote: > > > > > > On Thu, Oct 31, 2024 at 06:22:52PM -0500, Bjorn Helgaas wrote: > > > > > > > On Tue, Oct 29, 2024 at 07:04:50PM -0500, Bjorn Helgaas wrote: > > > > > > > > On Mon, Oct 28, 2024 at 10:05:33AM +0200, Leon Romanovsky wrote: > > > > > > > > > From: Leon Romanovsky > > > > > > > > > > > > > > > > > > The Virtual Product Data (VPD) attribute is not > > > > > > > > > readable by regular user without root permissions. > > > > > > > > > Such restriction is not really needed, as data > > > > > > > > > presented in that VPD is not sensitive at all. > > > > > > > > > > > > > > > > > > This change aligns the permissions of the VPD > > > > > > > > > attribute to be accessible for read by all users, > > > > > > > > > while write being restricted to root only. > > ... > > > > What's the use case? How does an unprivileged user use the VPD > > > information? > > > > We have to add new field keyword=value in VA section of VPD, which > > will indicate very specific sub-model for devices used as a bridge. > > > > > I can certainly imagine using VPD for bug reporting, but that > > > would typically involve dmesg, dmidecode, lspci -vv, etc, all of > > > which already require privilege, so it's not clear to me how > > > public VPD info would help in that scenario. > > > > I'm targeting other scenario - monitoring tool, which doesn't need > > root permissions for reading data. It needs to distinguish between > > NIC sub-models. > > Maybe the driver could expose something in sysfs? Maybe the driver > needs to know the sub-model as well, and reading VPD once in the > driver would make subsequent userspace sysfs reads trivial and fast. Our PCI driver lays in netdev subsystem and they have long-standing position do not allow any custom sysfs files. To be fair, we (RDMA) don't allow custom sysfs files too. Driver doesn't need to know this information as it is extra key=value in existing [VA] field, while driver relies on multiple FW capabilities to enable/disable functionality. Current [VA] line: "[VA] Vendor specific: MLX:MN=MLNX:CSKU=V2:UUID=V3:PCI=V0:MODL=CX713106A" Future [VA] line: "[VA] Vendor specific: MLX:MN=MLNX:CSKU=V2:UUID=V3:PCI=V0:MODL=CX713106A,SMDL=SOMETHING" Also the idea that we will duplicate existing functionality doesn't sound like a good approach to me, and there is no way that it is possible to expose as subsystem specific file. What about to allow existing VPD sysfs file to be readable for everyone for our devices? And if this allow list grows to much, we will open it for all devices in the world? Thanks > > Bjorn