netdev - Re: [RFC] current devlink extension plan for NICs

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: <20200323204116.7c2f6e46@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 23 Mar 2020 20:41:16 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     Parav Pandit <parav@...lanox.com>, Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Yuval Avnery <yuvalav@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "leon@...nel.org" <leon@...nel.org>,
        "andrew.gospodarek@...adcom.com" <andrew.gospodarek@...adcom.com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        Moshe Shemesh <moshe@...lanox.com>,
        Aya Levin <ayal@...lanox.com>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        Vlad Buslov <vladbu@...lanox.com>,
        Yevgeny Kliteynik <kliteyn@...lanox.com>,
        "dchickles@...vell.com" <dchickles@...vell.com>,
        "sburla@...vell.com" <sburla@...vell.com>,
        "fmanlunas@...vell.com" <fmanlunas@...vell.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>,
        "snelson@...sando.io" <snelson@...sando.io>,
        "drivers@...sando.io" <drivers@...sando.io>,
        "aelior@...vell.com" <aelior@...vell.com>,
        "GR-everest-linux-l2@...vell.com" <GR-everest-linux-l2@...vell.com>,
        "grygorii.strashko@...com" <grygorii.strashko@...com>,
        mlxsw <mlxsw@...lanox.com>, Ido Schimmel <idosch@...lanox.com>,
        Mark Zhang <markz@...lanox.com>,
        "jacob.e.keller@...el.com" <jacob.e.keller@...el.com>,
        Alex Vesker <valex@...lanox.com>,
        "linyunsheng@...wei.com" <linyunsheng@...wei.com>,
        "lihong.yang@...el.com" <lihong.yang@...el.com>,
        "vikas.gupta@...adcom.com" <vikas.gupta@...adcom.com>,
        "magnus.karlsson@...el.com" <magnus.karlsson@...el.com>
Subject: Re: [RFC] current devlink extension plan for NICs

On Mon, 23 Mar 2020 19:50:09 -0300 Jason Gunthorpe wrote:
> On Mon, Mar 23, 2020 at 12:31:16PM -0700, Jakub Kicinski wrote:
> 
> > Right, that is the point. It's the host admin that wants the new
> > entity, so if possible it'd be better if they could just ask for it 
> > via devlink rather than some cloud API. Not that I'm completely opposed
> > to a cloud API - just seems unnecessary here.  
> 
> The cloud API provides all the permissions checks and security
> elements. It cannot be avoided.

Ack, the question is just who consults the cloud API, the Host or the
SmartNIC (latter would abstract differences between cloud APIs).

> If you try to do it as you say then it is weird. You have to use the
> cloud API to authorize the VM to touch a certain network, then the VM
> has to somehow take that network ID and use devlink to get a netdev
> for it. And the cloud side has to protect against a hostile VM sending
> garbage along this communication channel.

I don't understand how the VM needs to know the network ID, quite the
opposite, the Network ID should be gettable/settable by the hypervisor/
/PF. 

If VF starts requesting nested network IDs those should be in a
separate namespace from the the "outer" ones, no?

> vs simply host plugging in the correct network fully operational when
> the cloud API connects the VM to the network.

That means the user has to pre-allocate the device ID, or query the
cloud API after the device is created about its attributes (in the case
of two interfaces being requested simultaneously).

I don't feel very strongly about this, but given how many Linux
instances run in the cloud it'd seem nice if we had some APIs to meet
their basic needs.