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;
Date:   Fri, 16 Oct 2020 08:20:27 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Allen Pais <allen.lkml@gmail.com>
Cc:     linux-pci@vger.kernel.org, bhelgaas@google.com, ast@kernel.org,
        linux-kernel@vger.kernel.org,
        Allen Pais <apais@linux.microsoft.com>,
        Allen Pais <allen.pais@lkml.com>
Subject: Re: [RFC] PCI: allow sysfs file owner to read the config space with
 CAP_SYS_RAWIO
Message-ID: <20201016062027.GB569795@kroah.com>
References: <20201016055235.440159-1-allen.lkml@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201016055235.440159-1-allen.lkml@gmail.com>
Precedence: bulk

On Fri, Oct 16, 2020 at 11:22:35AM +0530, Allen Pais wrote:
> From: Allen Pais <apais@linux.microsoft.com>
> 
>  Access to pci config space is explictly checked with CAP_SYS_ADMIN
> in order to read configuration space past the frist 64B.
> 
>  Since the path is only for reading, could we use CAP_SYS_RAWIO?

Why?  What needs this reduced capability?

> This patch contains a simpler fix, I would love to hear from the
> Maintainers on the approach.
> 
>  The other approach that I considered was to introduce and API
> which would check for multiple capabilities, something similar to
> perfmon_capable()/bpf_capable(). But I could not find more users
> for the API and hence dropped it.
> 
>  The problem I am trying to solve is to avoid handing out
> CAP_SYS_ADMIN for extended reads of the PCI config space.

Who is reading this config space that doesn't have admin rights?  And
what are they doing with it?

One big problem is that some devices will crash if you do this wrong,
which is why we restricted it to root.  Hopefully all of those devices
are now gone, but I don't think you can count on it.

The "guaranteed safe" fields in the config space are already exported by
sysfs for all users to read, are they not sufficient?

thanks,

greg k-h