Linux Virtualization - Apr 2018 - [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework

On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst at redhat.com>
wrote:
> On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> On Mon, 23 Apr 2018 20:24:56 +0300
>> "Michael S. Tsirkin" <mst at redhat.com> wrote:
>>
>> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> > > > >
>> > > > >I will NAK patches to change to common code for
netvsc especially the
>> > > > >three device model.  MS worked hard with distro
vendors to support transparent
>> > > > >mode, ans we really can't have a new model; or
do backport.
>> > > > >
>> > > > >Plus, DPDK is now dependent on existing model.
>> > > >
>> > > > Sorry, but nobody here cares about dpdk or other similar
oddities.
>> > >
>> > > The network device model is a userspace API, and DPDK is a
userspace application.
>> >
>> > It is userspace but are you sure dpdk is actually poking at
netdevs?
>> > AFAIK it's normally banging device registers directly.
>> >
>> > > You can't go breaking userspace even if you don't
like the application.
>> >
>> > Could you please explain how is the proposed patchset breaking
>> > userspace? Ignoring DPDK for now, I don't think it changes the
userspace
>> > API at all.
>> >
>>
>> The DPDK has a device driver vdev_netvsc which scans the Linux network
devices
>> to look for Linux netvsc device and the paired VF device and setup the
>> DPDK environment.  This setup creates a DPDK failsafe (bondingish)
instance
>> and sets up TAP support over the Linux netvsc device as well as the
Mellanox
>> VF device.
>>
>> So it depends on existing 2 device model. You can't go to a 3
device model
>> or start hiding devices from userspace.
>
> Okay so how does the existing patch break that? IIUC does not go to
> a 3 device model since netvsc calls failover_register directly.
>
>> Also, I am working on associating netvsc and VF device based on serial
number
>> rather than MAC address. The serial number is how Windows works now,
and it makes
>> sense for Linux and Windows to use the same mechanism if possible.
>
> Maybe we should support same for virtio ...
> Which serial do you mean? From vpd?
>
> I guess you will want to keep supporting MAC for old hypervisors?
>
> It all seems like a reasonable thing to support in the generic core.
That's the reason why I chose explicit identifier rather than rely on
MAC address to bind/pair a device. MAC address can change. Even if it
can't, malicious guest user can fake MAC address to skip binding.

-Siwei

>
> --
> MST

On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu
wrote:
> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> "Michael S. Tsirkin" <mst at redhat.com> wrote:
> >>
> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger
wrote:
> >> > > > >
> >> > > > >I will NAK patches to change to common code for
netvsc especially the
> >> > > > >three device model.  MS worked hard with distro
vendors to support transparent
> >> > > > >mode, ans we really can't have a new model;
or do backport.
> >> > > > >
> >> > > > >Plus, DPDK is now dependent on existing model.
> >> > > >
> >> > > > Sorry, but nobody here cares about dpdk or other
similar oddities.
> >> > >
> >> > > The network device model is a userspace API, and DPDK is
a userspace application.
> >> >
> >> > It is userspace but are you sure dpdk is actually poking at
netdevs?
> >> > AFAIK it's normally banging device registers directly.
> >> >
> >> > > You can't go breaking userspace even if you
don't like the application.
> >> >
> >> > Could you please explain how is the proposed patchset
breaking
> >> > userspace? Ignoring DPDK for now, I don't think it
changes the userspace
> >> > API at all.
> >> >
> >>
> >> The DPDK has a device driver vdev_netvsc which scans the Linux
network devices
> >> to look for Linux netvsc device and the paired VF device and setup
the
> >> DPDK environment.  This setup creates a DPDK failsafe (bondingish)
instance
> >> and sets up TAP support over the Linux netvsc device as well as
the Mellanox
> >> VF device.
> >>
> >> So it depends on existing 2 device model. You can't go to a 3
device model
> >> or start hiding devices from userspace.
> >
> > Okay so how does the existing patch break that? IIUC does not go to
> > a 3 device model since netvsc calls failover_register directly.
> >
> >> Also, I am working on associating netvsc and VF device based on
serial number
> >> rather than MAC address. The serial number is how Windows works
now, and it makes
> >> sense for Linux and Windows to use the same mechanism if possible.
> >
> > Maybe we should support same for virtio ...
> > Which serial do you mean? From vpd?
> >
> > I guess you will want to keep supporting MAC for old hypervisors?
> >
> > It all seems like a reasonable thing to support in the generic core.
> 
> That's the reason why I chose explicit identifier rather than rely on
> MAC address to bind/pair a device. MAC address can change. Even if it
> can't, malicious guest user can fake MAC address to skip binding.
> 
> -Siwei
Address should be sampled at device creation to prevent this
kind of hack. Not that it buys the malicious user much:
if you can poke at MAC addresses you probably already can
break networking.



> 
> >
> > --
> > MST

On Mon, 23 Apr 2018 12:44:39 -0700
Siwei Liu <loseweigh at gmail.com> wrote:
> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:  
> >> On Mon, 23 Apr 2018 20:24:56 +0300
> >> "Michael S. Tsirkin" <mst at redhat.com> wrote:
> >>  
> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger
wrote:
> >> > > > >
> >> > > > >I will NAK patches to change to common code for
netvsc especially the
> >> > > > >three device model.  MS worked hard with distro
vendors to support transparent
> >> > > > >mode, ans we really can't have a new model;
or do backport.
> >> > > > >
> >> > > > >Plus, DPDK is now dependent on existing model.
> >> > > >
> >> > > > Sorry, but nobody here cares about dpdk or other
similar oddities.
> >> > >
> >> > > The network device model is a userspace API, and DPDK is
a userspace application.
> >> >
> >> > It is userspace but are you sure dpdk is actually poking at
netdevs?
> >> > AFAIK it's normally banging device registers directly.
> >> >  
> >> > > You can't go breaking userspace even if you
don't like the application.
> >> >
> >> > Could you please explain how is the proposed patchset
breaking
> >> > userspace? Ignoring DPDK for now, I don't think it
changes the userspace
> >> > API at all.
> >> >  
> >>
> >> The DPDK has a device driver vdev_netvsc which scans the Linux
network devices
> >> to look for Linux netvsc device and the paired VF device and setup
the
> >> DPDK environment.  This setup creates a DPDK failsafe (bondingish)
instance
> >> and sets up TAP support over the Linux netvsc device as well as
the Mellanox
> >> VF device.
> >>
> >> So it depends on existing 2 device model. You can't go to a 3
device model
> >> or start hiding devices from userspace.  
> >
> > Okay so how does the existing patch break that? IIUC does not go to
> > a 3 device model since netvsc calls failover_register directly.
> >  
> >> Also, I am working on associating netvsc and VF device based on
serial number
> >> rather than MAC address. The serial number is how Windows works
now, and it makes
> >> sense for Linux and Windows to use the same mechanism if possible.
> >
> > Maybe we should support same for virtio ...
> > Which serial do you mean? From vpd?
> >
> > I guess you will want to keep supporting MAC for old hypervisors?
The serial number has always been in the hypervisor since original support of
SR-IOV
in WS2008.  So no backward compatibility special cases would be needed.

On Mon, 23 Apr 2018 23:06:55 +0300
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
> > On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
> > > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger
wrote:
> > >> On Mon, 23 Apr 2018 20:24:56 +0300
> > >> "Michael S. Tsirkin" <mst at redhat.com>
wrote:
> > >>  
> > >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen
Hemminger wrote:
> > >> > > > >
> > >> > > > >I will NAK patches to change to common
code for netvsc especially the
> > >> > > > >three device model.  MS worked hard with
distro vendors to support transparent
> > >> > > > >mode, ans we really can't have a new
model; or do backport.
> > >> > > > >
> > >> > > > >Plus, DPDK is now dependent on existing
model.
> > >> > > >
> > >> > > > Sorry, but nobody here cares about dpdk or
other similar oddities.
> > >> > >
> > >> > > The network device model is a userspace API, and
DPDK is a userspace application.
> > >> >
> > >> > It is userspace but are you sure dpdk is actually poking
at netdevs?
> > >> > AFAIK it's normally banging device registers
directly.
> > >> >  
> > >> > > You can't go breaking userspace even if you
don't like the application.
> > >> >
> > >> > Could you please explain how is the proposed patchset
breaking
> > >> > userspace? Ignoring DPDK for now, I don't think it
changes the userspace
> > >> > API at all.
> > >> >  
> > >>
> > >> The DPDK has a device driver vdev_netvsc which scans the
Linux network devices
> > >> to look for Linux netvsc device and the paired VF device and
setup the
> > >> DPDK environment.  This setup creates a DPDK failsafe
(bondingish) instance
> > >> and sets up TAP support over the Linux netvsc device as well
as the Mellanox
> > >> VF device.
> > >>
> > >> So it depends on existing 2 device model. You can't go to
a 3 device model
> > >> or start hiding devices from userspace.  
> > >
> > > Okay so how does the existing patch break that? IIUC does not go
to
> > > a 3 device model since netvsc calls failover_register directly.
> > >  
> > >> Also, I am working on associating netvsc and VF device based
on serial number
> > >> rather than MAC address. The serial number is how Windows
works now, and it makes
> > >> sense for Linux and Windows to use the same mechanism if
possible.
> > >
> > > Maybe we should support same for virtio ...
> > > Which serial do you mean? From vpd?
> > >
> > > I guess you will want to keep supporting MAC for old hypervisors?
> > >
> > > It all seems like a reasonable thing to support in the generic
core.
> > 
> > That's the reason why I chose explicit identifier rather than rely
on
> > MAC address to bind/pair a device. MAC address can change. Even if it
> > can't, malicious guest user can fake MAC address to skip binding.
> > 
> > -Siwei  
> 
> Address should be sampled at device creation to prevent this
> kind of hack. Not that it buys the malicious user much:
> if you can poke at MAC addresses you probably already can
> break networking.
On Hyper-V guest can't really change MAC address if SR-IOV is enabled.
Also, Linux has permanent ether address in netdev which is what should
be used to avoid user messing with device.

On Mon, Apr 23, 2018 at 06:25:03PM -0700, Stephen Hemminger
wrote:
> On Mon, 23 Apr 2018 12:44:39 -0700
> Siwei Liu <loseweigh at gmail.com> wrote:
> 
> > On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
> > > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger
wrote:
> > >> On Mon, 23 Apr 2018 20:24:56 +0300
> > >> "Michael S. Tsirkin" <mst at redhat.com>
wrote:
> > >>  
> > >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen
Hemminger wrote:
> > >> > > > >
> > >> > > > >I will NAK patches to change to common
code for netvsc especially the
> > >> > > > >three device model.  MS worked hard with
distro vendors to support transparent
> > >> > > > >mode, ans we really can't have a new
model; or do backport.
> > >> > > > >
> > >> > > > >Plus, DPDK is now dependent on existing
model.
> > >> > > >
> > >> > > > Sorry, but nobody here cares about dpdk or
other similar oddities.
> > >> > >
> > >> > > The network device model is a userspace API, and
DPDK is a userspace application.
> > >> >
> > >> > It is userspace but are you sure dpdk is actually poking
at netdevs?
> > >> > AFAIK it's normally banging device registers
directly.
> > >> >  
> > >> > > You can't go breaking userspace even if you
don't like the application.
> > >> >
> > >> > Could you please explain how is the proposed patchset
breaking
> > >> > userspace? Ignoring DPDK for now, I don't think it
changes the userspace
> > >> > API at all.
> > >> >  
> > >>
> > >> The DPDK has a device driver vdev_netvsc which scans the
Linux network devices
> > >> to look for Linux netvsc device and the paired VF device and
setup the
> > >> DPDK environment.  This setup creates a DPDK failsafe
(bondingish) instance
> > >> and sets up TAP support over the Linux netvsc device as well
as the Mellanox
> > >> VF device.
> > >>
> > >> So it depends on existing 2 device model. You can't go to
a 3 device model
> > >> or start hiding devices from userspace.  
> > >
> > > Okay so how does the existing patch break that? IIUC does not go
to
> > > a 3 device model since netvsc calls failover_register directly.
> > >  
> > >> Also, I am working on associating netvsc and VF device based
on serial number
> > >> rather than MAC address. The serial number is how Windows
works now, and it makes
> > >> sense for Linux and Windows to use the same mechanism if
possible.
> > >
> > > Maybe we should support same for virtio ...
> > > Which serial do you mean? From vpd?
> > >
> > > I guess you will want to keep supporting MAC for old hypervisors?
> 
> The serial number has always been in the hypervisor since original support
of SR-IOV
> in WS2008.  So no backward compatibility special cases would be needed.
Is that a serial from real hardware or a hypervisor thing?


-- 
MST

On Mon, Apr 23, 2018 at 1:06 PM, Michael S. Tsirkin <mst at redhat.com>
wrote:
> On Mon, Apr 23, 2018 at 12:44:39PM -0700, Siwei Liu wrote:
>> On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
>> > On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> >> On Mon, 23 Apr 2018 20:24:56 +0300
>> >> "Michael S. Tsirkin" <mst at redhat.com>
wrote:
>> >>
>> >> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen
Hemminger wrote:
>> >> > > > >
>> >> > > > >I will NAK patches to change to common code
for netvsc especially the
>> >> > > > >three device model.  MS worked hard with
distro vendors to support transparent
>> >> > > > >mode, ans we really can't have a new
model; or do backport.
>> >> > > > >
>> >> > > > >Plus, DPDK is now dependent on existing
model.
>> >> > > >
>> >> > > > Sorry, but nobody here cares about dpdk or
other similar oddities.
>> >> > >
>> >> > > The network device model is a userspace API, and
DPDK is a userspace application.
>> >> >
>> >> > It is userspace but are you sure dpdk is actually poking
at netdevs?
>> >> > AFAIK it's normally banging device registers
directly.
>> >> >
>> >> > > You can't go breaking userspace even if you
don't like the application.
>> >> >
>> >> > Could you please explain how is the proposed patchset
breaking
>> >> > userspace? Ignoring DPDK for now, I don't think it
changes the userspace
>> >> > API at all.
>> >> >
>> >>
>> >> The DPDK has a device driver vdev_netvsc which scans the Linux
network devices
>> >> to look for Linux netvsc device and the paired VF device and
setup the
>> >> DPDK environment.  This setup creates a DPDK failsafe
(bondingish) instance
>> >> and sets up TAP support over the Linux netvsc device as well
as the Mellanox
>> >> VF device.
>> >>
>> >> So it depends on existing 2 device model. You can't go to
a 3 device model
>> >> or start hiding devices from userspace.
>> >
>> > Okay so how does the existing patch break that? IIUC does not go
to
>> > a 3 device model since netvsc calls failover_register directly.
>> >
>> >> Also, I am working on associating netvsc and VF device based
on serial number
>> >> rather than MAC address. The serial number is how Windows
works now, and it makes
>> >> sense for Linux and Windows to use the same mechanism if
possible.
>> >
>> > Maybe we should support same for virtio ...
>> > Which serial do you mean? From vpd?
>> >
>> > I guess you will want to keep supporting MAC for old hypervisors?
>> >
>> > It all seems like a reasonable thing to support in the generic
core.
>>
>> That's the reason why I chose explicit identifier rather than rely
on
>> MAC address to bind/pair a device. MAC address can change. Even if it
>> can't, malicious guest user can fake MAC address to skip binding.
>>
>> -Siwei
>
> Address should be sampled at device creation to prevent this
> kind of hack. Not that it buys the malicious user much:
> if you can poke at MAC addresses you probably already can
> break networking.
I don't understand why poking at MAC address may potentially break
networking. Unlike VF, passthrough PCI endpoint device has its freedom
to change the MAC address. Even on a VF setup it's not neccessarily
always safe to assume the VF's MAC address cannot or shouldn't be
changed. That depends on the specific need whether the host admin
wants to restrict guest from changing the MAC address, although in
most cases it's true.

I understand we can use the perm_addr to distinguish. But as said,
this will pose limitation of flexible configuration where one can
assign VFs with identical MAC address at all while each VF belongs to
different PF and/or different subnet for e.g. load balancing. And
furthermore, the QEMU device model never uses MAC address to be
interpreted as an identifier, which requires to be unique per VM
instance. Why we're introducing this inconsistency?

-Siwei
>
>
>
>
>>
>> >
>> > --
>> > MST