Re: [PATCH net-next] macvlan: pass get_ts_info and SIOC[SG]HWTSTAMP ioctl to real device

[Hangbin Liu <liuhangbin@gmail.com>]

On Wed, Apr 17, 2019 at 08:31:57PM -0700, Richard Cochran wrote:
> On Wed, Apr 17, 2019 at 08:59:58PM +0200, Jiri Benc wrote:
> > The problem here is this patch gives access to physical interface
> > settings through a virtual interface layered on top of it. Whenever
> > such thing is done, the virtual interface needs to provide a suitable
> > way of moderating access to the shared resources, so the individual
> > virtual interfaces do not affect each other. That's not what's being
> > done here.
> 
> So I guess the macvlan should reject SIOCSHWTSTAMP but allow
> SIOCGHWTSTAMP.

Do you want to fix it only in container, like:

diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 4a6be8fab884..a2bd50a50e2f 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -836,6 +836,8 @@ static int macvlan_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)

        switch (cmd) {
        case SIOCSHWTSTAMP:
+               if (!net_eq(dev_net(dev), &init_net))
+                       break;
        case SIOCGHWTSTAMP:
                if (netif_device_present(real_dev) && ops->ndo_do_ioctl)
                        err = ops->ndo_do_ioctl(real_dev, &ifrr, cmd);

Or just remove 'case SIOCSHWTSTAMP' directly?

And we should do the same on vlan, right?

>  
> > I think this patch is wrong.
> 
> But what about this statement:
> 
>     ptp over vlan also has this issue
> 
> What is the issue with VLAN interfaces?  Are these exportable to a
> container when the physical interface is not?

Yes, if we attach a VLAN interface to container, a mapped user could also
be able to modify the host's physical interface rx filter via ioctl.

Thanks
Hangbin