Erik, 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 missing. 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 trade-offs. (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/smf_include.sh 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 helpful. 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. dsc _______________________________________________ zones-discuss mailing list firstname.lastname@example.org