Project

General

Profile

Actions

Bug #13992

open

VNIC in Zone loses access to properties

Added by Sean Klein 10 months ago. Updated 6 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

TL;DR: When using a VNIC within a Zone that uses an exclusive netstack, nearly all link properties are missing (shown as "?").

Here's my setup:

In the Global zone, I have a physical ethernet data link, on top of which I have created a VNIC (named "vnic_propolis0"):

(GZ) $ dladm
LINK        CLASS     MTU    STATE    BRIDGE     OVER
igb0        phys      1500   up       --         --
vnic_propolis0 vnic   1500   up       --         igb0

Meanwhile, I have a running zone:

(GZ)  $ zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              ipkg     shared
  47 instance_zone    running    /zone/instance_zone            sparse   excl  

And, again from the global zone, I can see link properties on the VNIC - such as the "zone" property, indicating it is being used by a non-global zone:

(GZ) $ dladm show-linkprop vnic_propolis0
LINK         PROPERTY        PERM VALUE          DEFAULT        POSSIBLE
vnic_propolis0 autopush      rw   --             --             -- 
vnic_propolis0 zone          rw   instance_zone  --             -- 
vnic_propolis0 state         r-   up             up             up,down 
vnic_propolis0 mtu           rw   1500           1500           60-1500 
...

This is all, as far as I can tell, expected behavior. However, when I zlogin to the zone, and try to show the link properties:

(Non-Global Zone) # dladm show-linkprop
LINK         PROPERTY        PERM VALUE          DEFAULT        POSSIBLE
vnic_propolis0 state         r-   ?              up             up,down 
vnic_propolis0 secondary-macs ?   ?              --             -- 
vnic_propolis0 maxbw         ?    ?              --             -- 
vnic_propolis0 cpus          ?    ?              --             -- 
vnic_propolis0 cpus-effective r-  ?              --             -- 
vnic_propolis0 pool          ?    ?              --             -- 
vnic_propolis0 pool-effective r-  ?              --             -- 
vnic_propolis0 priority      ?    ?              high           low,medium,high 
vnic_propolis0 tagmode       ?    ?              vlanonly       normal,vlanonly 

The properties are not visible.

Using truss, I see many invocations of:

ioctl(3, DLDIOC_GETMACPROP, 0x08111A48)         Err#2 ENOENT

Implying some visibility mismatch here.

Is this a bug? Is there a configuration I need to tweak to make data link properties accessible in the non-global zone?

Actions #1

Updated by Sean Klein 10 months ago

Following up here:

The following lines seem to be hit when actually querying the link properties.

https://github.com/illumos/illumos-gate/blob/8efb7381403c37b01ffd6e1ed80c97dc0ac5d395/usr/src/uts/common/io/dld/dld_drv.c#L681-L688

This code appears to prevent accessing link properties unless the calling process is from the same zone which created the link, as it is checking the value of dls_devnet_getownerzid.

I'd like to understand: Why not compare the credentials against the result of dls_devnet_getzid - AKA, the "current" zone - instead of the "creating" zone? It seems counterintuitive to me that a datalink can be "assigned" to a Zone, but all properties of that link are invisible to that non-global zone.

Actions #2

Updated by Dan McDonald 6 days ago

We'll need to be careful about which properties are settable by zone, vs. gettable by zone.

The good news is that auditing calls to check for the zone-ID vs. the owner-zone-ID SHOULD be localized to a handful of files:

kebe(src/uts)[0]% git grep -l dls_devnet_getzid
common/io/dld/dld_drv.c
common/io/dls/dls_link.c
common/io/dls/dls_mgmt.c
common/sys/dls.h
kebe(src/uts)[0]% git grep -l dls_devnet_getownerzid
common/io/dld/dld_drv.c
common/io/dls/dls_mgmt.c
common/sys/dls.h
kebe(src/uts)[0]% git grep -l dd_zid
common/io/dls/dls_mgmt.c
kebe(src/uts)[0]% git grep -l dd_owner_zid
common/io/dls/dls_mgmt.c
kebe(src/uts)[0]% 

There may be upstack callers of functions in these files that result in further checking, so I may be overly optimistic.

Actions

Also available in: Atom PDF