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: <20220114183445.463c74f5@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Fri, 14 Jan 2022 18:34:45 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Parav Pandit <parav@...dia.com>
Cc:     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 04:52:24 +0000 Parav Pandit wrote:
> > > Each enabled feature consumes
> > > (a) driver level memory resource such as querying ip sec capabilities and more later,
> > > (b) time in querying those capabilities,  
> > 
> > These are on the VM's side, it's not hypervisors responsibility to help the client
> > by stripping features.
> >   
> 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.

> > > (c) device level initialization in supporting this capability
> > >
> > > So for light weight devices which doesn't need it we want to keep it disabled.  
> > 
> > You need to explain this better. We are pretty far from "trust"
> > settings, which are about privilege and not breaking isolation.
> 
> We split the abstract trust to more granular settings, some related to privilege and some to capabilities.
>  
> > "device level initialization" tells me nothing.
> >  
> Above one belongs to capabilities bucket. Sw_steering belongs to trust bucket.
>
> > > No it is limited to tc offloads.
> > > A VF netdev inserts flow steering rss rules on nic rx table.
> > > This also uses the same smfs/dmfs when a VF is capable to do so.  
> > 
> > Given the above are you concerned about privilege or also just resources use
> > here? Do VFs have SMFS today?  
> 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.