Here are my belated comments on the IP Instances design.

There are two documents which describe the design
        si-interfaces - a high-level design focusing on the problem the
        project solves, and what the user-visible changes are

A general comment that in both documents page numbers seem to be

Figures 1 and 2 - I think the pictures are a little misleading the
second picture displays an example of two applications (web servers?)
both binding to INADDR_ANY on port 80.  Of course, that's also a very
viable example for the current zones model.  Perhaps a better example
might be one of those applications designated as "Internet facing" and
another might be "Intranet-facing" or "Internal".

Page 6, Section 4 - I'm not sure if this is the proper place for a
discussion on security or if it warrants a separate section, but I
think the document should discuss the security implications of a zone
using a shared stack versus an exclusive stack.  For example, I think
including the table you had sent in private email some time ago which
documented the various attack vectors and how each type of zone
addresses the type of attack would be helpful in understanding the

(I know some of this is headed to be discussed in Section 9 of the
second document but it seems at least some of the discussion belongs
here as well.)

Page 6, Section 5 - In the second paragraph, you mention there are no
planned layer two changes.  Does that mean for the initial design that
there will be no filtering done at that layer?  Again, perhaps this
merits discussion in a separate "Security" section but it's important
to understand what sorts of capabilities a privileged user in an
exclusive stack zone has versus one in a zone using the shared stack.

Page 7, Section 6 - In #4, leveraging zonename(1) in this way does seem
strange.  I know we discussed at one time a command to retrieve and
interpret the values of ZONE_ATTR_* kernel attributes although in this
particular case, it seems the only one that makes sense from inside the
zone itself is whether this zone is tied to an exclusive stack.

What about using /sbin/netstrategy and smf_netstrategy() in
/lib/svc/share/ for this purpose?

Page 7, Section 7 - Given the recent discussion with a customer, would
it make sense to make it clear here that there is a *single* shared IP
and the project does not allow for "islands" of shared IP instances?

Page 8, Section 9 - When does the enforcement of only allowing a
"physical" property for exclusive IP zones?  Does it occur when one
tries to complete the addition of a "net" resource by specifying "end"
subcommand?  Or does it occur when "verify" is performed on the whole
configuration (either the explicit command or the implicit verification
that takes place prior to commit?)

In the example given for the shared IP zone, I would specify add the
/24 prefix length to the address parameter (it's not required but
definitely encourage it) and also the missing "end" subcommand.

In the example given for the exclusive IP zone, there is also a missing
"end" subcommand.

Page 9, Section 10 - BrandZ added their BRAND column after the existing
PATH column but you're introducing it before.  It seems the "IP TYPE"
should follow both PATH and BRAND.  Also, updating the output for first
two "list" examples to account for the merge with BrandZ would be

In the third example, the command listed is "list -i" but earlier "-l"
is defined for this purpose.

With respect to "list -l", I'm not sure if this really belongs in
zoneadm(1M) or somewhere else.  In some ways, I'd rather see it as a
new option to dladm(1M) instead.

Will the list of link names printed be the ones actually registered
with the kernel though zone_add_ifname() or the subset of those link
names actually plumbed by the zone with the exclusive stack?  I assume
the former but please verify that.

In this respect, it seems that "list -l" is printing one of that
several pieces of zone runtime state which we don't currently print
through zoneadm(1M) or any other command.  The zones team has discussed
in the past introducing a more general "zoneadm status" or "zoneadm
info" facility but that's not yet designed.  Another alternative is to
begin supporting a "list -o <format>" in zoneadm(1M) and allow the link
names to be a supported type there.

Finally, in the case where multiple "net" resources have been specified
with an exclusive IP zone, are the link names separated by whitespace?

Page 9, Section 11 - As I mentioned earlier, zonename(1) seems the
wrong interface for obtaining this information.  What about using
/sbin/netstrategy and smf_netstrategy()?

Page 9, Section 12 - There should be some discussion of the packaging
changes somewhere in one or both of the documents.  In the particular
case of IP Filter, is the proposal to move all of the contents of
SUNWipfr into a non-hollow package?

Page 15, Section 14 - This is more of a code review question but are
the additional privileges being granted to an exclusive stack zone
being hard-coded in either libzonecfg or zoneadmd(1M) or are you
extending the XML uses for each brand?

Page 16, Section 15 - Is the additional configuration that is being
introduced part of this case or a future case?  If the latter, how will
this project and TX interact?

Page 16, Section 17 - Could you provide a bit more detail on each of
these interfaces?  In particular, does zone_get_ifnum() return the
number of link names registered via zone_add_ifname()?  Is the second
parameter of zone_get_iflist() a single string containing the link
names registered in a concatenated form?

More generally, can zone_getattr() be used in place of these
zone_get_if*() functions?

Should these functions be dealing with "link names" rather than
"interfaces" to avoid confusion with the interfaces that ifconfig(1M)
deals with?

        si-design - the design of the code changes. Assumes the reader
        has read si-interfaces already!

Pages 14, Section 7.1 - More of a code review comment but please update
truss(1) to account for the additional argument to zone_create().

Pages 14-15, Section 7.2 - As mentioned above, could you please provide
some more details on these new system calls?  Can zone_getattr() be
used instead of the proposed zone_get_if*() functions?

Also, could you list the changes to the proposed zone_t structure?

With regard to the third bullet, please see my concerns above about the
introduction of "list -l".  I think this should be part of a general
zone status/health facility or perhaps something that dladm(1M) can
print about the link names and how their assignment zone-wise.

With respect to the fourth bullet, can the global zone plumb an
interface which has been "assigned" to an exclusive IP zone but not yet
plumbed by that zone?

Page 15, Section 7.3 - As I asked about in the earlier document, is
"zonecfg verify" the only place where address property verification is
done or is it also done at end of adding or changing a "net" resource?

And as I asked earlier, are the additional privileges and devices being
hard-coded intop libzonecfg or zoneadm(1M) or are you extending the XML
uses for each brand?

Page 16, Section 9 - Providing the table of attack vectors here along
with some discussion would be very helpful.

zones-discuss mailing list

Reply via email to