RE: RE: virtio-net ip restriction.

[Parav Pandit <parav@nvidia.com>]

> From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Sent: Tuesday, August 15, 2023 8:40 AM
> 
> On Mon, 14 Aug 2023 13:03:53 +0000, Parav Pandit <parav@nvidia.com> wrote:
> >
> > > From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > Sent: Tuesday, August 8, 2023 1:35 PM
> > >
> > > ## Background
> > >
> > > For cloud, the ip restriction is important. Because the user of the
> > > vm is untrustworthy. One user may use the ip of another to config
> > > the netdevice to receive and send packets. So we need to restrict
> > > the ip traffic of the device(or port).
> > >
> > A VM can do the same with the mac address too.
> > Why is mac ignored?
> 
> On the cloud, the mac is not important, the DPU forwards the packets by the ip.
> But you are right, we can introduce the support for mac.
>
For one cloud may be mac is not important.
For others it is.
So one can start with flow filter rules with ip only definition, this is ok.
 
> >
> > > ## Implement
> > > Now we have these choice:
> > >
> > > 1. introduce the switch(as the part of pf or as a separate device under all PF
> > >    and VFs ), the switch support rx/tx filter 2. the virtio-net
> > > device support the ip restriction
> > >
> > #1 is the right approach, it is not either or.
> > Virtio switch object can be part of the virtio-net device or it can be indepdent
> device in itself.
> > So the definition we do should be generic enough so that it can be done as
> part of indepdent device in future without replicating all.
> >
> > The concept of switch port etc is needed.
> 
> For the switch part, I am ok.
> 
> But I would to know can we have two?
> 
I didn't follow the question.

> 
> 
> >
> > >
> > > Parav wrote:
> > > > I understood that you for some reason do not need restrictions for the PF.
> > > > I do not know why you don't need it. :) Most cloud setups that I
> > > > came across so far, needs it, but ok...
> > >
> > > PF is used by the administrator, so the ip restriction for the PF is not
> important.
> > > But we can have this feature.
> > >
> > In some cloud a PF is also owned by the tenant.
> > Hence its administration to be done outside of the PF.
> > Therefore the virtio switch object definition to be built for long term and
> apply to a narrow case for now as PF->VF.
> 
> YES.
> 
> But I think that the #2 is ok.
> 
> Your plan of the switching PF is the universal design to implement the ip
> restriction.
> 
> But the ip restriction is the common requirement in virtio case.
> We can support it in a virtio specific way.
>
There is no two design.
Let me try again.
There is just one design as virtio switch object.
A virtio switch object can be part of the some existing virtio device.
Or in future it can part of the independent virtio device with its unique device type.

All the plumbing we do to needs to wrap around this virtio switch object so that it is usable for years to come.

There is no point in adding some adhoc ip filter rules for short term.
 
> >
> >
> > > > The design for the switch object needs to cover the PF as well,
> > > > even though it
> > > may not be done initially.
> > > > (hint: an abstraction of switch port to be done, instead of doing
> > > > things directly
> > > on the group member id).
> > > >
> > > > We are seeing use cases reducing of having switch located on the
> > > > PF for its
> > > VFs.
> > >
> > > So for you, we should introduce a switching PF?
> > >
> > Yes.
> 
> You said that the use cases for switching PF are dwindling. But you prefer to
> implement ip restriction with switching PF. Am I right?
>
We should implement ip restriction rules using a virtio switch object.
This object can be part of an existing virtio-net device or it can be part of virtio switch object.
The definition to be done in a way that covers both.
There is no adhoc short cut and duplication.
 
> We know that the switch under all(PF, VF) is more complex.
> So we all not plan to implement it.
> 
> Then how about we do not implement the switching PF for now.
> We support ip restriction by the #2.
>
#2 is just "ip restriction without switch object", does not make much sense, as its very short term view.
 
> Then we can have an independent switch under all in the future.
>
That is fine, the virtio switch object definition to be there, so that one can put it in an independent virtio switch device type.
 
> >
> > > > So please reconsider.
> > > > I remember you mentioned in past in other thread, that mac etc is
> > > > controlled
> > > from the infrastructure side.
> > >
> > > YES.
> > >
> > Hence the administrative PF doing switching and VF configuration is desired.
> 
> I do not got fully.
> 
A new virtio switch device that covers PF and VFs.

> >
> > > > So, I repeatedly ask if you _really_ need to have the switch
> > > > object as part of
> > > the owner PF or not.
> > >
> > > For me, that are all ok.
> > > Could you explain the difference between these?
> > > So I would to know which one is better and which one is simper?
> > >
> > > > Which sort of contradicts with locating the administrative switch
> > > > on the
> > > owner PF.
> > >
> > > Why?
> > >
> > > For us, all is on the DPU.
> > >
> > If all is on the DPU, can the ip restriction be applied on the DPU for the VFs
> (where there may not be any virtio net device).
> > If so, why do we need to introduce things now?
> 
> In the past, we provided virtual machines. All virtual machines belong to
> different tenants. DPU has ip restriction function by default(without virtio).
> But more and more complex forms of services began to appear, they work on
> the HOST. But they create virtual machines or Dockers to provide to their
> tenants.
> For performance, each virtual machine or Docker uses a separate NIC provided
> by the DPU. So they need to configure IP restrictions for these NICs.
>
Hence it should be defined a virtio switch object, that can be used as part of existing virtio device or new device to cover both the use cases.

 > So the form of the cloud is changing, more and more configurations are need by
> the users from the host.

For may use cases this comes at heavy cost on the compute side where VMs are running.
But sure, this may be a valid case where its ok to pay it.

Please do not take short cut of some adding random rules via new CVQ commands for the ip restriction.
We need to define a virtio switch object, that has notion of switch ports, ingress,egress direction, re-use the flow filters infrastructure.

Also ip link vf spoof and other ip commands are already deprecated in Linux kernel long ago.
So do not think in that direction.

An established model will be through the switch representors like Satananda also explained.

I believe you are not thinking of ip link vf spoof anyway, because it does not allow ip level restrictions.
But making sure that we don't do in ip link direction because there was some question on "how you do spoof check".