Bug #13992
open
VNIC in Zone loses access to properties
0%
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?
Updated by Sean Klein 11 months ago
Following up here:
The following lines seem to be hit when actually querying the link properties.
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.
Updated by Dan McDonald about 1 month 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.