From sacadmin Wed Jul 19 09:30:56 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6JGUuYR023376 for ; Wed, 19 Jul 2006 09:30:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k6JGUqx17996; Wed, 19 Jul 2006 09:30:52 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J2N00601SJDC400@brm-avmta-1.central.sun.com>; Wed, 19 Jul 2006 10:30:49 -0600 (MDT) Received: from sac.sfbay.sun.com ([129.146.175.66]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J2N00KCPSJCEJB0@brm-avmta-1.central.sun.com>; Wed, 19 Jul 2006 10:30:49 -0600 (MDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6JGUmAx023276; Wed, 19 Jul 2006 09:30:48 -0700 (PDT) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id k6JGUmgx023275; Wed, 19 Jul 2006 09:30:48 -0700 (PDT) Date: Wed, 19 Jul 2006 09:30:48 -0700 (PDT) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2006/366 Stack instances Exclusive IP stack per zone To: PSARC@sun.com Cc: Erik.Nordmark@sun.com, PSARC-coord@sun.com Message-id: <200607191630.k6JGUmgx023275@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 371 New Materials submitted for PSARC 2006/366 Stack instances Exclusive IP stack per zone Status: inception scheduled 07/26/2006 Files: /shared/sac/PSARC/2006/366/inception.materials/RSS /shared/sac/PSARC/2006/366/inception.materials/si-20-questions.txt /shared/sac/PSARC/2006/366/inception.materials/si-interfaces.pdf Please let me know if you have questions. - PSARC From sacadmin Wed Jul 19 09:31:21 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6JGVK80023392 for ; Wed, 19 Jul 2006 09:31:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k6JGUTRJ023842; Thu, 20 Jul 2006 00:31:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J2N00401SK5EA00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Jul 2006 09:31:17 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J2N00ADPSK4GYB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Jul 2006 09:31:17 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6JGVG7x012082; Wed, 19 Jul 2006 10:31:16 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J2N00601SFEWY00@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM); Wed, 19 Jul 2006 10:31:16 -0600 (MDT) Received: from [129.152.9.11] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J2N0058TSK4PRJ6@mail-amer.sun.com>; Wed, 19 Jul 2006 10:31:16 -0600 (MDT) Date: Wed, 19 Jul 2006 11:31:16 -0500 From: Rick Matthews Subject: New PSARC Materials Submitted PSARC 2006/366 Stack instances: Exclusive IP stack per zone Sender: Richard.Matthews@sun.com To: PSARC@sun.com, Erik Nordmark Message-id: <44BE5E54.3050608@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 933 New Materials submitted for PSARC 2006/366 Stack instances: Exclusive IP stack per zone Status: inception scheduled 07/26/2006 Files: /shared/sac/PSARC/2006/366/inception.materials/si-20-questions.txt /shared/sac/PSARC/2006/366/inception.materials/si-interfaces.pdf Please let me know if you have questions. BTW, the IAM file listed Darren Reed as the intern for this case. I have corrected that. If there was other reasons for that change, please let me know. -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- From sacadmin Wed Jul 26 10:04:42 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6QH4gmQ010151 for ; Wed, 26 Jul 2006 10:04:42 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.7+Sun/8.13.6) with ESMTP id k6QH4bmc383482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 26 Jul 2006 10:04:39 -0700 (PDT) Message-ID: <44C7A0A4.3090007@sun.com> Date: Wed, 26 Jul 2006 10:04:36 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: psarc CC: crossbow-core@sun.com Subject: Initial response to issues (PSARC 2006/366) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 16155 Since I'll be on the phone I figured I could try to improve the communication efficiency by sending out an initial cut at written answers. I'll watch the issues file and might send responses to additional issues before the meeting. Erik #ident "@(#)issues 1.2 06/07/25 SAC" PSARC 2006/366: Stack instances: Exclusive IP stack per zone Submitter: Erik Nordmark Owner: Kais Belgaied Intern: Rick Matthews Issues for inception (07/26/2006): jdc-1 Why is the interface address configuration done from zonecfg? Answer: It follows the existing zones model of configuring IP addresses from zonecfg. It is important to minimize the differences between configuring a shared-stack zone and an exclusive-stack zone. This means that an exclusive stack owner can't control his own network interface properties, except after the fact, and possibly at odds with the global zone administrator. The non-global admin can control its own network configuration. But see section 12 in si-interfaces.pdf on the choices of creating/updating the /etc/ network files on zone install vs. zone boot. Note that the current approach in this case doesn't prevent other projects to change the zone's model for network configuration to allow use of the normal sysid mechanism for configuring network parameters. (Why not control other aspects of network configuration, such as which routing daemons to run, from zonecfg as well? What's the administrative model that requires only addresses and static default routes, especially given "route -p"?) The above seems like issues with the original zones case and not this case. One could likewise have argued that PSARC 2002/174 should have allowed specifying other or all aspects of network configuration (such as nsswitch.conf, resolv.conf, etc) in zonecfg, but it did not. jdc-2 How exactly do interface bring-up and route configuration work? Does zoneadmd enter the zone to do these things -- if so, how is that coordinated with IP Filter configuration? If not, then how do the zonecfg-configured values end up in the non-global zone where the normal boot process can use them? See section 12 in si-interfaces.pdf If we are going to update the files on each zone boot, then we will use the design pattern that Zulu uses (fork + zone_enter to create the file). If we are only going to create the files when the zone is installed, we'll just have zoneadm install create them while running in the global zone. How does dhcpagent inside the non-global zone find out that zonecfg in the global zone has told it to run on some interface? The normal mechanism that is used in the global zone in S10 - the existence of /etc/dhc.. Section 5 of the design says the opposite of this -- it says that the existing /etc files are used in the non-global zone for configuration. Where do you see an inconsistency in the materials? AFAIK the materials are self-consistent on this issue. And section 12 provides options, but doesn't seem to recommend a particular solution. We are actively seeking the feedback from the ARC on that issue, which is why it is explicitly flagged. Sorry if this wasn't clear. jdc-3 What can 'restrict' really do? Why can't a non-global zone steal an address from another machine? Why can't a malicious user just run ifconfig _after_ the zone boots and the restriction is gone? Why is the flag needed? See section 9 in si-interfaces.pdf. The implementation of the enforcement is done in the kernel, so that the various ioctls that set/change an IP address or make ARP publish an entry, check against the restriction. Thus the non-global admin can invoke ifconfig to try to change its IP address or do an 'addif', but the ioctl will fail with EPERM. The need for this is to allow a middle ground between the current shared-stack model (where the non-global zone doesn't have the privileges to do any of this) and an exclusive stack with unrestricted ability to do things on the network. That middle ground has been requested by some, but the customers I've talked to don't see a need for this. (When they are consolidating applications from multiple servers, they already have some approach to how they handle root access on the individual servers - e.g. the "application admin" might have the root, or might not.) When consolidating those applications they can just continue using the same model (e.g., whether or not the application admin has the root password for "its" non-global zone.) Couldn't a really malicious user just open a raw driver and start transmitting gratuitous ARP messages for someone else's address? That is correct. The 'restrict=true' prevents against accidental misconfiguration but not against root in the zone running its own DLPI application which sends bogus ARP packets. You get the same type of protection with a exclusive-stack zone with 'restrict=true' as you get with in S10 when a zone has been given access to snooping on a NIC (e.g., by adding device access to /dev/bge1 in zonecfg). As an aside, we have an opportunity to differentiate ourselves in this space in the future. I think the right long-term direction, which applies to Xen/LDOMs/zones, is to introduce IP Filter hooks in the GLD layer and make it easy to create filter expressions for ARP and Neighbor Discovery packets. That would allow us to have the machine administrator enforce network security independent of the domU or zone that uses a NIC to access the network. jdc-4 20q8 says that link aggregation is supported in non-global zones, but section 5 of the design says that it can't be supported. Which is true? Good catch. 20q8 is incorrect. An aggregate has to be configured in the global zone. (It is probably possible to relax this in the future, but the details depend on how one could handle the Clearview vanity names creating entries in /dev/net.) jdc-5 KSSL identifies particular user applications based on configuration. How is this virtualized so that one zone cannot affect another? See section 5 in si-interfaces.pdf. The virtualization of kernel network components above the transport layer (NFS, KSSL, NL7C, etc) are out of scope. Furthermore, if/when they are virtualized they should be make "zone aware" and not "stack instance aware" since at that layer there are no direct function calls into IP. jdc-6 Can exclusive stack instances communicate with each other? Does doing so require external hardware or something delivered from Crossbow? The purpose of this project is isolation and not communication, because that is where the pressing customer need exists. Thus communication between separate stack instances will be done via external devices (Ethernet switches, routers, firewalls, load balancers, etc). In the future we expect that the Crossbow project will provide GLDv3 devices that will additionally allow for cases when strict isolation isn't necessary, e.g. when separate stacks want to be able to communicate inside the server. jdc-7 Can exclusive stack instances run NFS servers? If not, are there other "normal" Solaris networking features that are prohibited as well, and how does the user find out? See answer to jdc-5. Presumably the user finds this out the same way s/he finds out that one can't run an NFS server in a non-global zone in S10. jdc-8 What about ndd hacks, such as ip_squeue_enter or the really awful 'hme instance' value? Are those independent in these zones? (I don't see how the latter could be -- if I delegate hme0 to zone A and hme1 to zone B, I don't want zone A doing "ndd -set /dev/hme instance 1," but I don't see how I can stop it.) ip_squeue_enter and the like will require PRIV_SYS_NET_CONFIG hence will only be allowed in the global zone. (The squeues are effectively a scheduling concept whose number is based on the number of CPUs, hence having more of them when there are more zones doesn't make sense.) 'hme instance' doesn't exist. I think it does exist for 'ce'. Since 'ce' is DLPI style 2 it can not be assigned to an exclusive stack it its current form (there are no /dev/ce devices). Should 'ce' be made into DLPI style 1 in the future (either explicitly, or by Clearview Nemo Unification) we need to address this. That can easily be handled e.g. by requiring PRIV_SYS_NET_CONFIG for ND_SET ioctls in GLD or in softmac. What are the device security issues exposed? Not any different than when e.g., /dev/bge1 is explicitly given to a zone so it can snoop. It is extremely unlikely that any DLPI style 1 device has a ndd hack like the 'ce' 'instance'. And many driver check for PRIV_SYS_NET_CONFIG for operations that change settings (even though they only apply to the instance that is open.) There is always the possibility that a device driver has bugs. In some cases IP/ARP might not trigger those bugs but a malicious application using DLPI might be able to trigger them. I expect we will handle such bugs using our normal quality processes. (Not an ARC issue, but you may want to check if there are any well-known /etc/system hacks that'll be unsupportable here. We've already had quite a few questions about kernel tuning within non-global zones.) I don't understand what type of /etc/system hacks you want us to consider. Do you have an example? /etc/system and driver.conf settings for network device drivers is something we want to move away from, and the things like the dladm properties (which can be extended to allow configuring jumbo-frames) are definitely the right way to go. jdc-9 Section 5 of the design says that non-global Zone users cannot add their own kernel modules for things such as Checkpoint, the Cisco VPN, or just a private build of ipf. How do we document that these independent stacks are not always independent? We already make it clear that with zones there is a single kernel. Thus clueful customers will infer that untrusted parties can't load random kernel modules into the single kernel. We will also make it clear that "stack instances" applies to the TCP/IP layer of the stack (layer 3 and 4 in the ISO reference model) and explain the distinct separation between this and the datalink (layer 2), with the datalink being managed by dladm etc. jdc-10 Would like DR details (particularly which administrator does what, and how the global and non-global zones coordinate) for commitment. We will provide an example of how this can be coordinated. jdc-11 What are the advantages of stack instances over Xen? (If we plan to ship Xen anyway, what things can Xen _not_ do, and does it make more sense to extend Zones than to enhance Xen?) It is clear that virtualization is something that will span our product line, with virtualization components and solutions from the hardware (e.g., virtualizable NICs) all the way up to the applications. There are tradeoffs in what layer the virtualization is applied, and in some cases it might make sense to combine them. For instance, using Xen as a way to get live migration, but then inside a Xen domU run multiple zones that share the resources. Examples of what Xen can not do that Zones can do (and stack instances doesn't change this) are - amortize the OS maintenance cost across multiple "blobs" (Note: I don't have a good term that captures the general notion of separate domains or containers, hence I arbitrarily pick the term "blob" for this answer) - share VM pages for the same read-only pages across "blobs" (e.g., a single copy of libc text) - very efficiently do fine grain and statistical sharing of machine resources such as CPU and memory. Hardware virtualization schemes end up with a two-layer approach to resource management, where the hypervisor does one layer of it and then the OS has its own management above. For instance, the hypervisor "scheduler" might not be aware that the OS is running in the idle loop. When we care about soft realtime this becomes even more apparent. - hardware independence; same approach works on sun4u, sun4v, x64. I don't know if PSARC desires more discussion about our virtualization strategy; typically the ARC doesn't review the business strategy. jdc-12 nit:Where do the moduleid values come from? (Why doesn't netstack_register just return an opaque pointer?) What does a module_create implementation do with a 'netstack_t' pointer? The moduleids are defined in netstack.h. This flexibility is sufficient. See section 13 in si-interfaces.pdf. The design (don't think this is architecture) needs to provide efficient ways get from e.g., a tcp_stack_t to an ip_stack_t when tcp is going to do an IRE lookup, and the fixed definition allows for this. The module_create functions record the netstack_t pointer in their per-stack data structure (e.g., tcp_stack_t). That way the tcp can get to the ip_stack_t by following the pointers: tcps->tcp_netstack->netstack_ip. jdc-13 nit:Could the kstat and other interfaces avoid having a netstackid_t value? It seems like merely having an "instance-per-stack" flag should be enough, since the user shouldn't be creating kstats for zones other than his own. It isn't the user that is causing the kstats to be created but the initialization of the zone. This hangs of the zsd callbacks in the zones framework, and that is driven from the zone_create() system call. The zone_create() system call is called from the global zone, hence it is not possible to use an implicit way to determine the zoneid or netstackid; it needs to be explicitly passed as an argument. gcs-1 Is there any need for other sharing configurations, say zones A and B sharing a stack, with that stack independent of the global zone's stack? What would have to change in your design to allow such additional flexibility? We haven't identified such a need even though the theoretical possibility has been discussed. For instance, in addition to the above case, what would happen if zones were hierarchical so that a non-global zone could create sub-zones, or having a separate stack per projectid? Even though there is no forseen need to handle this generality, the design of the netstack framework has taken the possibility into account, by providing routines that hide as much as possible the relationship between zoneids and netstackids, and hide the relationship between the thread that calls xx_open() and the netstack it uses. Thus if we need to support some other model in the future, the bulk of the changes would be in the configuration layer. Assuming we still use zonecfg to configure things at that possible future date, zonecfg would potentially need different configuration options. gw-1 nit: Perhaps UIRB should be consulted to see if there is a more admin friendly way to represent "stacktype=exclusive | shared" I recall seeing some email that UIRB doesn't review CLIs. What is the current state? gw-2 Please check with the TX project team (Jarrett Lu) for any overlaps. Will do? gw-3 Presumably SDP or IB is not covered in a per-zone way by this project. Correct. gw-4 nit: Evolving and Stable in the interface table. Maybe more than a nit. Is there a transition plan for move from the old to the new taxonomy? As I understand it, there isn't a 1-1 mapping (or N-1 mapping) from old to new. For the imported interfaces, clearly(?) I must re-state what was actually used by the case that introduced those interfaces. For the exported interfaces I want them to "be the same as those exports in PSARC XXX/YYY", but without a N-1 mapping from old to new I can't express that. gw-5 4. Goals -- IPsec includes IKE right :-) Correct. gw-6 5. Non-Goals -- How will the admin know that aggregation needs to be done in the global zone for exclusive stacks? Same way that the global admin in S10 knows to apply aggregation or IPMP or something else for the non-global zones. Is there a need for per-zone network resource limits? What limits did you have in mind? Bandwidth? The Crossbow project is working on bandwidth limits, that can be tied to zones, Xen instances, etc. gw-7 nit: 6.3 s/global/exclusive/ Thanks. --- From sacadmin Wed Jul 26 11:38:41 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6QIceXZ013207 for ; Wed, 26 Jul 2006 11:38:41 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k6QIe4e9018434; Wed, 26 Jul 2006 14:40:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.7+Sun/8.13.7/Submit) id k6QIe4a5018431; Wed, 26 Jul 2006 14:40:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17607.46852.179377.16358@gargle.gargle.HOWL> Date: Wed, 26 Jul 2006 14:40:04 -0400 From: James Carlson To: Erik Nordmark Cc: psarc , crossbow-core@sun.com Subject: Re: Initial response to issues (PSARC 2006/366) In-Reply-To: Erik Nordmark's message of 26 July 2006 10:04:36 References: <44C7A0A4.3090007@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 18648 Erik Nordmark writes: > jdc-1 Why is the interface address configuration done from zonecfg? > > Answer: It follows the existing zones model of configuring IP addresses > from > zonecfg. It is important to minimize the differences between configuring > a shared-stack zone and an exclusive-stack zone. But the existing zones model is predicated on the notion that one cannot configure interfaces from inside the zone. Having stack instances changes this model quite dramatically. This now leaves us with stack instances being a special case: unlike all previous incarnations of zones (global and non-global), it has _two_ separate and overlapping administrative interfaces. > This means that an exclusive stack owner can't control his own > network interface properties, except after the fact, and > possibly at odds with the global zone administrator. > > The non-global admin can control its own network configuration. But see > section 12 in si-interfaces.pdf on the choices of creating/updating the > /etc/ network files on zone install vs. zone boot. The part that confused me here is that we don't seem to have a preferred solution. > Note that the current approach in this case doesn't prevent other projects > to change the zone's model for network configuration to allow use of the > normal sysid mechanism for configuring network parameters. I'm asking how they should interact. We once had just one way to configure interfaces for any one zone. In the global zone, it's the /etc/* files. In all non-global zones, it's zonecfg. Zonecfg doesn't work for the global zone and /etc/* files don't work in the non-global zones. Perhaps that asymmetry is unfortunate, but it's the model we've been using. This new feature adds another possibility: the interfaces are configured both in zonecfg _and_ /etc/* files. So, which one is authoritative? There are things you can express in /etc/* files that cannot be expressed in the far more restrictive zonecfg syntax. If they're not just at odds with each other, how would this be handled? > (Why not control other aspects of network configuration, such > as which routing daemons to run, from zonecfg as well? What's > the administrative model that requires only addresses and > static default routes, especially given "route -p"?) > > The above seems like issues with the original zones case and not this case. > One could likewise have argued that PSARC 2002/174 should have allowed > specifying other or all aspects of network configuration (such as > nsswitch.conf, resolv.conf, etc) in zonecfg, but it did not. No, I'm asking about this project in particular. The original Zones case had no possibility of running any routing protocol daemon inside the non-global zones, because _all_ of the routing configuration was done out in the global zone. Thus, asking a question about how you'd configure it to do that doesn't make any sense. This project proposes something different. Some of the properties related to interface and route configuration can be administered from the global zone only (e.g., aggregations), some can be configured from inside the non-global zone alone (e.g., static routes other than default), and some are in both places (e.g., IP addresses and static default routes). I find this very confusing, especially with respect to the configuration of static default routes. Why are default routes special? Why would we configure static default routes from the global zone, but require all other static routes and dynamic routing protocols within the non-global zone? Why is it that the global zone administrator knows about the internal network topology for the non-global zone? In other words, how does he know what the right next hop address might be for those default routes? (More subtly: if he configures a _name_ for that next hop address, should he use a name that's known in the global zone's attached IP network, or one that's known to the non-global zone's network? And if it's the latter, how do you do zone-context-specific name service queries?) > Section 5 of the design says the opposite of this -- it says > that the existing /etc files are used in the non-global zone > for configuration. > > Where do you see an inconsistency in the materials? AFAIK the materials > are self-consistent on this issue. The conflict is between this in the 20q: For an exclusive stack, the user specifies the basic network configuration (IP addresses) in zonecfg as before, [...] and this in the si-interfaces.pdf document: No change to how IP is configured in Solaris,in particular,this project does not take the various networking /etc files (/etc/hostname.,/etc/defaultrouter,/etc/resolv.conf)and replace them by something else like SMF properties.A result of this is that for exclusive stack zones we rely on the /etc files to configure the exclusive stack. Those two don't seem to say the same thing at all. > And section 12 provides options, but > doesn't seem to recommend a particular solution. > > We are actively seeking the feedback from the ARC on that issue, which is > why it is explicitly flagged. Sorry if this wasn't clear. The response to #19 in the 20q is empty ... so I missed the flag. The one option that's left out of here (and the one that I _thought_ would have been the most obvious solution for stack instances, and the first option I would have suggested) would be: If you declare a zone to have a stack instance, then you cannot configure any of the IP parameters within zonecfg. It's illegal to specify any "add net" sections for a non-global zone that has an exclusive stack. Instead, you must delegate DLPI nodes (whole network devices or VLANs) to the non-global zone. The configuration of IP within the zone takes place with the same interfaces as would be used in a regular global zone. > That middle ground has been requested by some, but the customers I've > talked to > don't see a need for this. (When they are consolidating applications from > multiple servers, they already have some approach to how they handle root > access on the individual servers - e.g. the "application admin" might > have the root, or might not.) When consolidating those applications they > can just continue using the same model (e.g., whether or not the application > admin has the root password for "its" non-global zone.) It sounds to me like using the same mechanism (whatever that might be -- RBAC?) for both whole separate systems and these new stack-instance zones would be best. Having different mechanisms to enforce security in different contexts is probably not a safe thing for customers to do. That said, 'restrict' is still puzzling to me. It seems to imply that we somehow plumb an interface out in the global zone (it's the global zone that has the privilege to change addresses when 'restrict' is in effect, right?) but that the interface itself is inside the non-global zone. Or perhaps it means that we're restrictive only sometimes -- processes in the non-global zone can sometimes set up addresses but other times cannot. Or maybe it actually sets up a filter of sorts in the kernel: "zone X may at its discretion configure the following addresses, on these given interfaces, but no other." If so, should this feature play into regular Solaris in any way? Is this perhaps a more general feature? I suppose I'd like to know more details about how this mechanism will function by commitment. > Couldn't a really malicious user just open a raw driver and > start transmitting gratuitous ARP messages for someone else's > address? > > That is correct. The 'restrict=true' prevents against accidental > misconfiguration but not against root in the zone running its own DLPI > application which sends bogus ARP packets. OK. > As an aside, we have an opportunity to differentiate ourselves in this space > in the future. I think the right long-term direction, which applies to > Xen/LDOMs/zones, is to introduce IP Filter hooks in the GLD layer and > make it > easy to create filter expressions for ARP and Neighbor Discovery packets. > That would allow us to have the machine administrator enforce network > security > independent of the domU or zone that uses a NIC to access the network. Yes, I agree with that. > jdc-5 KSSL identifies particular user applications based on > configuration. How is this virtualized so that one zone > cannot affect another? > > See section 5 in si-interfaces.pdf. > > The virtualization of kernel network components above the transport layer > (NFS, KSSL, NL7C, etc) are out of scope. > Furthermore, if/when they are virtualized they should be make "zone > aware" and > not "stack instance aware" since at that layer there are no direct function > calls into IP. The distinction here is that this is one of the many things that need to be roped off. As this project rightly asserts, many of our current problems stem from past assertions that Zones would virtualize networking. Zones only partly does so, and thus works for some usages but not others. It seems to me that it would be harmful to tell customers that, unlike those past bad marketing messages and limited implementation, we've "really" virtualized networking this time around -- only to allow them to discover later that this is _NOT_ true, and that many things still remain unvirtualized and unavailable to non-global zones. > jdc-7 Can exclusive stack instances run NFS servers? If not, are > there other "normal" Solaris networking features that are > prohibited as well, and how does the user find out? > > See answer to jdc-5. > Presumably the user finds this out the same way s/he finds out that one > can't run an NFS server in a non-global zone in S10. But the two are very different. We're giving the stack-instance zone user the ability to control his network interfaces directly, and we're advertising it as better virtualization. In fact, one of the many reasons you might want to have stack instances is so that you can run a set of servers that are private to a given network. For example, Solaris boot servers. Unfortunately, if the customer chooses stack instances to implement such a network, he cannot have NFS servers. We just have no way of supplying that, because rpcmod isn't on the list. > jdc-8 What about ndd hacks, such as ip_squeue_enter or the really > awful 'hme instance' value? Are those independent in these > zones? (I don't see how the latter could be -- if I delegate > hme0 to zone A and hme1 to zone B, I don't want zone A doing > "ndd -set /dev/hme instance 1," but I don't see how I can stop > it.) > > ip_squeue_enter and the like will require PRIV_SYS_NET_CONFIG hence will > only > be allowed in the global zone. (The squeues are effectively a scheduling > concept whose number is based on the number of CPUs, hence having more of > them when there are more zones doesn't make sense.) > > 'hme instance' doesn't exist. See the 'hme_device' static variable in $SRC/uts/sun/io/hme.c. And, of course: # ndd /dev/hme \? | grep instance instance (read and write) It's stealthy, but it's there. > I think it does exist for 'ce'. Yep. > Since 'ce' is DLPI style 2 it can not be assigned to an exclusive stack > it its > current form (there are no /dev/ce devices). Oh. So, if DLPI Style 2 cannot be delegated, this means that PPP links cannot be used in these exclusive stack instance zones. Also true of some third party Ethernet devices. Can tunnels be used? (I'd imagine so ... but since it's not just an unequivocal "yes," it should be documented.) > What are the device security issues exposed? > > Not any different than when e.g., /dev/bge1 is explicitly given to a zone > so it can snoop. > > It is extremely unlikely that any DLPI style 1 device has a ndd hack like > the 'ce' 'instance'. And many driver check for PRIV_SYS_NET_CONFIG for No, not like that, though other hacks are possible. > operations that change settings (even though they only apply to the instance > that is open.) There is always the possibility that a device driver has > bugs. > In some cases IP/ARP might not trigger those bugs but a malicious > application > using DLPI might be able to trigger them. I expect we will handle such bugs > using our normal quality processes. OK. > (Not an ARC issue, but you may want to check if there are any > well-known /etc/system hacks that'll be unsupportable here. > We've already had quite a few questions about kernel tuning > within non-global zones.) > > I don't understand what type of /etc/system hacks you want us to consider. > Do you have an example? I'm thinking of things like this: http://docs.sun.com/source/819-0084-10/pt_tuningos.html#wp61914 I suspect there are quite a few others like this. I'm not asking for an exhaustive search, but rather a quick check to make sure that there won't be any obvious escalations shortly after customers start trying to use stack instances. > /etc/system and driver.conf settings for network device drivers is something > we want to move away from, and the things like the dladm properties (which > can be extended to allow configuring jumbo-frames) are definitely the right > way to go. Sure. But prior to stack instances, there wasn't any notion of a non-global zone somehow "owning" an interface. That ownership changes things -- the owner of an interface should be able to configure it as well. Until those things change, tuning those sorts of things can't be done as expected. > jdc-9 Section 5 of the design says that non-global Zone users cannot > add their own kernel modules for things such as Checkpoint, > the Cisco VPN, or just a private build of ipf. > > How do we document that these independent stacks are not > always independent? > > We already make it clear that with zones there is a single kernel. > Thus clueful customers will infer that untrusted parties can't load random > kernel modules into the single kernel. I think that misses the point of my question. By the same argument, clueful customers should never have been confused that the existing Zones model would have provided a completely separate networking model. After all, there's only one TCP/IP stack and the global zone owns and controls all of the network interfaces and routes, so how could it be otherwise? I'm concerned about how we make it clear that, like the original Zones project, stack instances isn't a panacea either. We should not make this mistake twice. It's an improvement on Zones, but it does *not* provide the completely isolated networking environment that some might hope that it does. It's explicitly *not* the same as having a separate system. > We will also make it clear that "stack instances" applies to the TCP/IP > layer > of the stack (layer 3 and 4 in the ISO reference model) and explain the > distinct separation between this and the datalink (layer 2), with the > datalink > being managed by dladm etc. There are fingers that extend upwards here -- due to other bits of the system (such as rpcmod) being not yet virtualized. That's not a complete description of the administrative model. > - amortize the OS maintenance cost across multiple "blobs" (Note: I don't > have a good term that captures the general notion of separate domains or > containers, hence I arbitrarily pick the term "blob" for this answer) Arguably, that's something that can and should be dealt with by install tools (such as flash archives and even ZFS-based cloning). The flip side of it is that Xen allows you to schedule your maintenance independently. With Zones, you have to arrange to tear down all of your non-global zones at once in order to patch something, and some things (actually, many things) cannot differ between zones even if you use the "whole root" model, due to tangled dependencies. It's not a simple win. > - share VM pages for the same read-only pages across "blobs" (e.g., a > single > copy of libc text) True. > - very efficiently do fine grain and statistical sharing of machine > resources > such as CPU and memory. Hardware virtualization schemes end up with a > two-layer approach to resource management, where the hypervisor does one > layer of it and then the OS has its own management above. For instance, > the hypervisor "scheduler" might not be aware that the OS is running in > the idle loop. When we care about soft realtime this becomes even more > apparent. Perhaps ... but this raises a different issue about how Xen and hypervisors in general ought to interact with scheduling. Though it's obviously outside the scope of this case, I'm not convinced that it's impossible or even "too hard" to get this right in a virutalized environment. > - hardware independence; same approach works on sun4u, sun4v, x64. That still doesn't grab me, as making Xen more common would also make it more valuable. It's not an intrinsic limitation. > I don't know if PSARC desires more discussion about our virtualization > strategy; typically the ARC doesn't review the business strategy. I'm not asking to review any business strategy. We have multiple projects playing in the same logical area that are headed through the ARC at the same time. Distinguishing them will help immensely. This *IS* architecture: how the projects all fit together to give customers a good experience and sound solutions on Solaris. Having projects that duplicate each other in functional ways promotes confusion, which is one of the things we try to avoid. If the ARC isn't expected to look at the functional and administrative overlaps between various large projects, perhaps you could suggest some other body at Sun that is in fact reviewing these things. Would that be Solaris PAC? > The module_create functions record the netstack_t pointer in their per-stack > data structure (e.g., tcp_stack_t). That way the tcp can get to the > ip_stack_t by following the pointers: tcps->tcp_netstack->netstack_ip. OK; that's the missing part. The model isn't opaque. > It isn't the user that is causing the kstats to be created but the > initialization of the zone. This hangs of the zsd callbacks in the zones > framework, and that is driven from the zone_create() system call. OK; I see what's going on now. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Jul 26 12:25:10 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6QJPAJ2016382 for ; Wed, 26 Jul 2006 12:25:10 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6QJPAZH008602; Wed, 26 Jul 2006 12:25:10 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k6QJPnOI005755; Wed, 26 Jul 2006 12:25:49 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k6QJPn1w005754; Wed, 26 Jul 2006 12:25:49 -0700 (PDT) Date: Wed, 26 Jul 2006 12:25:49 -0700 (PDT) From: Gary Winiger Message-Id: <200607261925.k6QJPn1w005754@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com, erik.nordmark@sun.com Subject: Re: Initial response to issues (PSARC 2006/366) Cc: crossbow-core@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1838 > gw-1 nit: Perhaps UIRB should be consulted to see if there is a more > admin friendly way to represent "stacktype=exclusive | shared" > > I recall seeing some email that UIRB doesn't review CLIs. > What is the current state? At last ARC chairs UIRB asked for help from the ARCs to point projects to them. This included command lines. Since zonecfg exists and this is an addition to it, the existing command syntax and semantics should be a precedent to UIRB. "stacktype=exclusive | shared" just struck me as not as intuitive as it might be, so rather than design on the fly, UIRB is in the position to make suggestions. > gw-4 nit: Evolving and Stable in the interface table. > > Maybe more than a nit. > > Is there a transition plan for move from the old to the new taxonomy? New cases go there for exported interfaces. > For the imported interfaces, clearly(?) I must re-state what was > actually used > by the case that introduced those interfaces. > > For the exported interfaces I want them to "be the same as those exports in > PSARC XXX/YYY", but without a N-1 mapping from old to new I can't > express that. That's my perspective. > gw-6 5. Non-Goals -- How will the admin know that aggregation needs > to be done in the global zone for exclusive stacks? > > Same way that the global admin in S10 knows to apply aggregation or IPMP > or something else for the non-global zones. Well, with perzone stacks that may no longer be clear to the admin. Perhaps the perzone stacks documentation could point out the things that still need to be done in the global zone. > Is there a need for per-zone network resource limits? > > What limits did you have in mind? > Bandwidth? Yes > The Crossbow project is working on bandwidth limits, that can be tied to > zones, Xen instances, etc. OK. Gary.. From sacadmin Wed Jul 26 12:34:40 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6QJYeWZ016835 for ; Wed, 26 Jul 2006 12:34:40 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k6QJYe2Z010214 for ; Wed, 26 Jul 2006 12:34:40 -0700 (PDT) Received: from d1-sfbay-05.sun.com ([192.18.39.115]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6QJYZKD018410 for ; Wed, 26 Jul 2006 12:34:35 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-05.sun.com by d1-sfbay-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J3000001ZAK0Q00@d1-sfbay-05.sun.com> (original mail from Sherri.Shieh@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 26 Jul 2006 12:34:34 -0700 (PDT) Received: from [129.150.21.135] by d1-sfbay-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J3000J86ZPMPR20@d1-sfbay-05.sun.com>; Wed, 26 Jul 2006 12:34:34 -0700 (PDT) Date: Wed, 26 Jul 2006 12:34:31 -0700 From: Sherri Shieh Subject: Re: Initial response to issues (PSARC 2006/366) In-reply-to: <44C7A0A4.3090007@sun.com> Sender: Sherri.Shieh@Sun.COM To: Erik Nordmark Cc: psarc , crossbow-core@Sun.COM Reply-to: Sherri.Shieh@Sun.COM Message-id: <44C7C3C7.7010805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <44C7A0A4.3090007@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 17962 These have been added to the issues file. - Sherri ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, Systems Architecture Sun Microsystems, Inc. Phone: 650-786-5245/x85245 Email: Sherri.Shieh@sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erik Nordmark wrote: > > Since I'll be on the phone I figured I could try to improve the > communication efficiency by sending out an initial cut at written > answers. > > I'll watch the issues file and might send responses to additional > issues before the meeting. > > Erik > > #ident "@(#)issues 1.2 06/07/25 SAC" > > PSARC 2006/366: Stack instances: Exclusive IP stack per zone > Submitter: Erik Nordmark > Owner: Kais Belgaied > Intern: Rick Matthews > > Issues for inception (07/26/2006): > > jdc-1 Why is the interface address configuration done from zonecfg? > > Answer: It follows the existing zones model of configuring IP > addresses from > zonecfg. It is important to minimize the differences between configuring > a shared-stack zone and an exclusive-stack zone. > > This means that an exclusive stack owner can't control his own > network interface properties, except after the fact, and > possibly at odds with the global zone administrator. > > The non-global admin can control its own network configuration. But see > section 12 in si-interfaces.pdf on the choices of creating/updating the > /etc/ network files on zone install vs. zone boot. > > Note that the current approach in this case doesn't prevent other > projects > to change the zone's model for network configuration to allow use of the > normal sysid mechanism for configuring network parameters. > > (Why not control other aspects of network configuration, such > as which routing daemons to run, from zonecfg as well? What's > the administrative model that requires only addresses and > static default routes, especially given "route -p"?) > > The above seems like issues with the original zones case and not this > case. > One could likewise have argued that PSARC 2002/174 should have allowed > specifying other or all aspects of network configuration (such as > nsswitch.conf, resolv.conf, etc) in zonecfg, but it did not. > > jdc-2 How exactly do interface bring-up and route configuration > work? Does zoneadmd enter the zone to do these things -- if > so, how is that coordinated with IP Filter configuration? If > not, then how do the zonecfg-configured values end up in the > non-global zone where the normal boot process can use them? > > See section 12 in si-interfaces.pdf > > If we are going to update the files on each zone boot, then we will use > the design pattern that Zulu uses (fork + zone_enter to create the file). > If we are only going to create the files when the zone is installed, > we'll > just have zoneadm install create them while running in the global zone. > > How does dhcpagent inside the non-global zone find out that > zonecfg in the global zone has told it to run on some > interface? > > The normal mechanism that is used in the global zone in S10 - the > existence > of /etc/dhc.. > > Section 5 of the design says the opposite of this -- it says > that the existing /etc files are used in the non-global zone > for configuration. > > Where do you see an inconsistency in the materials? AFAIK the materials > are self-consistent on this issue. > > And section 12 provides options, but > doesn't seem to recommend a particular solution. > > We are actively seeking the feedback from the ARC on that issue, which is > why it is explicitly flagged. Sorry if this wasn't clear. > > jdc-3 What can 'restrict' really do? Why can't a non-global zone > steal an address from another machine? Why can't a malicious > user just run ifconfig _after_ the zone boots and the > restriction is gone? Why is the flag needed? > > See section 9 in si-interfaces.pdf. > > The implementation of the enforcement is done in the kernel, so that > the various ioctls that set/change an IP address or make ARP publish > an entry, check against the restriction. > > Thus the non-global admin can invoke ifconfig to try to change its IP > address > or do an 'addif', but the ioctl will fail with EPERM. > > The need for this is to allow a middle ground between the current > shared-stack > model (where the non-global zone doesn't have the privileges to do any of > this) and an exclusive stack with unrestricted ability to do things on > the network. > That middle ground has been requested by some, but the customers I've > talked to > don't see a need for this. (When they are consolidating applications from > multiple servers, they already have some approach to how they handle root > access on the individual servers - e.g. the "application admin" might > have the root, or might not.) When consolidating those applications they > can just continue using the same model (e.g., whether or not the > application > admin has the root password for "its" non-global zone.) > > Couldn't a really malicious user just open a raw driver and > start transmitting gratuitous ARP messages for someone else's > address? > > That is correct. The 'restrict=true' prevents against accidental > misconfiguration but not against root in the zone running its own DLPI > application which sends bogus ARP packets. > > You get the same type of protection with a exclusive-stack zone with > 'restrict=true' as you get with in S10 when a zone has been given > access to > snooping on a NIC (e.g., by adding device access to /dev/bge1 in > zonecfg). > > As an aside, we have an opportunity to differentiate ourselves in this > space > in the future. I think the right long-term direction, which applies to > Xen/LDOMs/zones, is to introduce IP Filter hooks in the GLD layer and > make it > easy to create filter expressions for ARP and Neighbor Discovery packets. > That would allow us to have the machine administrator enforce network > security > independent of the domU or zone that uses a NIC to access the network. > > jdc-4 20q8 says that link aggregation is supported in non-global > zones, but section 5 of the design says that it can't be > supported. Which is true? > > Good catch. > 20q8 is incorrect. An aggregate has to be configured in the global zone. > (It is probably possible to relax this in the future, but the details > depend > on how one could handle the Clearview vanity names creating entries > in /dev/net.) > > jdc-5 KSSL identifies particular user applications based on > configuration. How is this virtualized so that one zone > cannot affect another? > > See section 5 in si-interfaces.pdf. > > The virtualization of kernel network components above the transport layer > (NFS, KSSL, NL7C, etc) are out of scope. > Furthermore, if/when they are virtualized they should be make "zone > aware" and > not "stack instance aware" since at that layer there are no direct > function > calls into IP. > > jdc-6 Can exclusive stack instances communicate with each other? > Does doing so require external hardware or something delivered > from Crossbow? > > The purpose of this project is isolation and not communication, because > that is where the pressing customer need exists. Thus communication > between > separate stack instances will be done via external devices (Ethernet > switches, > routers, firewalls, load balancers, etc). > > In the future we expect that the Crossbow project will provide GLDv3 > devices that will additionally allow for cases when strict isolation > isn't > necessary, e.g. when separate stacks want to be able to communicate > inside > the server. > > jdc-7 Can exclusive stack instances run NFS servers? If not, are > there other "normal" Solaris networking features that are > prohibited as well, and how does the user find out? > > See answer to jdc-5. > Presumably the user finds this out the same way s/he finds out that one > can't run an NFS server in a non-global zone in S10. > > jdc-8 What about ndd hacks, such as ip_squeue_enter or the really > awful 'hme instance' value? Are those independent in these > zones? (I don't see how the latter could be -- if I delegate > hme0 to zone A and hme1 to zone B, I don't want zone A doing > "ndd -set /dev/hme instance 1," but I don't see how I can stop > it.) > > ip_squeue_enter and the like will require PRIV_SYS_NET_CONFIG hence > will only > be allowed in the global zone. (The squeues are effectively a scheduling > concept whose number is based on the number of CPUs, hence having more of > them when there are more zones doesn't make sense.) > > 'hme instance' doesn't exist. I think it does exist for 'ce'. > Since 'ce' is DLPI style 2 it can not be assigned to an exclusive > stack it its > current form (there are no /dev/ce devices). > > Should 'ce' be made into DLPI style 1 in the future (either > explicitly, or > by Clearview Nemo Unification) we need to address this. > That can easily be handled e.g. by requiring PRIV_SYS_NET_CONFIG for > ND_SET > ioctls in GLD or in softmac. > > What are the device security issues exposed? > > Not any different than when e.g., /dev/bge1 is explicitly given to a zone > so it can snoop. > > It is extremely unlikely that any DLPI style 1 device has a ndd hack like > the 'ce' 'instance'. And many driver check for PRIV_SYS_NET_CONFIG for > operations that change settings (even though they only apply to the > instance > that is open.) There is always the possibility that a device driver > has bugs. > In some cases IP/ARP might not trigger those bugs but a malicious > application > using DLPI might be able to trigger them. I expect we will handle such > bugs > using our normal quality processes. > > (Not an ARC issue, but you may want to check if there are any > well-known /etc/system hacks that'll be unsupportable here. > We've already had quite a few questions about kernel tuning > within non-global zones.) > > I don't understand what type of /etc/system hacks you want us to > consider. > Do you have an example? > > /etc/system and driver.conf settings for network device drivers is > something > we want to move away from, and the things like the dladm properties > (which > can be extended to allow configuring jumbo-frames) are definitely the > right > way to go. > > jdc-9 Section 5 of the design says that non-global Zone users cannot > add their own kernel modules for things such as Checkpoint, > the Cisco VPN, or just a private build of ipf. > > How do we document that these independent stacks are not > always independent? > > We already make it clear that with zones there is a single kernel. > Thus clueful customers will infer that untrusted parties can't load > random > kernel modules into the single kernel. > > We will also make it clear that "stack instances" applies to the > TCP/IP layer > of the stack (layer 3 and 4 in the ISO reference model) and explain the > distinct separation between this and the datalink (layer 2), with the > datalink > being managed by dladm etc. > > jdc-10 Would like DR details (particularly which administrator does > what, and how the global and non-global zones coordinate) for > commitment. > > We will provide an example of how this can be coordinated. > > jdc-11 What are the advantages of stack instances over Xen? (If we > plan to ship Xen anyway, what things can Xen _not_ do, and > does it make more sense to extend Zones than to enhance Xen?) > > It is clear that virtualization is something that will span our > product line, > with virtualization components and solutions from the hardware (e.g., > virtualizable NICs) all the way up to the applications. > > There are tradeoffs in what layer the virtualization is applied, and > in some > cases it might make sense to combine them. For instance, using Xen as > a way > to get live migration, but then inside a Xen domU run multiple zones > that share > the resources. > > Examples of what Xen can not do that Zones can do (and stack instances > doesn't change this) are > - amortize the OS maintenance cost across multiple "blobs" (Note: I > don't > have a good term that captures the general notion of separate > domains or > containers, hence I arbitrarily pick the term "blob" for this answer) > - share VM pages for the same read-only pages across "blobs" (e.g., a > single > copy of libc text) > - very efficiently do fine grain and statistical sharing of machine > resources > such as CPU and memory. Hardware virtualization schemes end up with a > two-layer approach to resource management, where the hypervisor > does one > layer of it and then the OS has its own management above. For > instance, > the hypervisor "scheduler" might not be aware that the OS is > running in > the idle loop. When we care about soft realtime this becomes even more > apparent. > - hardware independence; same approach works on sun4u, sun4v, x64. > > I don't know if PSARC desires more discussion about our virtualization > strategy; typically the ARC doesn't review the business strategy. > > jdc-12 nit:Where do the moduleid values come from? (Why doesn't > netstack_register just return an opaque pointer?) What does a > module_create implementation do with a 'netstack_t' pointer? > > The moduleids are defined in netstack.h. This flexibility is > sufficient. See > section 13 in si-interfaces.pdf. > > The design (don't think this is architecture) needs to provide > efficient ways > get from e.g., a tcp_stack_t to an ip_stack_t when tcp is going to do an > IRE lookup, and the fixed definition allows for this. > > The module_create functions record the netstack_t pointer in their > per-stack > data structure (e.g., tcp_stack_t). That way the tcp can get to the > ip_stack_t by following the pointers: tcps->tcp_netstack->netstack_ip. > > jdc-13 nit:Could the kstat and other interfaces avoid having a > netstackid_t value? It seems like merely having an > "instance-per-stack" flag should be enough, since the user > shouldn't be creating kstats for zones other than his own. > > It isn't the user that is causing the kstats to be created but the > initialization of the zone. This hangs of the zsd callbacks in the zones > framework, and that is driven from the zone_create() system call. > The zone_create() system call is called from the global zone, hence it is > not possible to use an implicit way to determine the zoneid or > netstackid; it > needs to be explicitly passed as an argument. > > gcs-1 Is there any need for other sharing configurations, say zones A > and B sharing a stack, with that stack independent of the > global zone's stack? What would have to change in your design > to allow such additional flexibility? > > We haven't identified such a need even though the theoretical > possibility has > been discussed. For instance, in addition to the above case, > what would happen if zones were hierarchical so > that a non-global zone could create sub-zones, or having a separate stack > per projectid? > > Even though there is no forseen need to handle this generality, the > design > of the netstack framework has taken the possibility into account, by > providing > routines that hide as much as possible the relationship between > zoneids and > netstackids, and hide the relationship between the thread that calls > xx_open() > and the netstack it uses. > > Thus if we need to support some other model in the future, the bulk of > the > changes would be in the configuration layer. Assuming we still use > zonecfg to > configure things at that possible future date, zonecfg would potentially > need different configuration options. > > gw-1 nit: Perhaps UIRB should be consulted to see if there is a more > admin friendly way to represent "stacktype=exclusive | shared" > > I recall seeing some email that UIRB doesn't review CLIs. > What is the current state? > > gw-2 Please check with the TX project team (Jarrett Lu) for any > overlaps. > > Will do? > > gw-3 Presumably SDP or IB is not covered in a per-zone way by this > project. > > Correct. > > gw-4 nit: Evolving and Stable in the interface table. > > Maybe more than a nit. > > Is there a transition plan for move from the old to the new taxonomy? > As I understand it, there isn't a 1-1 mapping (or N-1 mapping) from > old to > new. > > For the imported interfaces, clearly(?) I must re-state what was > actually used > by the case that introduced those interfaces. > > For the exported interfaces I want them to "be the same as those > exports in > PSARC XXX/YYY", but without a N-1 mapping from old to new I can't > express that. > > gw-5 4. Goals -- IPsec includes IKE right :-) > > Correct. > > gw-6 5. Non-Goals -- How will the admin know that aggregation needs > to be done in the global zone for exclusive stacks? > > Same way that the global admin in S10 knows to apply aggregation or IPMP > or something else for the non-global zones. > > Is there a need for per-zone network resource limits? > > What limits did you have in mind? > Bandwidth? > > The Crossbow project is working on bandwidth limits, that can be tied to > zones, Xen instances, etc. > > gw-7 nit: 6.3 s/global/exclusive/ > > Thanks. > > --- > > From sacadmin Tue Aug 1 07:37:38 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k71EbcF5014958 for ; Tue, 1 Aug 2006 07:37:38 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.7+Sun/8.13.6) with ESMTP id k71EbWnr807463 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Aug 2006 07:37:35 -0700 (PDT) Message-ID: <44CF672B.7070402@sun.com> Date: Tue, 01 Aug 2006 07:37:31 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Gary Winiger CC: psarc@sac.sfbay.sun.com, crossbow-core@sun.com Subject: Re: Initial response to issues (PSARC 2006/366) References: <200607261925.k6QJPn1w005754@marduk.eng.sun.com> In-Reply-To: <200607261925.k6QJPn1w005754@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1482 Gary Winiger wrote: > At last ARC chairs UIRB asked for help from the ARCs to point > projects to them. This included command lines. Since > zonecfg exists and this is an addition to it, the existing > command syntax and semantics should be a precedent to UIRB. > "stacktype=exclusive | shared" just struck me as not as > intuitive as it might be, so rather than design on the fly, > UIRB is in the position to make suggestions. Who do I contact at the UIRB? >> gw-4 nit: Evolving and Stable in the interface table. >> For the exported interfaces I want them to "be the same as those exports in >> PSARC XXX/YYY", but without a N-1 mapping from old to new I can't >> express that. > > That's my perspective. I don't understand what you say is your perspective. Can you clarify how I can express "same as in the original Zones PSARC case" for the exported interfaces that I am adding? >> gw-6 5. Non-Goals -- How will the admin know that aggregation needs >> to be done in the global zone for exclusive stacks? > Well, with perzone stacks that may no longer be clear to the > admin. Perhaps the perzone stacks documentation could point > out the things that still need to be done in the global zone. The documentation will state what dladm setup (aggregations, VLANs, and future things) will be done in the global zone. Perhaps in the future we can relax some dladm operations, but today I don't think we have explored how this can be done. Erik From sacadmin Tue Aug 1 08:13:08 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k71FD8Pc016485 for ; Tue, 1 Aug 2006 08:13:08 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k71FEbUQ003235; Tue, 1 Aug 2006 11:14:37 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.7+Sun/8.13.7/Submit) id k71FEbLk003232; Tue, 1 Aug 2006 11:14:37 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17615.28637.279217.339027@gargle.gargle.HOWL> Date: Tue, 1 Aug 2006 11:14:37 -0400 From: James Carlson To: Erik Nordmark Cc: Gary Winiger , psarc@sac.sfbay.sun.com, crossbow-core@sun.com Subject: Re: Initial response to issues (PSARC 2006/366) In-Reply-To: Erik Nordmark's message of 1 August 2006 07:37:31 References: <200607261925.k6QJPn1w005754@marduk.eng.sun.com> <44CF672B.7070402@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 925 Erik Nordmark writes: > >> gw-4 nit: Evolving and Stable in the interface table. > > >> For the exported interfaces I want them to "be the same as those exports in > >> PSARC XXX/YYY", but without a N-1 mapping from old to new I can't > >> express that. > > > > That's my perspective. > > I don't understand what you say is your perspective. > Can you clarify how I can express "same as in the original Zones PSARC > case" for the exported interfaces that I am adding? Just map {Evolving,Stable,Standard}->Committed and Unstable-> Uncommitted, and all should be fine. (The only bit of wobble there is in Evolving, and then only in the way that ARCs other than PSARC had occasionally used it.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Aug 1 08:14:20 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k71FEKkd016803 for ; Tue, 1 Aug 2006 08:14:20 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.7+Sun/8.13.6) with ESMTP id k71FEFCK816674 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Aug 2006 08:14:18 -0700 (PDT) Message-ID: <44CF6FC6.9010500@sun.com> Date: Tue, 01 Aug 2006 08:14:14 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: James Carlson CC: psarc , crossbow-core@sun.com Subject: Re: Initial response to issues (PSARC 2006/366) References: <44C7A0A4.3090007@sun.com> <17607.46852.179377.16358@gargle.gargle.HOWL> In-Reply-To: <17607.46852.179377.16358@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 11107 James Carlson wrote: > The one option that's left out of here (and the one that I _thought_ > would have been the most obvious solution for stack instances, and the > first option I would have suggested) would be: > > If you declare a zone to have a stack instance, then you cannot > configure any of the IP parameters within zonecfg. It's illegal to > specify any "add net" sections for a non-global zone that has an > exclusive stack. > > Instead, you must delegate DLPI nodes (whole network devices or > VLANs) to the non-global zone. The configuration of IP within the > zone takes place with the same interfaces as would be used in a > regular global zone. [Just to make sure the email record reflects what we talked about in the meeting.] The project team will explore the above approach (which includes making sysid-net work as expected in an exclusive-stack zone). In zonecfg it probably still makes sense to allow add net physical=bge1 (and that is it) instead of using add device This is because future Clearview projects will introduce a /dev/net/ directory in addition to /dev/, and we don't want the user to have to know whether a particular link name lives in /dev/net/ or not. >> That middle ground has been requested by some, but the customers I've >> talked to >> don't see a need for this. (When they are consolidating applications from >> multiple servers, they already have some approach to how they handle root >> access on the individual servers - e.g. the "application admin" might >> have the root, or might not.) When consolidating those applications they >> can just continue using the same model (e.g., whether or not the application >> admin has the root password for "its" non-global zone.) > > It sounds to me like using the same mechanism (whatever that might be > -- RBAC?) for both whole separate systems and these new stack-instance > zones would be best. Having different mechanisms to enforce security > in different contexts is probably not a safe thing for customers to > do. The thing the project team needs to do is better understand whether there are benefits in being able to apply restrictions on the IP addresses a non-global zone can assign, even though we can't prevent a privileged process in that zone from sending arbitrary, including ARP, packets using DLPI access to their NICs. Hopefully we don't need this feature; I agree it is hard to conceptually describe how it relates to "normal Solaris". > That said, 'restrict' is still puzzling to me. It seems to imply that > we somehow plumb an interface out in the global zone (it's the global > zone that has the privilege to change addresses when 'restrict' is in > effect, right?) but that the interface itself is inside the non-global > zone. > > Or perhaps it means that we're restrictive only sometimes -- processes > in the non-global zone can sometimes set up addresses but other times > cannot. Processes in the global zone never issue SIOCS* ioctls for interfaces that have been assigned to an exclusive-stack zone. The ioctls are done by ifconfig in the non-global zone, but the kernel checks "should this zone be allowed to set this IP address on this network interface?". > Or maybe it actually sets up a filter of sorts in the kernel: "zone X > may at its discretion configure the following addresses, on these > given interfaces, but no other." If so, should this feature play into > regular Solaris in any way? Is this perhaps a more general feature? Yes, in essence it is a "filter" but applied to the SIOCSLIFADDR and SIOC*ARP ioctls. > As this project rightly asserts, many of our current problems stem > from past assertions that Zones would virtualize networking. Zones > only partly does so, and thus works for some usages but not others. > It seems to me that it would be harmful to tell customers that, unlike > those past bad marketing messages and limited implementation, we've > "really" virtualized networking this time around -- only to allow them > to discover later that this is _NOT_ true, and that many things still > remain unvirtualized and unavailable to non-global zones. Agreed. The message should instead be of the form that now we can ensure isolation when different zones are connected to different (V)LANs, including the different zones having separate routing, etc. >> I don't understand what type of /etc/system hacks you want us to consider. >> Do you have an example? > > I'm thinking of things like this: > > http://docs.sun.com/source/819-0084-10/pt_tuningos.html#wp61914 > > I suspect there are quite a few others like this. I'm not asking for > an exhaustive search, but rather a quick check to make sure that there > won't be any obvious escalations shortly after customers start trying > to use stack instances. We definitely need to document the constrains in this space. The /etc/system settings for networking related things, as for zones in general, can only be applied globally by the global zone. Same thing for the ndd settings relating to squeues, but hopefully there will be less of those as Crossbow makes progress. The tcp/ip/udp/arp ndd setting can be done separately for each exclusive stack zone. >> /etc/system and driver.conf settings for network device drivers is something >> we want to move away from, and the things like the dladm properties (which >> can be extended to allow configuring jumbo-frames) are definitely the right >> way to go. > > Sure. But prior to stack instances, there wasn't any notion of a > non-global zone somehow "owning" an interface. That ownership changes > things -- the owner of an interface should be able to configure it as > well. I think other virtualization techniques like Xen and LDOMs introduce restrictions on what it means to "own" a NIC as a result of actually sharing a single NIC underneath the virtual device drivers; perhaps that hasn't been discussed in the ARCs. As I understand Xen the normal operation is that dom0 sets the MAC address and the domU can't change it. And any operation that affects the PHY (e.g., half/full duplex, speed, inter-packet gap) isn't meaningful to set by N different parties that each own a virtual Ethernet driver sharing the same physical layer hardware. I don't know what those techologies propose as a solution should the local admin try to change something which is shared, but the point is that one of the benefits of virtualization is to be able to share the same Ethernet cable, hence there is a single PHY. > Until those things change, tuning those sorts of things can't be done > as expected. Yes, but virtualization might imply a change in the expectations. It the future there might be the model that is a domU (or an exclusive stack zone) is the only user of e.g., bge3, then it can control the PHY. But for VLANs or other forms of shared NICs that wouldn't be an option. >> jdc-9 Section 5 of the design says that non-global Zone users cannot >> add their own kernel modules for things such as Checkpoint, >> the Cisco VPN, or just a private build of ipf. >> >> How do we document that these independent stacks are not >> always independent? >> >> We already make it clear that with zones there is a single kernel. >> Thus clueful customers will infer that untrusted parties can't load random >> kernel modules into the single kernel. > > I think that misses the point of my question. > > By the same argument, clueful customers should never have been > confused that the existing Zones model would have provided a > completely separate networking model. After all, there's only one > TCP/IP stack and the global zone owns and controls all of the network > interfaces and routes, so how could it be otherwise? I suspect the confusion comes from Sun stating that Zones is all about isolation, and then saying that we provide network isolation by giving each zone a separate IP address. The fact that we didn't explicitly say "but when you have multiple LANs or VLANs, they are all connected together at the IP layer", means that it was quite easy for customer's to read "isolation" and make assumptions about what should happen when connecting a server with zones to isolated networks. > I'm concerned about how we make it clear that, like the original Zones > project, stack instances isn't a panacea either. We should not make > this mistake twice. It's an improvement on Zones, but it does *not* > provide the completely isolated networking environment that some might > hope that it does. It's explicitly *not* the same as having a > separate system. I think it is pretty easy to explicitly state what things do not do. The failure in the past seems to have been too much of a "state all the good things" and don't mention any of the limitations. >> - amortize the OS maintenance cost across multiple "blobs" (Note: I don't >> have a good term that captures the general notion of separate domains or >> containers, hence I arbitrarily pick the term "blob" for this answer) > > Arguably, that's something that can and should be dealt with by > install tools (such as flash archives and even ZFS-based cloning). That doesn't address the contractual cost that some customer's have; they've outsourced OS maintenance and are paying per OS instance. > The flip side of it is that Xen allows you to schedule your > maintenance independently. With Zones, you have to arrange to tear > down all of your non-global zones at once in order to patch something, > and some things (actually, many things) cannot differ between zones > even if you use the "whole root" model, due to tangled dependencies. > > It's not a simple win. Agreed - it is all a tradeoff. >> I don't know if PSARC desires more discussion about our virtualization >> strategy; typically the ARC doesn't review the business strategy. > > I'm not asking to review any business strategy. > > We have multiple projects playing in the same logical area that are > headed through the ARC at the same time. Distinguishing them will > help immensely. > > This *IS* architecture: how the projects all fit together to give > customers a good experience and sound solutions on Solaris. Having > projects that duplicate each other in functional ways promotes > confusion, which is one of the things we try to avoid. > If the ARC isn't expected to look at the functional and administrative > overlaps between various large projects, perhaps you could suggest > some other body at Sun that is in fact reviewing these things. Would > that be Solaris PAC? I don't have a problem with the functional and administrative model being discussed. But your question was jdc-11 What are the advantages of stack instances over Xen? which too me is asking for the business reasons for doing Zones and stack instances in particular, given that we are also doing Xen. Understanding and comparing the functional and admin models is important, and also to drive for common admin concepts where it is in fact the same thing that is being described. Erik From sacadmin Tue Aug 1 08:22:52 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.144]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k71FMqC2017930 for ; Tue, 1 Aug 2006 08:22:52 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.7+Sun/8.13.6) with ESMTP id k71FMlMg820972 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Aug 2006 08:22:50 -0700 (PDT) Message-ID: <44CF71C6.4020701@sun.com> Date: Tue, 01 Aug 2006 08:22:46 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: James Carlson CC: Gary Winiger , psarc@sac.sfbay.sun.com, crossbow-core@sun.com Subject: Re: Initial response to issues (PSARC 2006/366) References: <200607261925.k6QJPn1w005754@marduk.eng.sun.com> <44CF672B.7070402@sun.com> <17615.28637.279217.339027@gargle.gargle.HOWL> In-Reply-To: <17615.28637.279217.339027@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 278 James Carlson wrote: >> Can you clarify how I can express "same as in the original Zones PSARC >> case" for the exported interfaces that I am adding? > > Just map {Evolving,Stable,Standard}->Committed and Unstable-> > Uncommitted, and all should be fine. Thanks. Erik From sacadmin Tue Aug 1 08:32:47 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k71FWl0Z019300 for ; Tue, 1 Aug 2006 08:32:47 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k71FWkh3015216; Tue, 1 Aug 2006 08:32:46 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k71FXYbJ014461; Tue, 1 Aug 2006 08:33:34 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k71FXYH5014460; Tue, 1 Aug 2006 08:33:34 -0700 (PDT) Date: Tue, 1 Aug 2006 08:33:34 -0700 (PDT) From: Gary Winiger Message-Id: <200608011533.k71FXYH5014460@marduk.eng.sun.com> To: gww@eng.sun.com, erik.nordmark@sun.com Subject: Re: Initial response to issues (PSARC 2006/366) Cc: psarc@sac.sfbay.sun.com, crossbow-core@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 442 > Who do I contact at the UIRB? from http://sac.eng/rb/UIRB perhaps uirb@sun.com or devjani.ray@sun.com I wasn't suggesting anything like a new review of zoneadm, just some suggestions/help for the stacktype keyword. > >> gw-4 nit: Evolving and Stable in the interface table. > Can you clarify how I can express "same as in the original Zones PSARC > case" for the exported interfaces that I am adding? Jim already replied. Gary.. From sacadmin Wed Aug 2 09:22:50 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k72GMolr004901 for ; Wed, 2 Aug 2006 09:22:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k72GMnB14314; Wed, 2 Aug 2006 10:22:49 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J3D00307PI0I200@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Aug 2006 09:22:48 -0700 (PDT) Received: from nwkea-pix-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J3D002RXPHXJDD0@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Aug 2006 09:22:45 -0700 (PDT) Received: from d1-sfbay-03.sun.com ([192.18.39.113]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k72GMj8d010033; Wed, 02 Aug 2006 09:22:45 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-03.sun.com by d1-sfbay-03.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J3D00101PAX1Q00@d1-sfbay-03.sun.com> (original mail from Sherri.Shieh@Sun.COM); Wed, 02 Aug 2006 09:22:45 -0700 (PDT) Received: from [129.146.11.231] by d1-sfbay-03.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J3D00EX7PHWMQ50@d1-sfbay-03.sun.com>; Wed, 02 Aug 2006 09:22:45 -0700 (PDT) Date: Wed, 02 Aug 2006 09:22:44 -0700 From: Sherri Shieh Subject: PSARC Meeting Minutes 07/26/2006 Inception: 2006/366; Commitment: 2006/143 Sender: Sherri.Shieh@Sun.COM To: psarc@Sun.COM, Erik Nordmark , Frank Che , Ienup Sung , Shudong Zhou , Alan Perry Message-id: <44D0D154.7060606@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_4k9irFbybtIRrmMlKEIjqQ)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 27989 This is a multi-part message in MIME format. --Boundary_(ID_4k9irFbybtIRrmMlKEIjqQ) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT All, PSARC meeting minutes are now available and are attached. Audio files are available as well: (1) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060726.arcbiz.mp3 (2) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060726.2006.366.inception.mp3 (3) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060726.2006.143.commitment.mp3 Sum up available at: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060726.html If you ahve any corrections/feedback, please direct them to me. Thanks, Sherri -- ========================================================= Sherri Shieh Sun Microsystems, Inc. Program Manager Email: sherri.shieh@sun.com Systems Architecture Phone: 650-786-5245/x85245 =========================================================== --Boundary_(ID_4k9irFbybtIRrmMlKEIjqQ) Content-type: text/plain; name=20060726 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=20060726 SYSTEM ARCHITECTURE COUNCIL Platform Software ARC --------------------------------- PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 07/26/2006 MEETING MINUTES ============================================================== CORRECTIONS, additions, deletions to sherri.shieh@sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. ATTENDEES - Members: Joseph Kowalski: no (on sabbatical) Glenn Skinner: yes Robert Berube no James Carlson: yes Bill Sommerfeld: yes Gary Winiger: yes Tim Marsland: no (on sabbatical) Ed Gould: no (out) David Robinson no (on sabbatical) Kais Belgaied: yes Sherri Shieh: yes ATTENDEES - Interns: Don Cragun: yes Peter Dennis: no (on sabbatical) Wyllys Ingersoll: no Rick Matthews: yes Alec Muffett: no (on sabbatical) James Falkner: no (on sabbatical) Phil Harman: no Calum Mackay no Michael Speer no Ienup Sung no Cecilia Hu: no Brian Utterback no Michael Haines no Sebastien Roy no Alan Hargreaves yes Darren Reed no Guests: Ienup Sung Nils N. Alan Perry Nitin Hande Nicolas Erik Nordmark Frank Che Shudong Zhou --------------------------------------------------------------------------- AGENDA ------- 07/26/2006 (monthly late mtg - will start at 4pm PST; EdG out, Glenn out after first case) ROOM CHANGE FOR THIS DATE ONLY: Telegraph Hill, MPK17, Rm. 3445/Flr. 3 4:00-4:10 project id 4:10-4:20 ARC Business 4:20-5:05 Inception: Stack instances: Exclusive IP stack per zone (2006/366) Submitter: Erik Nordmark Owner: Kais Belgaied Intern: Rick Matthews 5:05-5:50 Commitment: HCTS 3.0 (2006/143) Submitter: Frank Che Owner: Shudong Zhou --------------------------------------------------------------------------- ARC Business ============ Fast tracks ----------- 2006/389 SDP (Sockets Direct Protocol) Amendment Nitin Hande waiting fast-track 07/28/2006 Kais Belgaied * Gary will take this up at ARC chairs tomorrow * let it run 2006/410 ATA Update FW support Ying Tian waiting fast-track 07/26/2006 Alan Perry * re-opened to pick up SPARC * Approved 2006/412 ipmievd Cathy Thomas waiting fast-track 07/28/2006 Alan Perry * P team make it some form of stability * Approved pedning comments being posted 2006/435 Automount KARCH and PLATFORM variables Rainer Orth waiting fast-track 07/21/2006 Darren Moffat * Approved last week 2006/438 Sun Cluster TCP/IP STREAMS contract James Carlson waiting fast-track 07/27/2006 James Carlson * Approved 2006/445 Generic 32-bit/64-bit symbolic links for Craig Mohrman waiting fast-track 07/27/2006 Donald Cragun * Approved 2006/447 LWP support for prun(1) and pstop(1) Vitezslav Batrla waiting fast-track 07/28/2006 Adam Leventhal * Approved 2006/448 UTF8_STRING support in Solaris libX11 an Federic Zhang, Gavin waiting fast-track 07/28/2006 Ienup Sung * Approved 2006/450 du option merge Cynthia Eastham waiting fast-track 08/01/2006 Bill Sommerfeld * Approved 2006/451 System V resource controls for Zones Steve Lawrence waiting fast-track 08/02/2006 Daniel Price * let it run Other Business -------------- * voting on The full BrandZ case: 2005/471 (2006/440 was approved fast track) yes - Glenn, Gary, Jim, Bill, Ed (proxy) no - NP - Kais - Case was approved during ARC business. Issues to Escalate ------------------ Gary will escalate these issues tomorrow at ARC chairs. * SAC isn't still pushing out the updated policies out to everybody. * Policy incoherent ============================================================================ Inception: Stack instances: Exclusive IP stack per zone (2006/366) Submitter: Erik Nordmark Owner: Kais Belgaied Intern: Rick Matthews SUMMARY ======= * Advice: SYSID and zones should cooperate and should be documented ISSUES ====== jdc-1 Why is the interface address configuration done from zonecfg? This means that an exclusive stack owner can't control his own network interface properties, except after the fact, and possibly at odds with the global zone administrator. Answer: It follows the existing zones model of configuring IP addresses from zonecfg. It is important to minimize the differences between configuring a shared-stack zone and an exclusive-stack zone. This means that an exclusive stack owner can't control his own network interface properties, except after the fact, and possibly at odds with the global zone administrator. The non-global admin can control its own network configuration. But see section 12 in si-interfaces.pdf on the choices of creating/updating the /etc/ network files on zone install vs. zone boot. Note that the current approach in this case doesn't prevent other projects to change the zone's model for network configuration to allow use of the normal sysid mechanism for configuring network parameters. (Why not control other aspects of network configuration, such as which routing daemons to run, from zonecfg as well? What's the administrative model that requires only addresses and static default routes, especially given "route -p"?) Answer: The above seems like issues with the original zones case and not this case. One could likewise have argued that PSARC 2002/174 should have allowed specifying other or all aspects of network configuration (such as nsswitch.conf, resolv.conf, etc) in zonecfg, but it did not. * Would you use zone config to configure things which you don't want to have control over? * IPconfig jdc-2 How exactly do interface bring-up and route configuration work? Does zoneadmd enter the zone to do these things -- if so, how is that coordinated with IP Filter configuration? If not, then how do the zonecfg-configured values end up in the non-global zone where the normal boot process can use them? Answer: See section 12 in si-interfaces.pdf If we are going to update the files on each zone boot, then we will use the design pattern that Zulu uses (fork + zone_enter to create the file). If we are only going to create the files when the zone is installed, we'll just have zoneadm install create them while running in the global zone. How does dhcpagent inside the non-global zone find out that zonecfg in the global zone has told it to run on some interface? Answer: The normal mechanism that is used in the global zone in S10 - the existence of /etc/dhc.. Section 5 of the design says the opposite of this -- it says that the existing /etc files are used in the non-global zone for configuration. And section 12 provides options, but doesn't seem to recommend a particular solution. Answer: Where do you see an inconsistency in the materials? AFAIK the materials are self-consistent on this issue. And section 12 provides options, but doesn't seem to recommend a particular solution. We are actively seeking the feedback from the ARC on that issue, which is why it is explicitly flagged. Sorry if this wasn't clear. jdc-3 What can 'restrict' really do? Why can't a non-global zone steal an address from another machine? Why can't a malicious user just run ifconfig _after_ the zone boots and the restriction is gone? Why is the flag needed? Answer: See section 9 in si-interfaces.pdf. The implementation of the enforcement is done in the kernel, so that the various ioctls that set/change an IP address or make ARP publish an entry, check against the restriction. Thus the non-global admin can invoke ifconfig to try to change its IP address or do an 'addif', but the ioctl will fail with EPERM. The need for this is to allow a middle ground between the current shared-stack model (where the non-global zone doesn't have the privileges to do any of this) and an exclusive stack with unrestricted ability to do things on the network. That middle ground has been requested by some, but the customers I've talked to don't see a need for this. (When they are consolidating applications from multiple servers, they already have some approach to how they handle root access on the individual servers - e.g. the "application admin" might have the root, or might not.) When consolidating those applications they can just continue using the same model (e.g., whether or not the application admin has the root password for "its" non-global zone.) Couldn't a really malicious user just open a raw driver and start transmitting gratuitous ARP messages for someone else's address? Answer: That is correct. The 'restrict=true' prevents against accidental misconfiguration but not against root in the zone running its own DLPI application which sends bogus ARP packets. You get the same type of protection with a exclusive-stack zone with 'restrict=true' as you get with in S10 when a zone has been given access to snooping on a NIC (e.g., by adding device access to /dev/bge1 in zonecfg). As an aside, we have an opportunity to differentiate ourselves in this space in the future. I think the right long-term direction, which applies to Xen/LDOMs/zones, is to introduce IP Filter hooks in the GLD layer and make it easy to create filter expressions for ARP and Neighbor Discovery packets. That would allow us to have the machine administrator enforce network security independent of the domU or zone that uses a NIC to access the network. jdc-4 20q8 says that link aggregation is supported in non-global zones, but section 5 of the design says that it can't be supported. Which is true? Answer: Good catch. 20q8 is incorrect. An aggregate has to be configured in the global zone. (It is probably possible to relax this in the future, but the details depend on how one could handle the Clearview vanity names creating entries in /dev/net.) jdc-5 KSSL identifies particular user applications based on configuration. How is this virtualized so that one zone cannot affect another? Answer: See section 5 in si-interfaces.pdf. The virtualization of kernel network components above the transport layer (NFS, KSSL, NL7C, etc) are out of scope. Furthermore, if/when they are virtualized they should be make "zone aware" and not "stack instance aware" since at that layer there are no direct function calls into IP. jdc-6 Can exclusive stack instances communicate with each other? Does doing so require external hardware or something delivered from Crossbow? Answer: The purpose of this project is isolation and not communication, because that is where the pressing customer need exists. Thus communication between separate stack instances will be done via external devices (Ethernet switches, routers, firewalls, load balancers, etc). In the future we expect that the Crossbow project will provide GLDv3 devices that will additionally allow for cases when strict isolation isn't necessary, e.g. when separate stacks want to be able to communicate inside the server. jdc-7 Can exclusive stack instances run NFS servers? If not, are there other "normal" Solaris networking features that are prohibited as well, and how does the user find out? Answer: See answer to jdc-5. Presumably the user finds this out the same way s/he finds out that one can't run an NFS server in a non-global zone in S10. jdc-8 What about ndd hacks, such as ip_squeue_enter or the really awful 'hme instance' value? Are those independent in these zones? (I don't see how the latter could be -- if I delegate hme0 to zone A and hme1 to zone B, I don't want zone A doing "ndd -set /dev/hme instance 1," but I don't see how I can stop it.) Answer: ip_squeue_enter and the like will require PRIV_SYS_NET_CONFIG hence will only be allowed in the global zone. (The squeues are effectively a scheduling concept whose number is based on the number of CPUs, hence having more of them when there are more zones doesn't make sense.) 'hme instance' doesn't exist. I think it does exist for 'ce'. Since 'ce' is DLPI style 2 it can not be assigned to an exclusive stack it its current form (there are no /dev/ce devices). Should 'ce' be made into DLPI style 1 in the future (either explicitly, or by Clearview Nemo Unification) we need to address this. That can easily be handled e.g. by requiring PRIV_SYS_NET_CONFIG for ND_SET ioctls in GLD or in softmac. What are the device security issues exposed? Answer: Not any different than when e.g., /dev/bge1 is explicitly given to a zone so it can snoop. It is extremely unlikely that any DLPI style 1 device has a ndd hack like the 'ce' 'instance'. And many driver check for PRIV_SYS_NET_CONFIG for operations that change settings (even though they only apply to the instance that is open.) There is always the possibility that a device driver has bugs. In some cases IP/ARP might not trigger those bugs but a malicious application using DLPI might be able to trigger them. I expect we will handle such bugs using our normal quality processes. (Not an ARC issue, but you may want to check if there are any well-known /etc/system hacks that'll be unsupportable here. We've already had quite a few questions about kernel tuning within non-global zones.) Answer: I don't understand what type of /etc/system hacks you want us to consider. Do you have an example? /etc/system and driver.conf settings for network device drivers is something we want to move away from, and the things like the dladm properties (which can be extended to allow configuring jumbo-frames) are definitely the right way to go. jdc-9 Section 5 of the design says that non-global Zone users cannot add their own kernel modules for things such as Checkpoint, the Cisco VPN, or just a private build of ipf. How do we document that these independent stacks are not always independent? Answer: We already make it clear that with zones there is a single kernel. Thus clueful customers will infer that untrusted parties can't load random kernel modules into the single kernel. We will also make it clear that "stack instances" applies to the TCP/IP layer of the stack (layer 3 and 4 in the ISO reference model) and explain the distinct separation between this and the datalink (layer 2), with the datalink being managed by dladm etc. jdc-10 Would like DR details (particularly which administrator does what, and how the global and non-global zones coordinate) for commitment. Answer: We will provide an example of how this can be coordinated. jdc-11 What are the advantages of stack instances over Xen? (If we plan to ship Xen anyway, what things can Xen _not_ do, and does it make more sense to extend Zones than to enhance Xen?) Answer: It is clear that virtualization is something that will span our product line, with virtualization components and solutions from the hardware (e.g., virtualizable NICs) all the way up to the applications. There are tradeoffs in what layer the virtualization is applied, and in some cases it might make sense to combine them. For instance, using Xen as a way to get live migration, but then inside a Xen domU run multiple zones that share the resources. Examples of what Xen can not do that Zones can do (and stack instances doesn't change this) are - amortize the OS maintenance cost across multiple "blobs" (Note: I don't have a good term that captures the general notion of separate domains or containers, hence I arbitrarily pick the term "blob" for this answer) - share VM pages for the same read-only pages across "blobs" (e.g., a single copy of libc text) - very efficiently do fine grain and statistical sharing of machine resources such as CPU and memory. Hardware virtualization schemes end up with a two-layer approach to resource management, where the hypervisor does one layer of it and then the OS has its own management above. For instance, the hypervisor "scheduler" might not be aware that the OS is running in the idle loop. When we care about soft realtime this becomes even more apparent. - hardware independence; same approach works on sun4u, sun4v, x64. I don't know if PSARC desires more discussion about our virtualization strategy; typically the ARC doesn't review the business strategy. jdc-12 nit:Where do the moduleid values come from? (Why doesn't netstack_register just return an opaque pointer?) What does a module_create implementation do with a 'netstack_t' pointer? Answer: The moduleids are defined in netstack.h. This flexibility is sufficient. See section 13 in si-interfaces.pdf. The design (don't think this is architecture) needs to provide efficient ways get from e.g., a tcp_stack_t to an ip_stack_t when tcp is going to do an IRE lookup, and the fixed definition allows for this. The module_create functions record the netstack_t pointer in their per-stack data structure (e.g., tcp_stack_t). That way the tcp can get to the ip_stack_t by following the pointers: tcps->tcp_netstack->netstack_ip. jdc-13 nit:Could the kstat and other interfaces avoid having a netstackid_t value? It seems like merely having an "instance-per-stack" flag should be enough, since the user shouldn't be creating kstats for zones other than his own. Answer: It isn't the user that is causing the kstats to be created but the initialization of the zone. This hangs of the zsd callbacks in the zones framework, and that is driven from the zone_create() system call. The zone_create() system call is called from the global zone, hence it is not possible to use an implicit way to determine the zoneid or netstackid; it needs to be explicitly passed as an argument. gcs-1 Is there any need for other sharing configurations, say zones A and B sharing a stack, with that stack independent of the global zone's stack? What would have to change in your design to allow such additional flexibility? Answer: We haven't identified such a need even though the theoretical possibility has been discussed. For instance, in addition to the above case, what would happen if zones were hierarchical so that a non-global zone could create sub-zones, or having a separate stack per projectid? Even though there is no forseen need to handle this generality, the design of the netstack framework has taken the possibility into account, by providing routines that hide as much as possible the relationship between zoneids and netstackids, and hide the relationship between the thread that calls xx_open() and the netstack it uses. Thus if we need to support some other model in the future, the bulk of the changes would be in the configuration layer. Assuming we still use zonecfg to configure things at that possible future date, zonecfg would potentially need different configuration options. gw-1 nit: Perhaps UIRB should be consulted to see if there is a more admin friendly way to represent "stacktype=exclusive | shared" Answer: I recall seeing some email that UIRB doesn't review CLIs. What is the current state? gw-2 Please check with the TX project team (Jarrett Lu) for any overlaps. Answer: Will do. gw-3 Presumably SDP or IB is not covered in a per-zone way by this project. Answer: Correct. gw-4 nit: Evolving and Stable in the interface table. Answer: Maybe more than a nit. Is there a transition plan for move from the old to the new taxonomy? As I understand it, there isn't a 1-1 mapping (or N-1 mapping) from old to new. For the imported interfaces, clearly(?) I must re-state what was actually used by the case that introduced those interfaces. For the exported interfaces I want them to "be the same as those exports in PSARC XXX/YYY", but without a N-1 mapping from old to new I can't express that. gw-5 4. Goals -- IPsec includes IKE right :-) Answer: Correct. gw-6 5. Non-Goals -- How will the admin know that aggregation needs to be done in the global zone for exclusive stacks? Answer: Same way that the global admin in S10 knows to apply aggregation or IPMP or something else for the non-global zones. Is there a need for per-zone network resource limits? Answer: What limits did you have in mind? Bandwidth? The Crossbow project is working on bandwidth limits, that can be tied to zones, Xen instances, etc. gw-7 nit: 6.3 s/global/exclusive/ wes-1 During last week's security strategy meeting, Whit Diffie asked us to take a closer look at cryptographic boundary issues. One aspect of this for IPsec is separation between cleartext and ciphertext packets (see RFC4301 section 3.1). Unfortunately, our IPsec implementation currently doesn't have a very well defined boundary. What does this have to do with this project? Well, when building a security gateway, it would be extremely helpful to be able to put the/a IPsec protection boundary between two stack instances. It would also resolve a few practical/operational problems relating to managing the routing table on our punchin gateways, collapsing it to a single default route on each side of the protection boundary. How can we stretch this architecture to permit this? (something more flexible than a 1:1 mapping between stack instances and zones might help) wes-2 (specific instance of gcs-1) there may be some assurance benefits from pairing zones (two zones sharing a stack instance; zone A runs a key mgmt daemon, zone B runs apps; if zone B is penetrated, attacker doesn't get to observe short-term or long-term keying material. wes-3 memory usage: we know we have a weak spot regarding memory consumption by mblks/dblks "in flight" through the stack. is there any way to track and/or limit allocation by each stack instance? (the mass rototill inherent in this project might well be the right time to introduce a "stack instance" parameter to the allocator..) wes-4 observability in the face of a compromised zone: 20Q8 says that global zone administrators must zlogin to a local zone to run that zone's version of netstat or equivalent to observe what that zone is doing. What happens if the software in that zone has been hacked to conceal the very thing the global zone admin is looking for? wes-5 20Q18: you answered N/A to: "Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? " I know there a few periodic worker threads within IP (e.g., the IPsec security association expiry threads). Are they shared between stack instances or do we create one per stack instance? * Answer by commitment. wes-6 stack instances w/o delegating administration to the zone? (related to wes-2 & wes-4, gcs-1, jdc-1) a number of use cases for zones I've run into (e.g, TX, compute grid, etc.) expressly do not want to delegate administration into a non-global zone because the zone forms a security barrier around an application; on the other hand, other constraints of that environment may require per-zone routing table, etc.; how do we avoid the security vs functionality tradeoff? * This was covered already. wes-7 what's the interaction between SO_ALLZONES and stack instances? Likewise for SO_MAC_EXEMPT and its associated privilege and process flag? * This needs to be documented - talk to the TX team. NEXT STEP ========= * Project team will go back and resolve all issues from today's review. ============================================================================ Commitment: HCTS 3.0 (2006/143) Submitter: Frank Che Owner: Shudong Zhou SUMMARY ======= * Update spec - more documentation on how the disk test knows about ZFS volumes * Update spec - interface specification - complete it (list major components); adding libs that are above internal should also be listed * Spec update: command line must use the configured interrupt character and be clearly documented (man page update) * TCA: use DHCP for automatic configuration (Kais will write this and send it to case owner/intern) ISSUES ====== jdc-13 Does the disk test know about ZFS volumes? (Is it the disk that's formatted or just the Solaris disk slice? Does the documentation mean "slice" when it talks about disks? How does a whole disk have a mount point?) Don't destroy the system. jdc-14 What does the "getting started guide" mean when it says that you "might need to do some additional aministration to completely restore system and network configuration settings after HCTS testing?" What additional things? (If you can't uninstall, wouldn't it be smarter to use LU or just reinstall from scratch? And if I do that, why bother with an uninstall script?) Update the doc to clarify the procedure. jdc-15 PAC advice: funding alignment between HCTS, SunVTS, and System Test will reduce duplication and lower costs. jdc-16 Advice: having HCL entries for controllers would be _very_ useful. Opinion: need HCL for audio, video controllers, etc. jdc-17 Team advice: in future cases, I'd like to see more information about how the test coverage supports the certification goal. Opinion jdc-18 Interface specification still incomplete; missing major components such as /opt/SUNWhcts/lib contents. Please work with your case owner. Spec. update: major components Things that may become public in the future KB-1 Functional_Specification.pdf, 2.2.3 Automated Network Configuration The described assignment of IP addresses to the SUT looks very similar to DHCP. Any reason for not using DHCP ? TCA: use dhcp for automation On whiteboard -------------- dwc-1 HCTSCLI Certify system Is it really appropriate to destroy production disks without positive comfirmation? * May be related to jdc-13. * In existance, there should be no production disks. dwc-2 HCTSCLI: Does this command really read CTL-C or STTY Interrupt CTL-C? * Note in the man page that there is an interrupt character * Update the doc to indicate what needs to be done. * stop certification, interrupt process VOTE ==== yes - kais, jim, bill, gary, shudong no - abstain - NP - NEXT STEP ========= * Case was approved during commitment * waiting need opinion --Boundary_(ID_4k9irFbybtIRrmMlKEIjqQ)-- From sacadmin Wed Aug 2 11:42:58 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k72Igv8I010526 for ; Wed, 2 Aug 2006 11:42:57 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.7+Sun/8.13.6) with ESMTP id k72IgsAR503708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 2 Aug 2006 11:42:56 -0700 (PDT) Message-ID: <44D0F22D.9000204@sun.com> Date: Wed, 02 Aug 2006 11:42:53 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Bill Sommerfeld CC: psarc Subject: PSARC 2006/366 stack instances Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 5134 [We didn't go into this during the inception review and I figured it might help to explore this a bit more.] wes-1 During last week's security strategy meeting, Whit Diffie asked us to take a closer look at cryptographic boundary issues. One aspect of this for IPsec is separation between cleartext and ciphertext packets (see RFC4301 section 3.1). Unfortunately, our IPsec implementation currently doesn't have a very well defined boundary. What does this have to do with this project? Well, when building a security gateway, it would be extremely helpful to be able to put the/a IPsec protection boundary between two stack instances. It would also resolve a few practical/operational problems relating to managing the routing table on our punchin gateways, collapsing it to a single default route on each side of the protection boundary. How can we stretch this architecture to permit this? (something more flexible than a 1:1 mapping between stack instances and zones might help) I think with Seb's GLDv3 tun module combined with stack instances we can be very close to do this separation, at least in principle. Basically the /dev/net/ip.tun7 is created by one zone (would have to be the global zone today), and then exported to another zone using zonecfg. "In principle", because we don't have a mechanism to have /dev/net/ip.tun* appear in a zone as they are configured - the zone would have to be rebooted. But would something like that do what you'd want? wes-2 (specific instance of gcs-1) there may be some assurance benefits from pairing zones (two zones sharing a stack instance; zone A runs a key mgmt daemon, zone B runs apps; if zone B is penetrated, attacker doesn't get to observe short-term or long-term keying material. The architecture definitely allows that type of evolution. What hasn't been looked at is how one would configure such a creation, and also if there would be any specific requirements on port number usage. One would need another piece - the ability for two or more zones to share the same IP address(es) and just "fight" over the port number space. I've prototyped that for some other discussions I had with Tim Marsland. The stack instance code, where ip_open() etc calls netstack_get_current() instead of getzoneid() made such a construct easier. wes-3 memory usage: we know we have a weak spot regarding memory consumption by mblks/dblks "in flight" through the stack. is there any way to track and/or limit allocation by each stack instance? (the mass rototill inherent in this project might well be the right time to introduce a "stack instance" parameter to the allocator..) This project doesn't attempt to solve that problem. And it doesn't rototill much at all - it mostly just applies changes of the form. From if (ip_forwarding == 1) to if (ipst->ips_ip_forwarding == 1) If one wishes to have accounting and resource controls for kernel memory, it isn't clear to me - whether the memory for network packets is more important to control than other kernel memory, and hence should be done first instead of worrying about the more general problem. - what granularity makes sense. For kernel memory in general the project concept or resource pool framework might provide reasonable granularity. For received network packets, the future Crossbow flow classification (classifying on what's in the packet headers) would also provide some finer granularity. Do we know what we want to restrict the granularity of memory allocation for network packets to per-IP stack? wes-4 observability in the face of a compromised zone: 20Q8 says that global zone administrators must zlogin to a local zone to run that zone's version of netstat or equivalent to observe what that zone is doing. What happens if the software in that zone has been hacked to conceal the very thing the global zone admin is looking for? I think I mentioned in the meeting that the MDB macros will tell the truth about the kernel state. Do we have data on how user handle this today with Zones? with VmWare or Xen? I'd like to understand that since for some corruption you can't look at things from outside the zone itself (e.g., in general it isn't safe for the global zone to poke around underneath the zonepath even if the zone is halted.) Do we know what types of observability hooks we need for a compromised zone? For instance, has anybody looked at things like verifying the signatures on the binaries in a non-global zone from the global zone? (So that e.g. a whole-root zone can be verified a bit when it is halted.) wes-7 what's the interaction between SO_ALLZONES and stack instances? Likewise for SO_MAC_EXEMPT and its associated privilege and process flag? * This needs to be documented - talk to the TX team. FWIW SO_ALLZONES and SO_MAC_EXCEPT are interpreted by the TCP/IP kernel modules relative to the IP stack instance in question. But we should probably prevent booting exclusive stack zones for a TX system. When is_system_labeled() is true, the zones infrastructure work a bit differently already. Erik From sacadmin Fri Aug 11 12:04:51 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7BJ4pqe020627 for ; Fri, 11 Aug 2006 12:04:51 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7BJ4nr7007262; Fri, 11 Aug 2006 15:04:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7BJ4npQ008054; Fri, 11 Aug 2006 15:04:49 -0400 (EDT) Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) From: Bill Sommerfeld To: Erik Nordmark Cc: psarc In-Reply-To: <44D0F22D.9000204@sun.com> References: <44D0F22D.9000204@sun.com> Content-Type: text/plain Date: Fri, 11 Aug 2006 15:04:49 -0400 Message-Id: <1155323089.6216.38.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3619 (I should have responded more quickly. in the interest of keeping the discussion focussed, I'm just responding to wes-1, wes-2, and wes-7 which are more tightly interrelated than the other two; I'll cover the others in a separate subthread). On Wed, 2006-08-02 at 11:42 -0700, Erik Nordmark wrote: > How can we stretch this architecture to permit this? > (something more flexible than a 1:1 mapping between stack > instances and zones might help) > > I think with Seb's GLDv3 tun module combined with stack instances we can > be very close to do this separation, at least in principle. > > Basically the /dev/net/ip.tun7 is created by one zone (would have to be > the global zone today), and then exported to another zone using zonecfg. > > "In principle", because we don't have a mechanism to have > /dev/net/ip.tun* appear in a zone as they are configured - the zone > would have to be rebooted. > > But would something like that do what you'd want? if it were sufficiently dynamic, and could be administered from once place -- consider punchind: it dynamically reconfigures both tunnel inner and outer addresses as VPN users come and go. zone reboots would be a showstopper; exactly how to map the inside and outside nets onto zones would also require some thought (since from an administrative perspective I'd rather see the global zone use the inner-facing stack instance by default). > wes-2 (specific instance of gcs-1) there may be some assurance > benefits from pairing zones (two zones sharing a stack > instance; zone A runs a key mgmt daemon, zone B runs apps; if > zone B is penetrated, attacker doesn't get to observe > short-term or long-term keying material. > > The architecture definitely allows that type of evolution. What hasn't > been looked at is how one would configure such a creation, and also if > there would be any specific requirements on port number usage. > One would need another piece - the ability for two or more zones to > share the same IP address(es) and just "fight" over the port number > space. I've prototyped that for some other discussions I had with Tim > Marsland. The stack instance code, where ip_open() etc calls > netstack_get_current() instead of getzoneid() made such a construct easier. I'd be interested in looking at that prototype. It's been clear for some time to me that we would get a lot of mileage out of a real access control model for ports rather than the current simplistic model -- in other words, well known ports would get acl's (think generically here rather than file system acls) and the rest would be either first-come, first-served, or partitioned. This would also help with least privilege: no longer would you have to grant a web server the privilege to bind any "privileged" port in order to let it run on port 80. > wes-7 what's the interaction between SO_ALLZONES and stack instances? > Likewise for SO_MAC_EXEMPT and its associated privilege and > process flag? > > * This needs to be documented - talk to the TX team. > > FWIW SO_ALLZONES and SO_MAC_EXCEPT are interpreted by the TCP/IP kernel > modules relative to the IP stack instance in question. > > But we should probably prevent booting exclusive stack zones for a TX > system. When is_system_labeled() is true, the zones infrastructure work > a bit differently already. I don't think that works -- as I understand it, the folks who seem to be place the greatest emphasis on red-black separation and who could thus benefit for separate stack instances for "inside" and "outside" are the very folks who want sensitivity labels, too.. From sacadmin Fri Aug 11 13:22:34 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7BKMYeh023881 for ; Fri, 11 Aug 2006 13:22:34 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k7BKMY67004741 for ; Fri, 11 Aug 2006 13:22:34 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7BKMTXx018870 for ; Fri, 11 Aug 2006 13:22:29 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J3U00D01OHMTV00@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 11 Aug 2006 13:22:29 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J3U001AMOLGX160@d1-sfbay-10.sun.com>; Fri, 11 Aug 2006 13:22:29 -0700 (PDT) Date: Fri, 11 Aug 2006 13:22:41 -0700 From: Ed Gould Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) In-reply-to: <1155323089.6216.38.camel@thunk> Sender: Ed.Gould@Sun.COM To: Bill Sommerfeld Cc: Erik Nordmark , psarc Message-id: <44DCE711.4010407@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_xIkAas5nOdIJxd9sufNVfA)" References: <44D0F22D.9000204@sun.com> <1155323089.6216.38.camel@thunk> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 2061 This is a multi-part message in MIME format. --Boundary_(ID_xIkAas5nOdIJxd9sufNVfA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Bill Sommerfeld wrote: > It's been clear for some time to me that we would get a lot of mileage > out of a real access control model for ports rather than the current > simplistic model -- in other words, well known ports would get acl's > (think generically here rather than file system acls) and the rest would > be either first-come, first-served, or partitioned. I've been a proponent of putting this sort of thing into the file system namespace, largely so that file system access controls (ACLs, in this case) can be used. Plan 9 did this very effectively (they had, to a first approximation, only one namespace for the entire system, and that was the file system). For example, rather than creating a socket and doing all of the bind() etc. dance, a web server would just open /net/ip/tcp/80 (or some other name - I don't care about the exact syntax or place in the namespace). We wouldn't have to populate the whole namespace of possible ports. It could make sense to pre-populate all of what are currently privileged ports so that we can hang suitable ACLs on them, and have other names created on open. There would also be a generic name to open with the semantics of "give me any free port." I think this sort of scheme could be used to do all of what Bill is suggesting. How or if this applies to the case at hand, however, is not so clear to me. -- --Ed --Boundary_(ID_xIkAas5nOdIJxd9sufNVfA) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect tel;work:650/786-4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_xIkAas5nOdIJxd9sufNVfA)-- From sacadmin Fri Aug 11 14:56:11 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7BLuAOq028654 for ; Fri, 11 Aug 2006 14:56:10 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7BLu8ou017191; Fri, 11 Aug 2006 17:56:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7BLu8xG008689; Fri, 11 Aug 2006 17:56:08 -0400 (EDT) Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) From: Bill Sommerfeld To: Ed Gould Cc: Erik Nordmark , psarc In-Reply-To: <44DCE711.4010407@sun.com> References: <44D0F22D.9000204@sun.com> <1155323089.6216.38.camel@thunk> <44DCE711.4010407@sun.com> Content-Type: text/plain Date: Fri, 11 Aug 2006 17:56:07 -0400 Message-Id: <1155333367.6216.69.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 929 On Fri, 2006-08-11 at 13:22 -0700, Ed Gould wrote: > I've been a proponent of putting this sort of thing into the file system > namespace, largely so that file system access controls (ACLs, in this > case) can be used. ... > Plan 9 did this very effectively (they had, to a > first approximation, only one namespace for the entire system, and that > was the file system). ... > I think this sort of scheme could be used to do all of what Bill is > suggesting. > > How or if this applies to the case at hand, however, is not so clear to me. Yup. There's insufficient flexibility within the existing sockets API to allow for explicit stack instance naming; the alternate universe where sockets were full-fledged filesystem object would solve the "how do you name a stack instance" problem and would allow for better decoupling between stack instances and zones. How to get there from here isn't clear. - Bill From sacadmin Sun Aug 13 15:36:22 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7DMaLgs008299 for ; Sun, 13 Aug 2006 15:36:22 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7DMaLf3006052; Sun, 13 Aug 2006 15:36:21 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k7DMbSpZ009325; Sun, 13 Aug 2006 15:37:28 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k7DMbSeG009324; Sun, 13 Aug 2006 15:37:28 -0700 (PDT) Date: Sun, 13 Aug 2006 15:37:28 -0700 (PDT) From: Gary Winiger Message-Id: <200608132237.k7DMbSeG009324@marduk.eng.sun.com> To: Ed.Gould@sun.com, sommerfeld@sun.com Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) Cc: erik.nordmark@sun.com, psarc@sac.sfbay.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 777 > > Plan 9 did this very effectively (they had, to a > > first approximation, only one namespace for the entire system, and that > > was the file system). > Yup. There's insufficient flexibility within the existing sockets API > to allow for explicit stack instance naming; the alternate universe > where sockets were full-fledged filesystem object would solve the "how > do you name a stack instance" problem and would allow for better > decoupling between stack instances and zones. I'm not sure how these comments apply to this case. As much as I dislike the complexity that a "Type Enforcement" policy brings, that is the policy we're all dancing around here. Only a subject of type webserver should be able to bind to an object of type webserver port. Gary.. From sacadmin Mon Aug 14 11:13:57 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7EIDva1025889 for ; Mon, 14 Aug 2006 11:13:57 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7EIDrJE015813; Mon, 14 Aug 2006 14:13:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7EIDr4x019955; Mon, 14 Aug 2006 14:13:53 -0400 (EDT) Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) From: Bill Sommerfeld To: Gary Winiger Cc: Ed.Gould@sun.com, erik.nordmark@sun.com, psarc@sac.sfbay.sun.com In-Reply-To: <200608132237.k7DMbSeG009324@marduk.eng.sun.com> References: <200608132237.k7DMbSeG009324@marduk.eng.sun.com> Content-Type: text/plain Date: Mon, 14 Aug 2006 14:13:53 -0400 Message-Id: <1155579233.18459.9.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 508 On Sun, 2006-08-13 at 15:37 -0700, Gary Winiger wrote: > As much as > I dislike the complexity that a "Type Enforcement" policy brings, > that is the policy we're all dancing around here. Only a subject > of type webserver should be able to bind to an object of type > webserver port. No, I don't think so -- I'm a bit vague on the precise meaning of "type enforcement"; unless it encompasses by definition all use of access control lists, I don't believe your statement is correct. - Bill From sacadmin Mon Aug 14 11:29:36 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7EITaeq026789 for ; Mon, 14 Aug 2006 11:29:36 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7EITZ6O017751; Mon, 14 Aug 2006 11:29:35 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k7EIUiVs010175; Mon, 14 Aug 2006 11:30:44 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k7EIUiaI010174; Mon, 14 Aug 2006 11:30:44 -0700 (PDT) Date: Mon, 14 Aug 2006 11:30:44 -0700 (PDT) From: Gary Winiger Message-Id: <200608141830.k7EIUiaI010174@marduk.eng.sun.com> To: gww@eng.sun.com, sommerfeld@sun.com Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) Cc: Ed.Gould@sun.com, erik.nordmark@sun.com, psarc@sac.sfbay.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1511 > On Sun, 2006-08-13 at 15:37 -0700, Gary Winiger wrote: > > As much as > > I dislike the complexity that a "Type Enforcement" policy brings, > > that is the policy we're all dancing around here. Only a subject > > of type webserver should be able to bind to an object of type > > webserver port. > > No, I don't think so -- I'm a bit vague on the precise meaning of "type > enforcement"; unless it encompasses by definition all use of access > control lists, I don't believe your statement is correct. Type enforcement is the name given to a mandatory policy made popular by NSA's SELinux. Consider a mandatory policy that associates an object type with each and every object on the system (just like a label based MAC policy would associate a label) and a subject type with each and every subject on the system (just like a label based MAC policy would associate a label and a privilege policy would associate a privilege vector). For example, the binary /usr/apache2/bin/apachectl would be given the subject type "webserver" and TCP port 80 or any other port such as 8080, ... would be given the type "webport" and there would be a rule in the Type Enforcement rule set: ``subject "webserver" object "webport" bind permitted'' And to create the set of webserver subject type and webport object types and rules would require security officer administrative action. ACLs are generally viewed as DAC mechanisms under control of the object owner and have limited operations. Gary.. From sacadmin Tue Aug 15 11:54:15 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FIsEsX023783 for ; Tue, 15 Aug 2006 11:54:14 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FIsAS1017478; Tue, 15 Aug 2006 14:54:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7FIsAFF024918; Tue, 15 Aug 2006 14:54:10 -0400 (EDT) Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) From: Bill Sommerfeld To: Gary Winiger Cc: Ed.Gould@sun.com, erik.nordmark@sun.com, psarc@sac.sfbay.sun.com In-Reply-To: <200608141830.k7EIUiaI010174@marduk.eng.sun.com> References: <200608141830.k7EIUiaI010174@marduk.eng.sun.com> Content-Type: text/plain Date: Tue, 15 Aug 2006 14:54:10 -0400 Message-Id: <1155668050.24747.9.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 995 On Mon, 2006-08-14 at 11:30 -0700, Gary Winiger wrote: > > On Sun, 2006-08-13 at 15:37 -0700, Gary Winiger wrote: > > > As much as > > > I dislike the complexity that a "Type Enforcement" policy brings, > > > that is the policy we're all dancing around here. Only a subject > > > of type webserver should be able to bind to an object of type > > > webserver port. > > > > No, I don't think so -- I'm a bit vague on the precise meaning of "type > > enforcement"; unless it encompasses by definition all use of access > > control lists, I don't believe your statement is correct. > > Type enforcement is the name given to a mandatory policy made > popular by NSA's SELinux. so that's where you misinterpreted me. I'm not talking about mandatory access control; rather, I'm thinking of discretionary access control under the owner of the "object" (in this case, the owner of the local address & port space, whether it be the global zone admin or a local zone admin). - Bill From sacadmin Tue Aug 15 21:08:40 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7G48eJv006471 for ; Tue, 15 Aug 2006 21:08:40 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7G48eZH010400; Tue, 15 Aug 2006 21:08:40 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k7G49oB0014166; Tue, 15 Aug 2006 21:09:50 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k7G49oIH014165; Tue, 15 Aug 2006 21:09:50 -0700 (PDT) Date: Tue, 15 Aug 2006 21:09:50 -0700 (PDT) From: Gary Winiger Message-Id: <200608160409.k7G49oIH014165@marduk.eng.sun.com> To: gww@eng.sun.com, sommerfeld@sun.com Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) Cc: Ed.Gould@sun.com, erik.nordmark@sun.com, psarc@sac.sfbay.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1075 > > Type enforcement is the name given to a mandatory policy made > > popular by NSA's SELinux. > > so that's where you misinterpreted me. I'm not talking about mandatory > access control; rather, I'm thinking of discretionary access control > under the owner of the "object" (in this case, the owner of the local > address & port space, whether it be the global zone admin or a local > zone admin). Perhaps not. As long as the object ownership and control access of the object falls exclusively to the administrator, it's equivalent to a mandatory policy. Now, if a normal user is allowed to set who can bind to port 80, 8080, 25, 22, ... it would be considered discretionary. My general understanding of the request is that only certain binaries be allowed to deal with certain ports, or perhaps more loosely that only certain users be allowed access to certain ports. None of which is under the normal user's discretion. But all is under the administrators discretion and manditory (that is always enforced outside the normal user's control). Gary.. From sacadmin Thu Aug 17 07:25:39 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.38]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7HEPdv8010727 for ; Thu, 17 Aug 2006 07:25:39 -0700 (PDT) Received: from [129.157.211.50] (dhcp-egnb07-211-50.France.Sun.COM [129.157.211.50]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k7HEPacE963727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Aug 2006 07:25:38 -0700 (PDT) Message-ID: <44E47C5F.3090909@sun.com> Date: Thu, 17 Aug 2006 07:25:35 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5.0.5 (X11/20060730) MIME-Version: 1.0 To: Ed Gould CC: Bill Sommerfeld , psarc Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) References: <44D0F22D.9000204@sun.com> <1155323089.6216.38.camel@thunk> <44DCE711.4010407@sun.com> In-Reply-To: <44DCE711.4010407@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 411 Ed Gould wrote: > How or if this applies to the case at hand, however, is not so clear to me. I don't think it applies at all. The current project doesn't propose any new access control model for TCP/UDP/SCTP ports. I suspect it might be confusing to use this PSARC email thread to continue to speculate how possible future projects might leverage stack instances to do new and exciting things. Erik From sacadmin Thu Aug 17 07:38:42 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7HEcfvx011810 for ; Thu, 17 Aug 2006 07:38:42 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7HEbbHn002054; Thu, 17 Aug 2006 14:37:37 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.6+Sun/8.13.6/Submit) id k7HEbbSj002053; Thu, 17 Aug 2006 10:37:37 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) From: Bill Sommerfeld To: Erik Nordmark Cc: Ed Gould , psarc In-Reply-To: <44E47C5F.3090909@sun.com> References: <44D0F22D.9000204@sun.com> <1155323089.6216.38.camel@thunk> <44DCE711.4010407@sun.com> <44E47C5F.3090909@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1155825457.1239.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.340 Date: Thu, 17 Aug 2006 10:37:37 -0400 Status: RO Content-Length: 534 On Thu, 2006-08-17 at 10:25, Erik Nordmark wrote: > I suspect it might be confusing to use this PSARC email thread to > continue to speculate how possible future projects might leverage stack > instances to do new and exciting things. Given all the other virtualization projects we're doing (specifically Xen and LDOMS), I guess I don't see the point in doing stack instances as well unless they permit "new and exciting things" not possible in a virtualized environment where each VM gets a full kernel instance. - Bill From sacadmin Thu Aug 17 07:40:34 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7HEeXsW012099 for ; Thu, 17 Aug 2006 07:40:33 -0700 (PDT) Received: from [129.157.211.50] (dhcp-egnb07-211-50.France.Sun.COM [129.157.211.50]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k7HEeVSq966861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Aug 2006 07:40:33 -0700 (PDT) Message-ID: <44E47FDE.1040508@sun.com> Date: Thu, 17 Aug 2006 07:40:30 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5.0.5 (X11/20060730) MIME-Version: 1.0 To: Bill Sommerfeld CC: psarc Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) References: <44D0F22D.9000204@sun.com> <1155323089.6216.38.camel@thunk> In-Reply-To: <1155323089.6216.38.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 4901 Bill Sommerfeld wrote: > (I should have responded more quickly. in the interest of keeping the > discussion focussed, I'm just responding to wes-1, wes-2, and wes-7 > which are more tightly interrelated than the other two; I'll cover the > others in a separate subthread). Bill, To me this looks like part of an exploration of how stack instances can later be leveraged to make a better punching or a different way to do TX, but it doesn't seem to be part of PSARC 2006/366. Is my understanding correct? For TX, stack instances will make sure that the current TX doesn't break. But discussions have been started on doing slightly better; if we choose to do that we will either add that to this project and case, or do a separate one. Other followups inline below: > On Wed, 2006-08-02 at 11:42 -0700, Erik Nordmark wrote: >> "In principle", because we don't have a mechanism to have >> /dev/net/ip.tun* appear in a zone as they are configured - the zone >> would have to be rebooted. >> >> But would something like that do what you'd want? > > if it were sufficiently dynamic, and could be administered from once > place -- consider punchind: it dynamically reconfigures both tunnel > inner and outer addresses as VPN users come and go. > > zone reboots would be a showstopper; exactly how to map the inside and > outside nets onto zones would also require some thought (since from an > administrative perspective I'd rather see the global zone use the > inner-facing stack instance by default). I haven't looked carefully at devname and whether that provides the mechanism to have devices appear dynamically inside a zone. >> wes-2 (specific instance of gcs-1) there may be some assurance >> benefits from pairing zones (two zones sharing a stack >> instance; zone A runs a key mgmt daemon, zone B runs apps; if >> zone B is penetrated, attacker doesn't get to observe >> short-term or long-term keying material. >> >> The architecture definitely allows that type of evolution. What hasn't >> been looked at is how one would configure such a creation, and also if >> there would be any specific requirements on port number usage. > >> One would need another piece - the ability for two or more zones to >> share the same IP address(es) and just "fight" over the port number >> space. I've prototyped that for some other discussions I had with Tim >> Marsland. The stack instance code, where ip_open() etc calls >> netstack_get_current() instead of getzoneid() made such a construct easier. > > I'd be interested in looking at that prototype. Once stack instances are in place, there was just some minor changes in the mapping from zoneid to stack instance that were necessary, plus the introduction of stacktype=shared-address in zonecfg. The webrev/workspace is at file:///net/nptbld-x.sfbay/disk1/nordmark/si-ext/webrev/index.html > It's been clear for some time to me that we would get a lot of mileage > out of a real access control model for ports rather than the current > simplistic model -- in other words, well known ports would get acl's > (think generically here rather than file system acls) and the rest would > be either first-come, first-served, or partitioned. > > This would also help with least privilege: no longer would you have to > grant a web server the privilege to bind any "privileged" port in order > to let it run on port 80. That together with the above prototype might be something interesting to explore. >> wes-7 what's the interaction between SO_ALLZONES and stack instances? >> Likewise for SO_MAC_EXEMPT and its associated privilege and >> process flag? >> >> * This needs to be documented - talk to the TX team. >> >> FWIW SO_ALLZONES and SO_MAC_EXCEPT are interpreted by the TCP/IP kernel >> modules relative to the IP stack instance in question. >> >> But we should probably prevent booting exclusive stack zones for a TX >> system. When is_system_labeled() is true, the zones infrastructure work >> a bit differently already. > > I don't think that works -- as I understand it, the folks who seem to be > place the greatest emphasis on red-black separation and who could thus > benefit for separate stack instances for "inside" and "outside" are the > very folks who want sensitivity labels, too.. And we also need to understand how TX will be more applicable to commercial usage; being able to tie labels to IPsec instead of only using clear-text CIPSO is something we need. But the details whether TX in an exclusive-stack zone makes sense (means that a multi-level port just applies to the remote labels - the local zone has a single label), whether or not we need a label-aware router in the global zone (with labels applied to internal vnic interfaces instead of routes) is also something we need to understand. But as I said, this project will keep TX working as it currently works. Erik From sacadmin Thu Aug 17 11:11:45 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7HIBjCZ015791 for ; Thu, 17 Aug 2006 11:11:45 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k7HIBfDS126744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Aug 2006 11:11:43 -0700 (PDT) Message-ID: <44E4B15D.7020404@sun.com> Date: Thu, 17 Aug 2006 11:11:41 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5.0.5 (X11/20060730) MIME-Version: 1.0 To: Bill Sommerfeld CC: Ed Gould , psarc Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) References: <44D0F22D.9000204@sun.com> <1155323089.6216.38.camel@thunk> <44DCE711.4010407@sun.com> <44E47C5F.3090909@sun.com> <1155825457.1239.21.camel@localhost> In-Reply-To: <1155825457.1239.21.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1487 Bill Sommerfeld wrote: > On Thu, 2006-08-17 at 10:25, Erik Nordmark wrote: >> I suspect it might be confusing to use this PSARC email thread to >> continue to speculate how possible future projects might leverage stack >> instances to do new and exciting things. > > Given all the other virtualization projects we're doing (specifically > Xen and LDOMS), I guess I don't see the point in doing stack instances > as well unless they permit "new and exciting things" not possible in a > virtualized environment where each VM gets a full kernel instance. Hopefully the discussion has shown that there are possibilities to do new and exiting things, even though there aren't any projects that are working on the details. Or do you see a need for more pie-in-the-sky speculation? Does PSARC also want to discuss OPG's investment profile for virtualization? Or what did you mean with "I don't see the point". I would assume PSARC is interested in the architectural consistency across the set of virtualization technologies, but nobody has explicitly asked that question.m FWIW one of the motivations for stack instances is better architectural consistency, ranging from blade servers that share a physical NIC and Ethernet cable, over Xen and LDOMs, to zones. With stack instances combined with the Crossbow VNICs we can more easily handle that as a range that all provide a concept of "Ethernet sharing" with each server/domain/container having its own MAC address. Erik From sacadmin Thu Aug 17 13:34:14 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7HKYDiP018095 for ; Thu, 17 Aug 2006 13:34:13 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k7HKY8Tx160786; Thu, 17 Aug 2006 13:34:13 -0700 (PDT) Message-Id: <200608172034.k7HKY8Tx160786@jurassic.eng.sun.com> Date: Thu, 17 Aug 2006 10:34:03 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) To: sommerfeld@sun.com, erik.nordmark@sun.com Cc: ed.gould@sun.com, psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ovWz1wgReuFkGLAAl++emg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1292 I'm leery of stepping into this, and I only want to do so at a 50,000 foot level... > From: Erik Nordmark ... > Hopefully the discussion has shown that there are possibilities to do > new and exiting things, even though there aren't any projects that are > working on the details. PSARC (and even its predecessors) has always questioned "shinny new mechanisms" and only approved them when consumers of such mechanisms have been adequately identified. Simple fact. Its a well defined architectual concept to deny integration of dead or useless code. (I think "shinny new mechanism" is a shannon'ism, but I'm not sure.) Now of course, the devil is in the detail of what "adequately" means. I don't think it means, "Well, we could use it for ...". However, I think "Foo is on the OPG roadmap and it will need it...", does meet the criteria. So does "its part of our approved virtualization architecture". Sure, there is no guarentee that the Foo project won't be cancelled or redesigned. That's a chance we take, in order to allow some forms of infrastructure to integrate before consumers itegrate. So, I believe the request for the identification of an well defined project that will consume this is a reasonable request. Your mileage may vary. - jek3 From sacadmin Thu Aug 17 13:49:32 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7HKnWKt018353 for ; Thu, 17 Aug 2006 13:49:32 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k7HKnOYA164141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Aug 2006 13:49:29 -0700 (PDT) Message-ID: <44E4D653.9040704@sun.com> Date: Thu, 17 Aug 2006 13:49:23 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5.0.5 (X11/20060730) MIME-Version: 1.0 To: Joseph Kowalski CC: sommerfeld@sun.com, ed.gould@sun.com, psarc@sac.sfbay.sun.com Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) References: <200608172034.k7HKY8Tx160786@jurassic.eng.sun.com> In-Reply-To: <200608172034.k7HKY8Tx160786@jurassic.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 843 Joseph Kowalski wrote: > So, I believe the request for the identification of an well defined project > that will consume this is a reasonable request. I'm confused. Are you saying that this project doesn't solve the problem specified in the interface document and one pager? That problem is to provide network separation at the IP level when zones is used *and* when the customer has separate LANs or VLANs on the network. Bill was asking for expansions on how this can be used to make IPsec and punchin in particular me more secure, as well as how it make make TX better, which is not in scope for this problem we set out to solve. That doesn't mean that I don't think stack instances can be valuable in improving those parts of the system; I'm pretty sure it will. But the details belong in a different project. Puzzled, Erik From sacadmin Thu Aug 17 14:17:36 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.38]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7HLHa0d019761 for ; Thu, 17 Aug 2006 14:17:36 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k7HLHUGT171339; Thu, 17 Aug 2006 14:17:35 -0700 (PDT) Message-Id: <200608172117.k7HLHUGT171339@jurassic.eng.sun.com> Date: Thu, 17 Aug 2006 11:17:26 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: PSARC 2006/366 stack instances (issues wes-1, wes-2, wes-7) To: Joseph.Kowalski@eng.sun.com, erik.nordmark@sun.com Cc: sommerfeld@sun.com, ed.gould@sun.com, psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /S5EyJWwK3dqsKw9aZQOtw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1896 > From: Erik Nordmark ... > Joseph Kowalski wrote: > > > So, I believe the request for the identification of an well defined project > > that will consume this is a reasonable request. > > I'm confused. Are you saying that this project doesn't solve the problem > specified in the interface document and one pager? That problem is to > provide network separation at the IP level when zones is used *and* when > the customer has separate LANs or VLANs on the network. > > Bill was asking for expansions on how this can be used to make IPsec and > punchin in particular me more secure, as well as how it make make TX > better, which is not in scope for this problem we set out to solve. > That doesn't mean that I don't think stack instances can be valuable in > improving those parts of the system; I'm pretty sure it will. But the > details belong in a different project. > > Puzzled, > Erik Sorry. I jumped on the statement: > Hopefully the discussion has shown that there are possibilities to do > new and exiting things, even though there aren't any projects that are > working on the details. Well, this project by itself does at least one "new and exciting thing" as in ... Enables separation without network security issues for customers that connect separate (V)LANs to separate zones; something we can not currently provide. The other questions in the tread (which I'll only have claimed to scanned) are often of the form "could this also work for ...". These are also legitimate questions as they may alter the *form* of the interface. However, *none* of this fits in the characterization I jumped to of "shinny new mechanism. This clearly isn't that. =================================================================== My bad. (BTW: I hope this is "exciting things" and not "exiting things"... 8^) - jek3 From sacadmin Wed Nov 1 11:02:06 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA1J26ju021044 for ; Wed, 1 Nov 2006 11:02:06 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id kA1J24815380; Wed, 1 Nov 2006 11:02:04 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J8200M1BFJEL800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 01 Nov 2006 11:02:02 -0800 (PST) Received: from sac.sfbay.sun.com ([129.146.175.66]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J8200JBBFJC8970@nwk-avmta-1.sfbay.Sun.COM>; Wed, 01 Nov 2006 11:02:00 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA1J20O3021016; Wed, 01 Nov 2006 11:02:00 -0800 (PST) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id kA1J1xFP021015; Wed, 01 Nov 2006 11:01:59 -0800 (PST) Date: Wed, 01 Nov 2006 11:01:59 -0800 (PST) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2006/366 Stack instances Exclusive IP stack per zone To: PSARC@sun.com Cc: Erik.Nordmark@sun.com, PSARC-coord@sun.com Message-id: <200611011901.kA1J1xFP021015@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2999 New Materials submitted for PSARC 2006/366 Stack instances Exclusive IP stack per zone Status: commitment scheduled 11/08/2006 Files: /shared/sac/PSARC/2006/366/commitment.materials/0list-of-changes /shared/sac/PSARC/2006/366/commitment.materials/getsockopt.3.diff /shared/sac/PSARC/2006/366/commitment.materials/getsockopt.3.txt /shared/sac/PSARC/2006/366/commitment.materials/if_tcp.7p.diff /shared/sac/PSARC/2006/366/commitment.materials/if_tcp.7p.txt /shared/sac/PSARC/2006/366/commitment.materials/ifconfig.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/ifconfig.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/ikeadm.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/ikeadm.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/ikecert.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/ikecert.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/in.iked.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/in.iked.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/ipsecalgs.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/ipsecalgs.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/ipsecconf.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/ipsecconf.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/ipseckey.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/ipseckey.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/net_lookup.9f.diff /shared/sac/PSARC/2006/366/commitment.materials/net_lookup.9f.txt /shared/sac/PSARC/2006/366/commitment.materials/net_register.9f.diff /shared/sac/PSARC/2006/366/commitment.materials/net_register.9f.txt /shared/sac/PSARC/2006/366/commitment.materials/net_walk.9f.diff /shared/sac/PSARC/2006/366/commitment.materials/net_walk.9f.txt /shared/sac/PSARC/2006/366/commitment.materials/netstat.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/netstat.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/privileges.5.diff /shared/sac/PSARC/2006/366/commitment.materials/privileges.5.txt /shared/sac/PSARC/2006/366/commitment.materials/routeadm.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/si-20-questions-commit.txt /shared/sac/PSARC/2006/366/commitment.materials/si-interfaces-wdiff.html /shared/sac/PSARC/2006/366/commitment.materials/si-interfaces.pdf /shared/sac/PSARC/2006/366/commitment.materials/si-psarc.tar /shared/sac/PSARC/2006/366/commitment.materials/traceroute.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/traceroute.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/updated-response-to-inception-issues /shared/sac/PSARC/2006/366/commitment.materials/zoneadm.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/zoneadm.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/zonecfg.1m.diff /shared/sac/PSARC/2006/366/commitment.materials/zonecfg.1m.txt /shared/sac/PSARC/2006/366/commitment.materials/zones.5.diff /shared/sac/PSARC/2006/366/commitment.materials/zones.5.txt Please let me know if you have questions. - PSARC From sac-owner Thu Nov 9 08:17:25 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA9GHOnF013125 for ; Thu, 9 Nov 2006 08:17:24 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id kA9GHGIh014311 for <@sunmail3.sfbay.sun.com:sac-review@sun.com>; Fri, 10 Nov 2006 00:17:23 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J8H00B0L18YKL00@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Thu, 09 Nov 2006 08:17:22 -0800 (PST) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J8H00A6Q18X3920@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Thu, 09 Nov 2006 08:17:21 -0800 (PST) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA9GHLCa019493 for ; Thu, 09 Nov 2006 08:17:21 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J8H00K0117SPX00@d1-sfbay-09.sun.com> (original mail from Sherri.Shieh@Sun.COM) for sac-review@sun.com (ORCPT sac-review@sun.com); Thu, 09 Nov 2006 08:17:21 -0800 (PST) Received: from [129.150.29.61] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J8H00D2018WVOCO@d1-sfbay-09.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Thu, 09 Nov 2006 08:17:21 -0800 (PST) Date: Thu, 09 Nov 2006 08:17:27 -0800 From: Sherri Shieh Subject: PSARC Case Approved 11/08/2006 - 2006/366 Sender: Sherri.Shieh@sun.com To: Sherri Shieh Reply-to: Sherri.Shieh@sun.com Message-id: <45535497.9000607@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 241 PSARC approved 11/08/2006 Case: Stack instances: Exclusive IP stack per zone (2006/366) Incompatible Changes: none Precedent: none If more information is needed, please contact the case owner/intern. From sacadmin Mon Jan 22 10:51:57 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0MIpviP023938 for ; Mon, 22 Jan 2007 10:51:57 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0MIpvF2000456 for ; Mon, 22 Jan 2007 10:51:57 -0800 (PST) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0MIpv65023842 for ; Mon, 22 Jan 2007 11:51:57 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCA004019AZIJ00@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 22 Jan 2007 11:51:56 -0700 (MST) Received: from [129.152.9.11] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCA00G269QJOXQA@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Mon, 22 Jan 2007 11:51:56 -0700 (MST) Date: Mon, 22 Jan 2007 12:51:55 -0600 From: Rick Matthews Subject: Opinion for review: PSARC/2006/366 - Stack Instances: Exclusive IP stack per zone Sender: Richard.Matthews@Sun.COM To: psarc@sac.sfbay.sun.com, Dong-Hai Han Message-id: <45B507CB.9000009@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_jynjwPpKR3ooaTiSMy4xNQ)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 12741 This is a multi-part message in MIME format. --Boundary_(ID_jynjwPpKR3ooaTiSMy4xNQ) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Please review the attached opinion by 01/29/2007. There is a opinion.ps file in the case directory as well. Rick -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- --Boundary_(ID_jynjwPpKR3ooaTiSMy4xNQ) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Stack instances: Exclusive IP stack per zone Submitted by: Erik Nordmark File: PSARC/2006/366/opinion.ms Date: November 8th, 2006 Committee: Kais Belgaied (opinion written by Rick Matthews), James Carlson, Ed Gould, Glenn Skinner, Bill Sommerfeld, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac@sun.com 1. Summary This case proposes an extension to zones to allow (as an option) a zone's IP networking be completely separate from the IP networking in other zones. This separation can iso- late a zone's IP networking from the global zone as well. 2. Decision & Precedence Information This project is approved as specified in reference [1] but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a micro release of Solaris. 3. Interfaces The project exports the following interfaces. ________________________________________________________________________________ | Interfaces Exported | |__________________________|_______________________|___________________________| |Interface | Classification | Comments | |__________________________|_______________________|___________________________| |zonecfg extensions | | [8], The existing zonecfg| | | | syntax was classified as | | | | Evolving in [9]. | | ip-type property | Committed | | | | | | |zoneadm extensions | | [7] | | -l list_option | Committed | | | -v/-p output format | Committed | | |__________________________|_______________________|___________________________| PSARC/2006/366 Copyright 2006 Sun Microsystems - 2 - ________________________________________________________________________________ | Interfaces Exported | |__________________________|_______________________|___________________________| |Interface | Classification | Comments | |__________________________|_______________________|___________________________| | | | | |dladm extensions | | [2] | | in show-linkprop | Committed | displays zone | | in set-linkprop | Committed | specifies zone | | | | | |privileges(5) | | [6] | |PRIV_SYS_IP_CONFIG | Committed | The privilege names in | | | | [10] are stable. | | | | | |Extensions to zone xml | Project Private | Introduced by [9] | |zone_create flags | Project Private | excl or shared | |zone_add_ifname() | Project Private | restrict=yes implementa- | | | | tion | |zone_remove_ifname() | Project Private | | |zone_ifname_lookup() | Project Private | | | | | | |netstack_register() | Project Private | Akin to zone_key_create()| |netstack_unregister() | Project Private | | | | | | |netstack_get_current() | Project Private | For xx_open lookups, etc.| |netstack_find_by_cred() | Project Private | | |netstack_find_by_stackid()| Project Private | | |netstack_hold() | Project Private | | |netstack_rele() | Project Private | | |netstackid_to_zoneid() | Project Private | | |zoneid_to_netstackid() | Project Private | | | | | | |kstat_create_netstack() | Project Private | For kstats made visible | | | | for one netstack. | |kstat_destoy_netstack() | Project Private | | | | | | |netstack_handle_t | Project Private | For modules that need to | | | | walk all netstacks. | |netstack_next_init() | Project Private | | |netstack_next_fini() | Project Private | | |netstack_next() | Project Private | | | | | | |secpolicy_ip_config() | Consolidation Private| | | | | | |net_register() | Consolidation Private| [4], added zoneid argu- | | | | ment, introduced in [11] | |net_lookup() | Consolidation Private| [3], added zoneid argu- | | | | ment, introduced in [11] | |net_walk() | Consolidation Private| [5], added zoneid argu- | | | | ment, introduced in [11] | | | | | |hook_run() | Project Private | Introduced in [11] | | | | | |platform.xml | Project Private | Introduced in [12] | |__________________________|_______________________|___________________________| PSARC/2006/366 Copyright 2006 Sun Microsystems - 3 - ________________________________________________________________________________ | Interfaces Exported | |__________________________|_______________________|___________________________| |Interface | Classification | Comments | |__________________________|_______________________|___________________________| |__________________________|_______________________|___________________________| The project imports the following interfaces. ____________________________________________________ | Interfaces Imported | |_______________|_______________________|__________| |Interface | Classification | Comments| |_______________|_______________________|__________| |zone_key_create| Consolidation Private| | |_______________|_______________________|__________| 4. Opinion 4.1. zoneadm list The project proposed exposing zone specific information for IP networking from zoneadm list. The IP networking zone con- figuration should be made with dladm show-linkprop and be removed from zoneadm. Some members of the committee were concerned that adding networking specifics to zoneadm list was contrary to any other means (like file systems) of exposing zone specific information. This issue resulted in TCR-1. 4.2. Use of zoneid The net_* functions (net_register, net_lookup, net_walk) require a zoneid argument. We need to raise the stability of the zoneid, as provided by netstackid_to_zoneid(), to Conso- lidation Private. This issue resulted in TCR-2. 4.3. Use of the global zone This project interacts with individual zones as well as the global zone. Portions of the documentation were not specific as to relation to the global zone. This should be clarified in the documentation. 4.4. Future Direction for this project The project as proposed is complete and useful on its own, but substantially duplicates a capability provided by two current virtual machine projects (LDOMS, (FWARC 2005/633), and Xen, (PSARC 2006/260)). PSARC/2006/366 Copyright 2006 Sun Microsystems - 4 - Its promise is greatest as a basis for certain other future capabilities which are not entirely practical in a virtual machine environment, but the project team was insistent dur- ing the review that the future work, while reasonable, was not planned. 4.4.1. Secure observability from the global zone. After a successful attack on a zone, the software in that zone may be compromised in subtle ways, altering the behavior of tools such as "netstat" within that zone. It should be possible to use the global zone's copy of tools such as "netstat" from the global zone to accurately observe kernel state associated with the zone and its stack instance. The project team suggested using mdb, but mdb is not really suitable for this purpose. 4.4.2. Zones vs. virtual machines The committee is concerned that should these follow-on pro- jects not materialize, we will further confuse customers as to the relative applicability of zones vs. virtual machines, and create a maintainance and support burden for the groups working on and near the Solaris IP stack. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project must not use use zoneadm list -l to display IP instances. This function ahould be added to dladm rather than zoneadm. 2. The netstackid interface and routines that manipu- late it must be Consolidation Private. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material All path names are relative to the case directory (PSARC/2006/366). PSARC/2006/366 Copyright 2006 Sun Microsystems - 5 - 1 Project Specification - final.materials/si- interfaces.pdf 2 manpage - final.materials/dladm.1m.txt 3 manpage - commitment.materials/net_lookup.9f.txt 4 manpage - commitment.materials/net_register.9f.txt 5 manpage - commitment.materials/netstat.1m.txt 6 manpage - commitment.materials/net_walk.9f.txt 7 manpage - commitment.materials/privileges.5.txt 8 manpage - commitment.materials/zoneadm.1m.txt The following PSARC cases are referenced in this opinion, and can be found in the appropriate PSARC case directory: 9 PSARC 2002/174 Virtualization and Namespace Isolation in Solaris 10 PSARC 2002/188 Least privilege for Solaris 11 PSARC 2005/334 Packet Filtering Hooks APIs 12 PSARC 2005/471 BrandZ: Support for non-native zones PSARC/2006/366 Copyright 2006 Sun Microsystems --Boundary_(ID_jynjwPpKR3ooaTiSMy4xNQ)-- From sacadmin Mon Jan 22 12:33:00 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0MKWxsp027456 for ; Mon, 22 Jan 2007 12:33:00 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0MKWxut999931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 12:32:59 -0800 (PST) Message-ID: <45B51F7B.2070106@sun.com> Date: Mon, 22 Jan 2007 12:32:59 -0800 From: Erik Nordmark User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Rick Matthews CC: psarc@sac.sfbay.sun.com, Dong-Hai Han Subject: Re: Opinion for review: PSARC/2006/366 - Stack Instances: Exclusive IP stack per zone References: <45B507CB.9000009@Sun.COM> In-Reply-To: <45B507CB.9000009@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 299 Rick Matthews wrote: > Please review the attached opinion by 01/29/2007. There > is a opinion.ps file in the case directory as well. > > Rick > The opinion says The project may be delivered in a micro release of Solaris. but the project team asked for patch binding. Is that a typo? Erik From sacadmin Mon Jan 22 12:53:29 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0MKrTAJ027668 for ; Mon, 22 Jan 2007 12:53:29 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0MKrTw4001129 for ; Mon, 22 Jan 2007 12:53:29 -0800 (PST) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0MKrTKG021262 for ; Mon, 22 Jan 2007 13:53:29 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCA00G01EY60900@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 22 Jan 2007 13:53:29 -0700 (MST) Received: from [129.152.9.11] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCA006AQFD4YT30@mail-amer.sun.com>; Mon, 22 Jan 2007 13:53:29 -0700 (MST) Date: Mon, 22 Jan 2007 14:53:28 -0600 From: Rick Matthews Subject: Re: Opinion for review: PSARC/2006/366 - Stack Instances: Exclusive IP stack per zone In-reply-to: <45B51F7B.2070106@sun.com> Sender: Richard.Matthews@Sun.COM To: Erik Nordmark Cc: psarc@sac.sfbay.sun.com, Dong-Hai Han Message-id: <45B52448.9080504@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <45B507CB.9000009@Sun.COM> <45B51F7B.2070106@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1041 Erik and all, It depended which 20Q I looked at. I missed the fact that the release had changed from micro initially to micro/patch in the commitment materials. I'll update that in the opinion. -- Rick Erik Nordmark wrote On 01/22/07 02:32 PM,: > Rick Matthews wrote: > >> Please review the attached opinion by 01/29/2007. There >> is a opinion.ps file in the case directory as well. >> >> Rick >> > > The opinion says > The project may be delivered in a micro release of Solaris. > but the project team asked for patch binding. > > Is that a typo? > > Erik > -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- From sacadmin Fri Feb 9 08:18:28 2007 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19GIRRc000177 for ; Fri, 9 Feb 2007 08:18:28 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l19GIMvT000494 for ; Sat, 10 Feb 2007 00:18:22 +0800 (SGT) Received: from sun.com ([129.158.123.14]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JD700HKJEMJPJCE@mail-apac.sun.com> for psarc@sac.sfbay.sun.com; Sat, 10 Feb 2007 00:18:19 +0800 (SGT) Received: from [192.18.19.174] (Forwarded-For: [129.150.144.18]) by sedge2-mail1.singapore.sun.com (mshttpd); Sat, 10 Feb 2007 00:18:19 +0800 Date: Sat, 10 Feb 2007 00:18:19 +0800 From: Dong-Hai Han Subject: PSARC 2006/366 Stack Instances: Exclusive IP stack per zone To: psarc@sac.sfbay.sun.com Cc: stack-instance-iteam@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal Status: RO Content-Length: 637 This project was approved with patch/micro release binding. During backport, we discovered that one of the interfaces we are modifying (the dladm {show,set,reset}-linkprop subcommands) is not present in the update release (S10U4) we're targeting, because "WiFi For GLDv3" (PSARC 2006/406) has not been backported yet. Thus, we plan to deliver these subcommands without the WiFi and secobj support features, in order to manage the zone property. We believe this change to be trivial enough that it does not require additional review, but if anyone disagrees, please speak up and we'll open a new case to discuss it. Best, Donghai. From sacadmin Fri Feb 9 12:17:17 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19KHHnj003221 for ; Fri, 9 Feb 2007 12:17:17 -0800 (PST) Received: from [129.145.154.81] (sr1-umpk-31.SFBay.Sun.COM [129.145.154.81]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l19KH6ib295036; Fri, 9 Feb 2007 12:17:06 -0800 (PST) Message-ID: <45CCD6C2.4000803@Sun.COM> Date: Fri, 09 Feb 2007 12:17:06 -0800 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060727 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: Dong-Hai Han CC: psarc@sac.sfbay.sun.com, stack-instance-iteam@Sun.COM Subject: Re: PSARC 2006/366 Stack Instances: Exclusive IP stack per zone References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1285 Dong-Hai Han wrote On 02/09/07 08:18 AM,: >This project was approved with patch/micro release binding. During >backport, we discovered that one of the interfaces we are modifying >(the dladm {show,set,reset}-linkprop subcommands) is not present in >the update release (S10U4) we're targeting, because "WiFi For GLDv3" >(PSARC 2006/406) has not been backported yet. > > PSARC/2006/366 has a dependency on PSARC/2006/406 then. Stating it was not relevant during the commitment (and opinion review) of 2006/366 because PSARC/2006/406 has already delivered dladm {show,set,reset}-linkprop subcommandsin onnv. >Thus, we plan to deliver these subcommands without the WiFi and >secobj support features, in order to manage the zone property. We > > sounds like a s10u4 C-team matter here. If they're OK with back porting 2006/366 in two steps (1st without the zone link property) then 2006/406, then the rest of 2006/366 Now, that C-team needs to be aware of the fact that if s10u4 must ship before 2006/406 ever makes, then the PSARC/2006/366 code in s10u4 is incomplete. Kais. >believe this change to be trivial enough that it does not require >additional review, but if anyone disagrees, please speak up and >we'll open a new case to discuss it. > >Best, > >Donghai. > > > From sacadmin Fri Feb 9 12:45:48 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19Kjmtl003392 for ; Fri, 9 Feb 2007 12:45:48 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l19KjlA2026583; Fri, 9 Feb 2007 15:45:47 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l19Kjlxt026580; Fri, 9 Feb 2007 15:45:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17868.56699.357952.627145@gargle.gargle.HOWL> Date: Fri, 9 Feb 2007 15:45:47 -0500 From: James Carlson To: Kais Belgaied Cc: Dong-Hai Han , psarc@sac.sfbay.sun.com, stack-instance-iteam@sun.com Subject: Re: PSARC 2006/366 Stack Instances: Exclusive IP stack per zone In-Reply-To: <45CCD6C2.4000803@Sun.COM> References: <45CCD6C2.4000803@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 924 Kais Belgaied writes: > PSARC/2006/366 has a dependency on PSARC/2006/406 then. Not exactly. They both just deliver new attributes to the same brand-new subcommand. If the '366 case had integrated into Nevada first, then it'd be '406 that'd be extending the same commands. The ordering really doesn't matter here, and that's what's pointed out by this update message. > Now, that C-team needs to be aware of the fact that if s10u4 must ship > before 2006/406 ever makes, then the > PSARC/2006/366 code in s10u4 is incomplete. That's absolutely false. If only '366 goes into s10u4, then it's *NOT* incomplete. You won't have the WiFi attributes from '406, but that doesn't harm the interface. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Fri Feb 9 15:26:13 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.55]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19NQDou006490 for ; Fri, 9 Feb 2007 15:26:13 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l19NQAfA336463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Feb 2007 15:26:11 -0800 (PST) Message-ID: <45CD0312.80703@sun.com> Date: Fri, 09 Feb 2007 15:26:10 -0800 From: Erik Nordmark User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Kais Belgaied CC: Dong-Hai Han , psarc@sac.sfbay.sun.com, stack-instance-iteam@sun.com Subject: Re: PSARC 2006/366 Stack Instances: Exclusive IP stack per zone References: <45CCD6C2.4000803@Sun.COM> In-Reply-To: <45CCD6C2.4000803@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 624 Kais Belgaied wrote: > sounds like a s10u4 C-team matter here. > If they're OK with back porting 2006/366 in two steps (1st without the > zone link property) then > 2006/406, then the rest of 2006/366 > > Now, that C-team needs to be aware of the fact that if s10u4 must ship > before 2006/406 ever makes, then the > PSARC/2006/366 code in s10u4 is incomplete. Kais, The plan is to integrate 2006/366 plus the {show,set,reset}-linkprop subset of 2006/406 at the same time. Thus 2006/366 would be complete in S10U4 - with the zone property for dladm {show,set,reset}-linkprop that PSARC asked for in the TCR. Erik From sacadmin Fri Feb 9 19:48:48 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1A3mmBH016545 for ; Fri, 9 Feb 2007 19:48:48 -0800 (PST) Received: from [129.145.154.81] (sr1-umpk-31.SFBay.Sun.COM [129.145.154.81]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1A3mkT2385915; Fri, 9 Feb 2007 19:48:46 -0800 (PST) Message-ID: <45CD409E.10804@Sun.COM> Date: Fri, 09 Feb 2007 19:48:46 -0800 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060727 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: James Carlson CC: Dong-Hai Han , psarc@sac.sfbay.sun.com, stack-instance-iteam@Sun.COM Subject: Re: PSARC 2006/366 Stack Instances: Exclusive IP stack per zone References: <45CCD6C2.4000803@Sun.COM> <17868.56699.357952.627145@gargle.gargle.HOWL> In-Reply-To: <17868.56699.357952.627145@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1718 James Carlson wrote On 02/09/07 12:45 PM,: >Kais Belgaied writes: > > >>PSARC/2006/366 has a dependency on PSARC/2006/406 then. >> >> > >Not exactly. They both just deliver new attributes to the same >brand-new subcommand. If the '366 case had integrated into Nevada >first, then it'd be '406 that'd be extending the same commands. > >The ordering really doesn't matter here, and that's what's pointed out >by this update message. > > Not quite: A single onnv putback of the WiFi for GLDv3 integrated the following in as single SCCS delta: PSARC/2006/406 WiFi for GLDv3 PSARC/2006/517 WiFi for GLDv3 Addendum PSARC/2006/623 WiFi for GLDv3 Addendum #2 6484943 integrate WiFi/GLDv3 which includes the concept of link properties all together, then the properies specific to wifi. >>Now, that C-team needs to be aware of the fact that if s10u4 must ship >>before 2006/406 ever makes, then the >>PSARC/2006/366 code in s10u4 is incomplete. >> >> > >That's absolutely false. If only '366 goes into s10u4, then it's >*NOT* incomplete. > > like I said in the sentence right before that: > If they're OK with back porting 2006/366 in two steps (1st without the > zone link property) then > 2006/406, then the rest of 2006/366 > > In other words 1st step only: '366 minus the use of linkprops for link's zoneID is incomplete because it is missing the implementation of the TCR. Reading again Dong-Hai's email and Erik's clarifying reply, they mean "carve the code for link properties out of 406 and back-port it with 366". So, as such, yes the backported '366 + subset of 406 wad is complete. Kais >You won't have the WiFi attributes from '406, but that doesn't harm >the interface. > > > From sacadmin Mon Feb 12 05:08:55 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1CD8t6V015726 for ; Mon, 12 Feb 2007 05:08:55 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1CD8shE008743; Mon, 12 Feb 2007 08:08:54 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l1CD8sqC008740; Mon, 12 Feb 2007 08:08:54 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17872.26342.411590.739580@gargle.gargle.HOWL> Date: Mon, 12 Feb 2007 08:08:54 -0500 From: James Carlson To: Kais Belgaied Cc: Dong-Hai Han , psarc@sac.sfbay.sun.com, stack-instance-iteam@sun.com Subject: Re: PSARC 2006/366 Stack Instances: Exclusive IP stack per zone In-Reply-To: <45CD409E.10804@Sun.COM> References: <45CCD6C2.4000803@Sun.COM> <17868.56699.357952.627145@gargle.gargle.HOWL> <45CD409E.10804@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 695 Kais Belgaied writes: > In other words 1st step only: '366 minus the use of linkprops for link's > zoneID is incomplete > because it is missing the implementation of the TCR. Nobody was suggesting '366 minus linkprops, as far as I know. > Reading again Dong-Hai's email and Erik's clarifying reply, they mean > "carve the code for link properties out of 406 and back-port it with 366". > So, as such, yes the backported '366 + subset of 406 wad is complete. Exactly. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Thu Mar 15 10:55:35 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2FHtYwM014121 for ; Thu, 15 Mar 2007 10:55:34 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2FHtWqp009156 for ; Thu, 15 Mar 2007 17:55:33 GMT Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2FHtWfW000917 for ; Thu, 15 Mar 2007 17:55:32 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JEY00501HLJL600@mail-amer.sun.com> (original mail from rick.matthews@sun.com) for sac-review@sun.com (ORCPT sac-review@sun.com); Thu, 15 Mar 2007 11:55:32 -0600 (MDT) Received: from [192.168.1.101] ([129.150.33.174]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEY00L8UHSD2080@mail-amer.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Thu, 15 Mar 2007 11:55:30 -0600 (MDT) Date: Thu, 15 Mar 2007 12:55:25 -0500 From: Rick Matthews Subject: Opinion for review: PSARC/2006/366 - Stack instances: Exclusive IP stack per zone Sender: Richard.Matthews@sun.com To: sac-review@sun.com Message-id: <45F9888D.8060308@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_cVSYODe/ZO4YBk3DfTwFMw)" User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 12279 This is a multi-part message in MIME format. --Boundary_(ID_cVSYODe/ZO4YBk3DfTwFMw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Please review the attached opinion, and submit any comments by 03/23/2007. --Boundary_(ID_cVSYODe/ZO4YBk3DfTwFMw) Content-type: text/plain; name=opinion.txt; x-mac-creator=0; x-mac-type=0 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Stack instances: Exclusive IP stack per zone Submitted by: Erik Nordmark File: PSARC/2006/366/opinion.ms Date: November 8th, 2006 Committee: Kais Belgaied (opinion written by Rick Matthews), James Carlson, Ed Gould, Glenn Skinner, Bill Sommerfeld, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac@sun.com 1. Summary This case proposes an extension to zones to allow (as an option) a zone's IP networking be completely separate from the IP networking in other zones. This separation can iso- late a zone's IP networking from the global zone as well. 2. Decision & Precedence Information This project is approved as specified in reference [1] but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a micro or patch release of Solaris. 3. Interfaces The project exports the following interfaces. ________________________________________________________________________________ | Interfaces Exported | |__________________________|_______________________|___________________________| |Interface | Classification | Comments | |__________________________|_______________________|___________________________| |zonecfg extensions | | [8], The existing zonecfg| | | | syntax was classified as | | | | Evolving in [9]. | | ip-type property | Committed | | | | | | |zoneadm extensions | | [7] | | -l list_option | Committed | | |__________________________|_______________________|___________________________| PSARC/2006/366 Copyright 2006 Sun Microsystems - 2 - ________________________________________________________________________________ | Interfaces Exported | |__________________________|_______________________|___________________________| |Interface | Classification | Comments | |__________________________|_______________________|___________________________| | -v/-p output format | Committed | | | | | | |dladm extensions | | [2] | | in show-linkprop | Committed | displays zone | | in set-linkprop | Committed | specifies zone | | | | | |privileges(5) | | [6] | |PRIV_SYS_IP_CONFIG | Committed | The privilege names in | | | | [10] are stable. | | | | | |Extensions to zone xml | Project Private | Introduced by [9] | |zone_create flags | Project Private | excl or shared | |zone_add_ifname() | Project Private | restrict=yes implementa- | | | | tion | |zone_remove_ifname() | Project Private | | |zone_ifname_lookup() | Project Private | | | | | | |netstack_register() | Project Private | Akin to zone_key_create()| |netstack_unregister() | Project Private | | | | | | |netstack_get_current() | Project Private | For xx_open lookups, etc.| |netstack_find_by_cred() | Project Private | | |netstack_find_by_stackid()| Project Private | | |netstack_hold() | Project Private | | |netstack_rele() | Project Private | | |netstackid_to_zoneid() | Project Private | | |zoneid_to_netstackid() | Project Private | | | | | | |kstat_create_netstack() | Project Private | For kstats made visible | | | | for one netstack. | |kstat_destoy_netstack() | Project Private | | | | | | |netstack_handle_t | Project Private | For modules that need to | | | | walk all netstacks. | |netstack_next_init() | Project Private | | |netstack_next_fini() | Project Private | | |netstack_next() | Project Private | | | | | | |secpolicy_ip_config() | Consolidation Private| | | | | | |net_register() | Consolidation Private| [4], added zoneid argu- | | | | ment, introduced in [11] | |net_lookup() | Consolidation Private| [3], added zoneid argu- | | | | ment, introduced in [11] | |net_walk() | Consolidation Private| [5], added zoneid argu- | | | | ment, introduced in [11] | | | | | |hook_run() | Project Private | Introduced in [11] | | | | | |__________________________|_______________________|___________________________| PSARC/2006/366 Copyright 2006 Sun Microsystems - 3 - ________________________________________________________________________________ | Interfaces Exported | |__________________________|_______________________|___________________________| |Interface | Classification | Comments | |__________________________|_______________________|___________________________| |platform.xml | Project Private | Introduced in [12] | |__________________________|_______________________|___________________________| The project imports the following interfaces. ____________________________________________________ | Interfaces Imported | |_______________|_______________________|__________| |Interface | Classification | Comments| |_______________|_______________________|__________| |zone_key_create| Consolidation Private| | |_______________|_______________________|__________| 4. Opinion 4.1. zoneadm list The project proposed exposing zone specific information for IP networking from zoneadm list. The IP networking zone con- figuration should be made with dladm show-linkprop and be removed from zoneadm. Some members of the committee were concerned that adding networking specifics to zoneadm list was contrary to any other means (like file systems) of exposing zone specific information. This issue resulted in TCR-1. 4.2. Use of zoneid The net_* functions (net_register, net_lookup, net_walk) require a zoneid argument. We need to raise the stability of the zoneid, as provided by netstackid_to_zoneid(), to Conso- lidation Private. This issue resulted in TCR-2. 4.3. Use of the global zone This project interacts with individual zones as well as the global zone. Portions of the documentation were not specific as to relation to the global zone. This should be clarified in the documentation. 4.4. Future Direction for this project The project as proposed is complete and useful on its own, but substantially duplicates a capability provided by two current virtual machine projects (LDOMS, (FWARC 2005/633), and Xen, (PSARC 2006/260)). PSARC/2006/366 Copyright 2006 Sun Microsystems - 4 - Its promise is greatest as a basis for certain other future capabilities which are not entirely practical in a virtual machine environment, but the project team was insistent dur- ing the review that the future work, while reasonable, was not planned. 4.4.1. Secure observability from the global zone. After a successful attack on a zone, the software in that zone may be compromised in subtle ways, altering the behavior of tools such as "netstat" within that zone. It should be possible to use the global zone's copy of tools such as "netstat" from the global zone to accurately observe kernel state associated with the zone and its stack instance. The project team suggested using mdb, but mdb is not really suitable for this purpose. 4.4.2. Zones vs. virtual machines The committee is concerned that should these follow-on pro- jects not materialize, we will further confuse customers as to the relative applicability of zones vs. virtual machines, and create a maintainance and support burden for the groups working on and near the Solaris IP stack. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project must not use use zoneadm list -l to display IP instances. This function ahould be added to dladm rather than zoneadm. 2. The netstackid interface and routines that manipu- late it must be Consolidation Private. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material All path names are relative to the case directory (PSARC/2006/366). PSARC/2006/366 Copyright 2006 Sun Microsystems - 5 - 1 Project Specification - final.materials/si- interfaces.pdf 2 manpage - final.materials/dladm.1m.txt 3 manpage - commitment.materials/net_lookup.9f.txt 4 manpage - commitment.materials/net_register.9f.txt 5 manpage - commitment.materials/netstat.1m.txt 6 manpage - commitment.materials/net_walk.9f.txt 7 manpage - commitment.materials/privileges.5.txt 8 manpage - commitment.materials/zoneadm.1m.txt The following PSARC cases are referenced in this opinion, and can be found in the appropriate PSARC case directory: 9 PSARC 2002/174 Virtualization and Namespace Isolation in Solaris 10 PSARC 2002/188 Least privilege for Solaris 11 PSARC 2005/334 Packet Filtering Hooks APIs 12 PSARC 2005/471 BrandZ: Support for non-native zones PSARC/2006/366 Copyright 2006 Sun Microsystems --Boundary_(ID_cVSYODe/ZO4YBk3DfTwFMw)-- From sacadmin Thu Mar 22 21:01:00 2007 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2N40xbS027960 for ; Thu, 22 Mar 2007 21:01:00 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2N40sKP005338 for ; Fri, 23 Mar 2007 04:00:54 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFC00H01824RB00@mail-apac.sun.com> (original mail from Donghai.Han@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 23 Mar 2007 12:00:54 +0800 (SGT) Received: from [129.158.219.115] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFC006ZD8H8W933@mail-apac.sun.com> for psarc@sac.sfbay.sun.com; Fri, 23 Mar 2007 12:00:45 +0800 (SGT) Date: Fri, 23 Mar 2007 12:00:13 +0800 From: Dong-Hai Han Subject: 2006/366 Stack instances Sender: Donghai.Han@Sun.COM To: psarc@sac.sfbay.sun.com Reply-to: Donghai.Han@Sun.COM Message-id: <460350CD.3030300@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: zh-cn User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; zh-CN; rv:1.7) Gecko/20041207 Status: RO Content-Length: 407 Hello, (A short note per James' request) As the output of TCR 1 (replacing zoneadm list -l with dladm) ( http://sac.sfbay.sun.com/PSARC/2006/366/opinion.txt, 7.1), IP Instances now has closer coupling with dladm/GLDv3, thus the restrictions of NIC drivers has been narrowed to Nemo/GLDv3 drivers, that is, only those NIC-s with Nemo/GLDv3 drivers could be assigned to exclusive IP zones. Best, Donghai. From sac-owner Wed Mar 28 10:26:23 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SHQNI2028524 for ; Wed, 28 Mar 2007 10:26:23 -0700 (PDT) Received: from sunmail3mpk.sfbay.sun.com (localhost [127.0.0.1]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SHQMxl026949 for ; Wed, 28 Mar 2007 10:26:22 -0700 (PDT) Received: (from noaccess@localhost) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/Submit) id l2SHQMG3026948 for sac-opinion-not-2b-used-directly; Wed, 28 Mar 2007 10:26:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SHQMTi026941; Wed, 28 Mar 2007 10:26:22 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFM00705J3Y4M00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 28 Mar 2007 10:26:22 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFM00I9PJ3X3A90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 28 Mar 2007 10:26:21 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2SHQLhI020114; Wed, 28 Mar 2007 17:26:21 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFM00401J1VR800@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM); Wed, 28 Mar 2007 11:26:21 -0600 (MDT) Received: from [129.152.9.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFM008YGJ3WZ466@mail-amer.sun.com>; Wed, 28 Mar 2007 11:26:20 -0600 (MDT) Date: Wed, 28 Mar 2007 12:26:20 -0500 From: Rick Matthews Subject: Opinion: PSARC/2006/366 Stack instances: Exclusive IP stack per zone Sender: Richard.Matthews@Sun.Com To: sac-opinion@Sun.Com, solaris-pac-opinion@Sun.Com Message-id: <460AA53C.6080106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 11916 This email is to archive the opinion that the case is closed approved, and to forward the opinion to Solaris PAC. sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Stack instances: Exclusive IP stack per zone Submitted by: Erik Nordmark File: PSARC/2006/366/opinion.ms Date: November 8th, 2006 Committee: Kais Belgaied (opinion written by Rick Matthews), James Carlson, Ed Gould, Glenn Skinner, Bill Sommerfeld, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac@sun.com 1. Summary This case proposes an extension to zones to allow (as an option) a zone's IP networking be completely separate from the IP networking in other zones. This separation can iso- late a zone's IP networking from the global zone as well. 2. Decision & Precedence Information This project is approved as specified in reference [1] but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a micro or patch release of Solaris. 3. Interfaces The project exports the following interfaces. ________________________________________________________________________________ | Interfaces Exported | |__________________________|_______________________|___________________________| |Interface | Classification | Comments | |__________________________|_______________________|___________________________| |zonecfg extensions | | [8], The existing zonecfg| | | | syntax was classified as | | | | Evolving in [9]. | | ip-type property | Committed | | | | | | |zoneadm extensions | | [7] | | -l list_option | Committed | | |__________________________|_______________________|___________________________| PSARC/2006/366 Copyright 2006 Sun Microsystems - 2 - ________________________________________________________________________________ | Interfaces Exported | |__________________________|_______________________|___________________________| |Interface | Classification | Comments | |__________________________|_______________________|___________________________| | -v/-p output format | Committed | | | | | | |dladm extensions | | [2] | | in show-linkprop | Committed | displays zone | | in set-linkprop | Committed | specifies zone | | | | | |privileges(5) | | [6] | |PRIV_SYS_IP_CONFIG | Committed | The privilege names in | | | | [10] are stable. | | | | | |Extensions to zone xml | Project Private | Introduced by [9] | |zone_create flags | Project Private | excl or shared | |zone_add_ifname() | Project Private | restrict=yes implementa- | | | | tion | |zone_remove_ifname() | Project Private | | |zone_ifname_lookup() | Project Private | | | | | | |netstack_register() | Project Private | Akin to zone_key_create()| |netstack_unregister() | Project Private | | | | | | |netstack_get_current() | Project Private | For xx_open lookups, etc.| |netstack_find_by_cred() | Project Private | | |netstack_find_by_stackid()| Project Private | | |netstack_hold() | Project Private | | |netstack_rele() | Project Private | | |netstackid_to_zoneid() | Project Private | | |zoneid_to_netstackid() | Project Private | | | | | | |kstat_create_netstack() | Project Private | For kstats made visible | | | | for one netstack. | |kstat_destoy_netstack() | Project Private | | | | | | |netstack_handle_t | Project Private | For modules that need to | | | | walk all netstacks. | |netstack_next_init() | Project Private | | |netstack_next_fini() | Project Private | | |netstack_next() | Project Private | | | | | | |secpolicy_ip_config() | Consolidation Private| | | | | | |net_register() | Consolidation Private| [4], added zoneid argu- | | | | ment, introduced in [11] | |net_lookup() | Consolidation Private| [3], added zoneid argu- | | | | ment, introduced in [11] | |net_walk() | Consolidation Private| [5], added zoneid argu- | | | | ment, introduced in [11] | | | | | |hook_run() | Project Private | Introduced in [11] | | | | | |__________________________|_______________________|___________________________| PSARC/2006/366 Copyright 2006 Sun Microsystems - 3 - ________________________________________________________________________________ | Interfaces Exported | |__________________________|_______________________|___________________________| |Interface | Classification | Comments | |__________________________|_______________________|___________________________| |platform.xml | Project Private | Introduced in [12] | |__________________________|_______________________|___________________________| The project imports the following interfaces. ____________________________________________________ | Interfaces Imported | |_______________|_______________________|__________| |Interface | Classification | Comments| |_______________|_______________________|__________| |zone_key_create| Consolidation Private| | |_______________|_______________________|__________| 4. Opinion 4.1. zoneadm list The project proposed exposing zone specific information for IP networking from zoneadm list. The IP networking zone con- figuration should be made with dladm show-linkprop and be removed from zoneadm. Some members of the committee were concerned that adding networking specifics to zoneadm list was contrary to any other means (like file systems) of exposing zone specific information. This issue resulted in TCR-1. 4.2. Use of zoneid The net_* functions (net_register, net_lookup, net_walk) require a zoneid argument. We need to raise the stability of the zoneid, as provided by netstackid_to_zoneid(), to Conso- lidation Private. This issue resulted in TCR-2. 4.3. Use of the global zone This project interacts with individual zones as well as the global zone. Portions of the documentation were not specific as to relation to the global zone. This should be clarified in the documentation. 4.4. Future Direction for this project The project as proposed is complete and useful on its own, but substantially duplicates a capability provided by two current virtual machine projects (LDOMS, (FWARC 2005/633), and Xen, (PSARC 2006/260)). PSARC/2006/366 Copyright 2006 Sun Microsystems - 4 - Its promise is greatest as a basis for certain other future capabilities which are not entirely practical in a virtual machine environment, but the project team was insistent dur- ing the review that the future work, while reasonable, was not planned. 4.4.1. Secure observability from the global zone. After a successful attack on a zone, the software in that zone may be compromised in subtle ways, altering the behavior of tools such as "netstat" within that zone. It should be possible to use the global zone's copy of tools such as "netstat" from the global zone to accurately observe kernel state associated with the zone and its stack instance. The project team suggested using mdb, but mdb is not really suitable for this purpose. 4.4.2. Zones vs. virtual machines The committee is concerned that should these follow-on pro- jects not materialize, we will further confuse customers as to the relative applicability of zones vs. virtual machines, and create a maintenance and support burden for the groups working on and near the Solaris IP stack. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project must not use use zoneadm list -l to display IP instances. This function should be added to dladm rather than zoneadm. 2. The netstackid interface and routines that manipu- late it must be Consolidation Private. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material All path names are relative to the case directory (PSARC/2006/366). PSARC/2006/366 Copyright 2006 Sun Microsystems - 5 - 1 Project Specification - final.materials/si- interfaces.pdf 2 manpage - final.materials/dladm.1m.txt 3 manpage - commitment.materials/net_lookup.9f.txt 4 manpage - commitment.materials/net_register.9f.txt 5 manpage - commitment.materials/netstat.1m.txt 6 manpage - commitment.materials/net_walk.9f.txt 7 manpage - commitment.materials/privileges.5.txt 8 manpage - commitment.materials/zoneadm.1m.txt The following PSARC cases are referenced in this opinion, and can be found in the appropriate PSARC case directory: 9 PSARC 2002/174 Virtualization and Namespace Isolation in Solaris 10 PSARC 2002/188 Least privilege for Solaris 11 PSARC 2005/334 Packet Filtering Hooks APIs 12 PSARC 2005/471 BrandZ: Support for non-native zones PSARC/2006/366 Copyright 2006 Sun Microsystems From sacadmin Tue Nov 27 22:25:55 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAS6Ptax009951 for ; Tue, 27 Nov 2007 22:25:55 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lAS6Psbl013293 for ; Tue, 27 Nov 2007 22:25:54 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAS6PmuT015852 for ; Wed, 28 Nov 2007 06:25:48 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JS700101DPKB500@mail-apac.sun.com> (original mail from Donghai.Han@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 28 Nov 2007 14:25:48 +0800 (SGT) Received: from [129.158.219.115] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JS700ES6DUZNFQG@mail-apac.sun.com> for psarc@sac.sfbay.sun.com; Wed, 28 Nov 2007 14:25:47 +0800 (SGT) Date: Wed, 28 Nov 2007 14:25:45 +0800 From: Dong-Hai Han Subject: The contract for 2006/366 Stack instances: Exclusive IP stack per zone (2007/655 IP Instances over Cassini) Sender: Donghai.Han@Sun.COM To: Mehdi Bonyadi , Markus Flierl Cc: psarc@sac.sfbay.sun.com Reply-to: Donghai.Han@Sun.COM Message-id: <474D09E9.2050900@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_6IuytQ1fkuROQytKfHjREQ)" X-Accept-Language: zh-cn User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; zh-CN; rv:1.7) Gecko/20041207 Status: RO Content-Length: 6410 This is a multi-part message in MIME format. --Boundary_(ID_6IuytQ1fkuROQytKfHjREQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello, Mehdi, Markus, Since the new ce driver will be using a consolidation private interface of ON, we need a contract signed by both side, NSN and ON. I have drafted a contract and Seb kindly reviewed it, could you please take a look and if you think everything is OK, could you please sign it by replying my mail? (esp. cc-ing psarc@sac.safbay). Best, Donghai. --Boundary_(ID_6IuytQ1fkuROQytKfHjREQ) Content-type: text/plain; name=contract Content-transfer-encoding: 7BIT Content-disposition: inline; filename=contract @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2006/366-01 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris Consolidation: OS/Networking Department or Group: Solaris Networking Bugster Product/Category/SubCategory: solaris/kernel/gld Responsible Manager: Markus Flierl 3. The CONSUMER is identified by the following: Product or Bundle: cassini driver Consolidation: NSN Department or Group: SSG, NSN Bugster Product/Category/SubCategory: cassini/ethernet_cassini/cassini_sw Responsible Manager: Mehdi Bonyadi 4. The INTERFACES are: Interface name Stability level Comments DLDIOCHOLDVLAN Consolidation Private ioctl to keep a VLAN alive. DLDIOCRELEVLAN Consolidation Private ioctl to release a VLAN. 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing (Exporting) these INTERFACES is: PSARC/2006/366 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: _N_ 7a. Although the stability level doesn't normally restrict it, SUPPLIER promises to only modify INTERFACES in an incompatible way as follows: N/A _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will expose INTERFACES to a PARTNER, which is external to Sun, namely: Name of Company: N/A Name of Department or Group within Company: N/A Responsible Manager: N/A _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. [Paragraph used to mandate notification before interfaces change.] The ioctls DLDIOCHOLDVLAN and DLDIOCRELEVLAN will be changed/removed by project , the corresponding code in ce driver should be changed/removed accordingly, thanks! _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same consolidation, they have the option of arranging for simultaneous conversion to the new interfaces. If this is not possible, or if they are not in the same consolidation, then SUPPLIER will either make best effort to work with CONSUMER so that CONSUMER can detect which version of INTERFACES is being supplied, or else SUPPLIER will make best effort to supply both old and new versions of INTERFACES. If SUPPLIER cannot make both versions of INTERFACES available, and SUPPLIER and CONSUMER cannot devise a method whereby CONSUMER can detect which version of INTERFACES is being supplied, and the old version of CONSUMER will not run with the new version of SUPPLIER, then either the EOL process must be followed by SUPPLIER, or else a major release of SUPPLIER will be required, or the change will not be allowed. 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make best effort to accommodate such changes, which shall then be treated in accordance with paragraph 7 above. 9. Notwithstanding paragraphs 7 and 8, a change to any portion of the INTERFACES shall be regarded as a completely new set of INTERFACES which require both ARC approval and execution of a new contract. 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: Any change to the interfaces requires mutual consent of the SUPPLIER and CONSUMER. If SUPPLIER requires an incompatible change to an interface, SUPPLIER will ensure that existing CONSUMER code still works. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: SUPPLIER agrees that CONSUMER shall have access to any documentation, code samples, or test suites that exist now or are developed later to assist the CONSUMER in using the interfaces. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: The interfaces are documented in the case materials for PSARC/2006/366. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: The CONSUMER shall update the existing test suite for validating the functionality of the interfaces and provide it to the SUPPLIER. The SUPPLIER will run the test suite provided by the CONSUMER. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: This contract can be terminated after mutual signed agreement between SUPPLIER and CONSUMER. 15. This contract is not valid until "signed" via agreement from the SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by this contract. E-mail agreement to the contract should be archived in the mail archive of CASE; verbal agreement to the contract should be noted in the meeting minutes. This contract remains valid until superseded or invalidated. For SUPPLIER: Markus Flierl Date: For CONSUMER: Mehdi Bonyadi Date: For ARC: Sebastien Roy Date: A copy of this contract shall be deposited in the CASE directory as "contract-" or in a "contracts" subdirectory. 16. (Not to be filled in until superseded or invalidated.) This contract was superseded or invalidated by CASE: For ARC: Date: --Boundary_(ID_6IuytQ1fkuROQytKfHjREQ)-- From sacadmin Fri Nov 30 09:46:32 2007 Received: from jurassic.eng.sun.com (jurassic-226-b [129.146.226.130]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAUHkWlp010976 for ; Fri, 30 Nov 2007 09:46:32 -0800 (PST) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAUHkVgV464786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 09:46:31 -0800 (PST) Message-ID: <47504C74.90406@sun.com> Date: Fri, 30 Nov 2007 09:46:28 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.4 (X11/20070723) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com CC: Mehdi Bonyadi , Markus Flierl , Dong-Hai Han Subject: Re: The contract for 2006/366 Stack instances: Exclusive IP stack per zone (2007/655 IP Instances over Cassini) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1102 -------- Original Message -------- Subject: Re: The contract for ce/IP Instances work Date: Fri, 30 Nov 2007 09:38:39 -0800 From: Mehdi Bonyadi To: Markus.Flierl@Sun.COM CC: Donghai.Han@Sun.COM, Erik Nordmark References: <473A8767.2050900@Sun.COM> <473AA017.6020305@sun.com> Sorry for the delay in responding as I thought I had already responded. We reviewed the contract and it is fine with us. Title of the contract: " @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2006/366-01 " Thanks, Mehdi Markus Flierl wrote: > Looks OK to me. > > Markus > > > Dong-Hai Han wrote: >> Hello, Mehdi, Markus, >> >> Since the new ce driver will be using a consolidation private interface >> of ON, we need a contract signed by both side, ON and NSN. >> >> I have drafted a contract, could you please take a look and if you think >> everything is OK, could you please sign it by replying my mail? >> >> Best, >> >> Donghai. >> > > From sacadmin Fri Nov 30 09:52:34 2007 Received: from jurassic.eng.sun.com (jurassic-226-b [129.146.226.130]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAUHqY4q011182 for ; Fri, 30 Nov 2007 09:52:34 -0800 (PST) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAUHqHDg464865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 09:52:23 -0800 (PST) Message-ID: <47504DCE.2000401@sun.com> Date: Fri, 30 Nov 2007 09:52:14 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.4 (X11/20070723) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com CC: Markus Flierl , Mehdi Bonyadi , Dong-Hai Han Subject: Re: The contract for 2006/366 Stack instances: Exclusive IP stack per zone (2007/655 IP Instances over Cassini) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1026 This wasn't cc'ed to the PSARC list, so for completeness of the email record I'm forwarding it to the list. Erik -------- Original Message -------- Subject: Re: The contract for ce/IP Instances work Date: Tue, 13 Nov 2007 23:13:27 -0800 From: Markus Flierl Reply-To: Markus.Flierl@Sun.COM Organization: Sun To: Donghai.Han@Sun.COM CC: Mehdi Bonyadi , Erik Nordmark References: <473A8767.2050900@Sun.COM> Looks OK to me. Markus Dong-Hai Han wrote: > Hello, Mehdi, Markus, > > Since the new ce driver will be using a consolidation private interface > of ON, we need a contract signed by both side, ON and NSN. > > I have drafted a contract, could you please take a look and if you think > everything is OK, could you please sign it by replying my mail? > > Best, > > Donghai. > -- --- Markus Flierl Manager, Solaris Core OS 17 Network Circle Menlo Park, CA 94025 phone: 650-786-2056 http://blogs.sun.com/roller/page/markusflierl From sacadmin Sat Dec 1 13:11:55 2007 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB1LBtoC016385 for ; Sat, 1 Dec 2007 13:11:55 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB1LBthi053419 for ; Sat, 1 Dec 2007 13:11:55 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB1LBoYv004938 for ; Sat, 1 Dec 2007 13:11:50 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSE00H012KY2H00@fe-sfbay-09.sun.com> (original mail from Mehdi.Bonyadi@Sun.COM) for psarc@sac.sfbay.sun.com; Sat, 01 Dec 2007 13:11:50 -0800 (PST) Received: from [129.153.85.32] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSE005HR2VPSC50@fe-sfbay-09.sun.com> for psarc@sac.sfbay.sun.com; Sat, 01 Dec 2007 13:11:50 -0800 (PST) Date: Sat, 01 Dec 2007 13:11:49 -0800 From: Mehdi Bonyadi Subject: Re: The contract for 2006/366 Stack instances: Exclusive IP stack per zone (2007/655 IP Instances over Cassini) In-reply-to: <474D09E9.2050900@Sun.COM> Sender: Mehdi.Bonyadi@Sun.COM To: Donghai.Han@Sun.COM Cc: Markus Flierl , psarc@sac.sfbay.sun.com Message-id: <4751CE15.5010402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <474D09E9.2050900@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 521 We have reviewed this contract and we agree to its terms. It is approved from NSN side. Thanks, Mehdi Dong-Hai Han wrote: > Hello, Mehdi, Markus, > > Since the new ce driver will be using a consolidation private interface > of ON, we need a contract signed by both side, NSN and ON. > > I have drafted a contract and Seb kindly reviewed it, could you please > take a look and if you think everything is OK, could you please sign it > by replying my mail? (esp. cc-ing psarc@sac.safbay). > > Best, > > Donghai. > From sacadmin Mon Dec 3 18:21:47 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB42LlrF015438 for ; Mon, 3 Dec 2007 18:21:47 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lB42LlH2023192 for ; Mon, 3 Dec 2007 18:21:47 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB42Llw8012372 for ; Tue, 4 Dec 2007 02:21:47 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSI006016F82300@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 03 Dec 2007 19:21:47 -0700 (MST) Received: from [192.168.1.3] ([72.93.210.146]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSI000SA6KALO20@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Mon, 03 Dec 2007 19:21:46 -0700 (MST) Date: Mon, 03 Dec 2007 21:21:45 -0500 From: Sebastien Roy Subject: Re: The contract for 2006/366 Stack instances: Exclusive IP stack per zone (2007/655 IP Instances over Cassini) In-reply-to: <4751CE15.5010402@sun.com> Sender: Sebastien.Roy@Sun.COM To: Mehdi Bonyadi Cc: Donghai.Han@Sun.COM, Markus Flierl , psarc@sac.sfbay.sun.com Message-id: <4754B9B9.2040003@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <474D09E9.2050900@Sun.COM> <4751CE15.5010402@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 320 Mehdi Bonyadi wrote: > We have reviewed this contract and we agree to its terms. It is approved > from NSN side. Both supplier and consumer have signed the contract. I've place a copy of the contract as "contract-01" in the 2006/366 case directory, with a symbolic link to the 2007/655 case directory Thanks, -Seb