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: <20220118100235.412b557c@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Tue, 18 Jan 2022 10:02:35 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Saeed Mahameed <saeed@...nel.org>
Cc:     Parav Pandit <parav@...dia.com>,
        Sunil Sudhakar Rani <sunrani@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>,
        Jiri Pirko <jiri@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Bodong Wang <bodong@...dia.com>
Subject: Re: [PATCH net-next 1/2] devlink: Add support to set port function
 as trusted

On Fri, 14 Jan 2022 22:15:48 -0800 Saeed Mahameed wrote:
> On 14 Jan 18:34, Jakub Kicinski wrote:
> >> HV is composing the device before giving it to the VM.
> >> VM can always disable certain feature if it doesn't want to use by ethtool or other means.
> >> But here we are discussing about offering/not offering the feature to the VF from HV.
> >> HV can choose to not offer certain features based on some instruction received from orchestration.  
> >
> >I'm still missing why go thru orchestration and HV rather than making
> >the driver load more clever to avoid wasting time on initializing
> >unnecessary caps.  
> 
> unfortunately for "smartnics" of this era, many of these initilizations
> and resources are only manged by FW and the details are hidden away from
> drivers, we need the knobs to tell the FW, hey we don't need all of these
> features for this particular vf, save the resources for something else.
> After all VF users need only a small portion of all the features we offer
> to them, but again unfortunately the FW pre-allocates precious HW
> resources to allow such features per VFs.
> 
> I know in this case smartnic === dumb FW, and sometimes there is no way
> around it, this is the hw arch we have currently, not everything is a
> nice generic flexible resources, not when it has to be wrapped with FW
> "__awesome__" logic ;), and for proper virtualization we need this FW.
> 
> But i totally agree with your point, when we can limit with resources, we
> should limit with resources, otherwise we need a knob to communicate to FW
> what is the user intention for this VF.
> 
> >> Privilege.
> >> VFs have SMFS today, but by default it is disabled. The proposed knob will enable it.  
> >
> >Could you rephrase? What does it mean that VFs have SMFS but it's
> >disabled? Again - privilege means security, I'd think that it can't have
> >security implications if you're freely admitting that it's exposed.  
> 
> I think the term privilege is misused here, due to the global knob proposed
> initially. Anyway the issue is exactly as I explained above, SW steering requires
> FW pre-allocated resources and initializations, for VFs it is disabled
> since there was no demand for it and FW wanted to save on resources.
> 
> Now as SW steering is catching up with FW steering in terms of
> functionality, people want it also on VFs to help with rule insertion rate
> for use cases other than switchdev and TC, e.g TLS, connection tracking,
> etc .. 

Sorry long weekend here, thanks for the explanation!

Where do we stand? Are you okay with an explicit API for enabling /
disabling VF features? If SMFS really is about conntrack and TLS maybe
it can be implied by the delegation of appropriate bits meaningful to
netdev world?