netdev - Re: [PATCH net-next 1/2] devlink: Add support to set port function as trusted

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d0df87e28497a697cae6cd6f03c00d42bc24d764.camel@nvidia.com>
Date:   Wed, 15 Dec 2021 18:19:16 +0000
From:   Saeed Mahameed <saeedm@...dia.com>
To:     "kuba@...nel.org" <kuba@...nel.org>
CC:     Parav Pandit <parav@...dia.com>, Jiri Pirko <jiri@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Sunil Sudhakar Rani <sunrani@...dia.com>,
        Bodong Wang <bodong@...dia.com>
Subject: Re: [PATCH net-next 1/2] devlink: Add support to set port function as
 trusted

On Thu, 2021-12-02 at 09:31 -0800, Jakub Kicinski wrote:
> On Wed, 1 Dec 2021 07:07:05 +0000 Saeed Mahameed wrote:
> > On Tue, 2021-11-30 at 19:12 -0800, Jakub Kicinski wrote:
> > > On Tue, 30 Nov 2021 22:17:29 +0000 Sunil Sudhakar Rani wrote:  
> > > > Sorry for the late response. We agree that the current
> > > > definition
> > > > is vague.
> > > > 
> > > > What we meant is that the enforcement is done by device/FW.
> > > > We simply want to allow VF/SF to access privileged or
> > > > restricted
> > > > resource such as physical port counters.
> > > > So how about defining the api such that:
> > > > This knob allows the VF/SF to access restricted resource such
> > > > as
> > > > physical port counters.  
> > > 
> > > You need to say more about the use case, I don't understand 
> > > what you're doing.  
> > 
> > Some device features/registers/units are not available by default
> > to
> > VFs/SFs (e.g restricted), examples are: physical port
> > registers/counters and similar global attributes.
> > 
> > Some customers want to use SF/VF in specialized VM/container for
> > management and monitoring, thus they want SF/VF to have similar
> > privileges to PF in terms of access to restricted resources.
> > 
> > Note: this doesn't break the sriov/sf model, trusted SF/VF will not
> > be
> > allowed to alter device attributes, they will simply enjoy access
> > to
> > more resources/features.
> 
> None of this explains the use case. It's pretty much what Sunil
> already
> stated. 
> 
> 

After some internal discussions, the plan is to not push new
interfaces, but to utilize the existing devlink params interface for
devlink port functions.

We will suggest a more fine grained parameters to control a port
function (SF/VF) well-defined capabilities.

devlink port function param set/get DEV/PORT_INDEX name PARAMETER value
VALUE cmode { runtime | driverinit | permanent }

Jiri is already on-board. Jakub I hope you are ok with this, let us
know if you have any concerns before we start implementation.

Thanks,
Saeed.