linux-kernel - Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension

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 for Android: free password hash cracker in your pocket

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

Message-ID: <d54ae715-8634-c983-1602-8cd8dea2a5e2@huawei.com>
Date:   Wed, 9 Jun 2021 19:05:23 +0800
From:   Yunsheng Lin <linyunsheng@...wei.com>
To:     Parav Pandit <parav@...dia.com>, Jakub Kicinski <kuba@...nel.org>
CC:     moyufeng <moyufeng@...wei.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Or Gerlitz <gerlitz.or@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "michal.lkml@...kovi.net" <michal.lkml@...kovi.net>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Jiri Pirko <jiri@...dia.com>,
        Salil Mehta <salil.mehta@...wei.com>,
        "lipeng (Y)" <lipeng321@...wei.com>,
        Guangbin Huang <huangguangbin2@...wei.com>,
        "shenjian15@...wei.com" <shenjian15@...wei.com>,
        "chenhao (DY)" <chenhao288@...ilicon.com>,
        Jiaran Zhang <zhangjiaran@...wei.com>,
        "linuxarm@...neuler.org" <linuxarm@...neuler.org>
Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension

On 2021/6/9 17:38, Parav Pandit wrote:
> 
>> From: Yunsheng Lin <linyunsheng@...wei.com>
>> Sent: Wednesday, June 9, 2021 2:46 PM
>>
> [..]
> 
>>>> Is there any reason why VF use its own devlink instance?
>>>
>>> Primary use case for VFs is virtual environments where guest isn't
>>> trusted, so tying the VF to the main devlink instance, over which
>>> guest should have no control is counter productive.
>>
>> The security is mainly about VF using in container case, right?
>> Because VF using in VM, it is different host, it means a different devlink
>> instance for VF, so there is no security issue for VF using in VM case?
>> But it might not be the case for VF using in container?
> Devlink instance has net namespace attached to it controlled using devlink reload command.
> So a VF devlink instance can be assigned to a container/process running in a specific net namespace.
> 
> $ ip netns add n1
> $ devlink dev reload pci/0000:06:00.4 netns n1
>                                      ^^^^^^^^^^^^^
>                                      PCI VF/PF/SF.

Could we create another devlink instance when the net namespace of
devlink port instance is changed? It may seems we need to change the
net namespace based on devlink port instance instead of devlink instance.
This way container case seems be similiar to the VM case?

> 
>> Also, there is a "switch_id" concept from jiri's example, which seems to be
>> not implemented yet?
> 
> switch_id is present for switch ports in [1] and documented in [2].
> 
> [1] /sys/class/net/representor_netdev/phys_switch_id.
> [2] https://www.kernel.org/doc/Documentation/networking/switchdev.txt " Switch ID"

Thanks for info.
I suppose we could use "switch_id" to indentify a eswitch since
"switch_id is present for switch ports"?
Where does the "switch_id" of switch port come from? Is it from FW?
Or the driver generated it?

Is there any rule for "switch_id"? Or is it vendor specific?

>