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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20210602093440.15dc5713@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Wed, 2 Jun 2021 09:34:40 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Yunsheng Lin <linyunsheng@...wei.com>
Cc:     moyufeng <moyufeng@...wei.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Parav Pandit <parav@...lanox.com>,
        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@...lanox.com>,
        Salil Mehta <salil.mehta@...wei.com>,
        "lipeng (Y)" <lipeng321@...wei.com>,
        Guangbin Huang <huangguangbin2@...wei.com>,
        <shenjian15@...wei.com>, "chenhao (DY)" <chenhao288@...ilicon.com>,
        Jiaran Zhang <zhangjiaran@...wei.com>
Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension

On Wed, 2 Jun 2021 10:24:11 +0800 Yunsheng Lin wrote:
> On 2021/6/2 5:34, Jakub Kicinski wrote:
> > On Tue, 1 Jun 2021 15:33:09 +0800 Yunsheng Lin wrote:  
> >> Is there a reason why it didn't have to be solved yet?
> >> Is it because the devices currently supporting devlink do not have
> >> this kind of problem, like single-function ASIC or multi-function
> >> ASIC without sharing common resource?  
> > 
> > I'm not 100% sure, my guess is multi-function devices supporting
> > devlink are simple enough for the problem not to matter all that much.
> >   
> >> Was there a discussion how to solved it in the past?  
> > 
> > Not really, we floated an idea of creating aliases for devlink
> > instances so a single devlink instance could answer to multiple 
> > bus identifiers. But nothing concrete.  
> 
> What does it mean by "answer to multiple bus identifiers"? I
> suppose it means user provides the bus identifiers when setting or
> getting something, and devlink instance uses that bus identifiers
> to differentiate different PF in the same ASIC?

Correct.

> can devlink port be used to indicate different PF in the same ASIC,
> which already has the bus identifiers in it? It seems we need a
> extra identifier to indicate the ASIC?
> 
> $ devlink port show
> ...
> pci/0000:03:00.0/61: type eth netdev sw1p1s0 split_group 0

Ports can obviously be used, but which PCI device will you use to
register the devlink instance? Perhaps using just one doesn't matter 
if there is only one NIC in the system, but may be confusing with
multiple NICs, no?

> >> "same control domain" means if it is controlled by a single host, not
> >> by multi hosts, right?
> >>
> >> If the PF is not passed through to a vm using VFIO and other PF is still
> >> in the host, then I think we can say it is controlled by a single host.
> >>
> >> And each PF is trusted with each other right now, at least at the driver
> >> level, but not between VF.  
> > 
> > Right, the challenge AFAIU is how to match up multiple functions into 
> > a single devlink instance, when driver has to probe them one by one.  
> 
> Does it make sense if the PF first probed creates a auxiliary device,
> and the auxiliary device driver creates the devlink instance? And
> the PF probed later can connect/register to that devlink instance?

I would say no, that just adds another layer of complication and
doesn't link the functions in any way.

> > If there is no requirement that different functions are securely
> > isolated it becomes a lot simpler (e.g. just compare device serial
> > numbers).  
> 
> Is there any known requirement if the different functions are not
> securely isolated?

Not sure I understand. If the functions are in different domains 
of control allowing one of them to dump state of the other may be
problematic given features like TLS offload, for instance.