Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0AKQfIQ022374 for ; Tue, 10 Jan 2006 12:26:41 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k0AKQa724576; Tue, 10 Jan 2006 12:26:36 -0800 (PST) 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 <0ISW00C018SA3M00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jan 2006 12:26:34 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0ISW007H78S90Z50@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jan 2006 12:26:33 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.175.66]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0AKQWTe012091; Tue, 10 Jan 2006 12:26:32 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0AKQWIQ022369; Tue, 10 Jan 2006 12:26:32 -0800 (PST) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id k0AKQWiP022368; Tue, 10 Jan 2006 12:26:32 -0800 (PST) Date: Tue, 10 Jan 2006 12:26:32 -0800 (PST) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/471 BrandX Support for non-native zones To: PSARC@sun.com Cc: Nils.Nieuwejaar@sun.com, PSARC-coord@sun.com Message-id: <200601102026.k0AKQWiP022368@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.1.222179 Status: RO Content-Length: 473 New Materials submitted for PSARC 2005/471 BrandX Support for non-native zones Status: inception scheduled 01/18/2006 Files: /shared/sac/PSARC/2005/471/inception.materials/20_questions /shared/sac/PSARC/2005/471/inception.materials/design_doc.pdf /shared/sac/PSARC/2005/471/inception.materials/zoneadm.1m /shared/sac/PSARC/2005/471/inception.materials/zonecfg.1m /shared/sac/PSARC/2005/471/inception.materials/zones.5 Please let me know if you have questions. - PSARC From sacadmin Wed Jan 18 11:13:58 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0IJDwIQ028375 for ; Wed, 18 Jan 2006 11:13:58 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ITA00H01Y7V5E@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 18 Jan 2006 11:13:57 -0800 (PST) Received: from [129.146.108.175] (scharffenberger.SFBay.Sun.COM [129.146.108.175]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ITA00AK6YR3Z7@mpk-mail1.sfbay.sun.com>; Wed, 18 Jan 2006 11:13:51 -0800 (PST) Date: Wed, 18 Jan 2006 11:13:55 -0800 From: Ed Gould Subject: PDF of Design Doc for PSARC/2005/471 To: Nils Nieuwejaar Cc: psarc@sac.sfbay.sun.com, Sherri Shieh Message-id: <43CE9373.1030006@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051206 Status: RO Content-Length: 496 Nils, I'm sorry to have noticed this so late (and I'm a bit surprised no one else did, either), but the PDF of the design document for BrandZ in the PSARC case directory is flawed. Specifically, there is text at the right margin that is truncated, in many places throught he document. I can mostly extrapolate to understand what the text says, but please replace this file with a correct one (rather, send it to me or Sherri, as I don't expect you have permission to replace it). --Ed From sacadmin Wed Jan 18 11:56:16 2006 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0IJuGIQ029654 for ; Wed, 18 Jan 2006 11:56:16 -0800 (PST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.5+Sun/8.13.5) with SMTP id k0IJuGwd012858; Wed, 18 Jan 2006 11:56:16 -0800 (PST) Message-Id: <200601181956.k0IJuGwd012858@ivrel.sfbay.sun.com> Date: Wed, 18 Jan 2006 11:56:16 -0800 (PST) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: PDF of Design Doc for PSARC/2005/471 To: psarc@sac.sfbay.sun.com Cc: Sherri.Shieh@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dBCJb/b8R4+O5NRdRfQkog== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 820 Date: Wed, 18 Jan 2006 11:13:55 -0800 From: Ed Gould Subject: PDF of Design Doc for PSARC/2005/471 I'm sorry to have noticed this so late (and I'm a bit surprised no one else did, either), but the PDF of the design document for BrandZ in the PSARC case directory is flawed. Specifically, there is text at the right margin that is truncated, in many places throught he document. I can mostly extrapolate to understand what the text says, but please replace this file with a correct one (rather, send it to me or Sherri, as I don't expect you have permission to replace it). In the interim, an HTML version of the document is available as ; this version doesn't have the margin problem. -- Glenn From sacadmin Wed Jan 18 12:06:08 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0IK68IQ029795 for ; Wed, 18 Jan 2006 12:06:08 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k0IK66S07844; Wed, 18 Jan 2006 12:06:06 -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 <0ITB0090D165NQ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Jan 2006 12:06:05 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.106.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0ITB00H3O164YAF0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Jan 2006 12:06:04 -0800 (PST) Received: from [129.150.26.21] (vpn-129-150-26-21.SFBay.Sun.COM [129.150.26.21]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k0IK63Uf882632; Wed, 18 Jan 2006 12:06:04 -0800 (PST) Date: Wed, 18 Jan 2006 12:05:57 -0800 From: Sherri Shieh Subject: Re: PDF of Design Doc for PSARC/2005/471 In-reply-to: <20060118195643.GF113509@east.sun.com> To: Nils Nieuwejaar Cc: Ed Gould , psarc@sun.com Reply-to: sherri.shieh@sun.com Message-id: <43CE9FA5.9040607@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.1.222179 References: <43CE9373.1030006@Sun.COM> <20060118195643.GF113509@east.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: 1795 All, This new document has been put into the case directory: -rw-rw-r-- 1 ss146556 sac-2 2126216 Jan 18 12:04 design_doc.ps - Sherri ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, Systems Architecture Sun Microsystems, Inc. Phone: 650-786-5245/x85245 Email: Sherri.Shieh@sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nils Nieuwejaar wrote: >Sorry about that. The design doc is coming from the OpenSolaris web site, >so I'm converting from .html to .ps and from .ps to .pdf. It appears that >the truncation is coming in the second part of that translation. > >In the interest of time, I am sending the .ps file instead of trying to >figure out the magic to generate a correct .pdf file. > >Sorry again, > Nils > >On Wed 01/18/06 at 11:13 AM, Ed.Gould@Sun.COM wrote: > > >>Nils, >> >>I'm sorry to have noticed this so late (and I'm a bit surprised no one >>else did, either), but the PDF of the design document for BrandZ in the >>PSARC case directory is flawed. Specifically, there is text at the >>right margin that is truncated, in many places throught he document. I >>can mostly extrapolate to understand what the text says, but please >>replace this file with a correct one (rather, send it to me or Sherri, >>as I don't expect you have permission to replace it). >> >> --Ed >> >> From sacadmin Wed Jan 18 12:10:21 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0IKALIQ029813 for ; Wed, 18 Jan 2006 12:10:21 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k0IKALS09808 for <@sunmail2.sfbay.sun.com:psarc@sun.com>; Wed, 18 Jan 2006 12:10:21 -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 <0ITB00A0H1D81D00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 18 Jan 2006 12:10:20 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0ITB00HS61D8XRE0@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 18 Jan 2006 12:10:20 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0IKAImT013247; Wed, 18 Jan 2006 12:10:18 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k0IK8M4o026297; Wed, 18 Jan 2006 12:08:22 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k0IK8MUq026296; Wed, 18 Jan 2006 12:08:22 -0800 (PST) Date: Wed, 18 Jan 2006 12:08:22 -0800 (PST) From: Gary Winiger Subject: Re: PDF of Design Doc for PSARC/2005/471 To: nils.nieuwejaar@sun.com, sherri.shieh@sun.com Cc: Ed.Gould@sun.com, psarc@sun.com Message-id: <200601182008.k0IK8MUq026296@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.1.1.222179 Status: RO Content-Length: 147 > This new document has been put into the case directory: > > -rw-rw-r-- 1 ss146556 sac-2 2126216 Jan 18 12:04 design_doc.ps Still broken From sacadmin Wed Jan 18 12:30:25 2006 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0IKUOIQ000259 for ; Wed, 18 Jan 2006 12:30:24 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0IKUOmT021874; Wed, 18 Jan 2006 12:30:24 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k0IKSSit026413; Wed, 18 Jan 2006 12:28:28 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k0IKSPNc026412; Wed, 18 Jan 2006 12:28:25 -0800 (PST) Date: Wed, 18 Jan 2006 12:28:25 -0800 (PST) From: Gary Winiger Message-Id: <200601182028.k0IKSPNc026412@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com, glenn@ivrel.sfbay.sun.com Subject: Re: PDF of Design Doc for PSARC/2005/471 Cc: Sherri.Shieh@Sun.COM X-Sun-Charset: US-ASCII Status: RO Content-Length: 300 > In the interim, an HTML version of the document is available as > ; this version > doesn't have the margin problem. I've converted this to PDF and dropped it in the case directory as BrandZ.pdf. It is now formatted to fit on a page. Gary.. From sacadmin Wed Jan 18 12:50:00 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0IKnxIQ000614 for ; Wed, 18 Jan 2006 12:49:59 -0800 (PST) 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 k0IKntpb009046 for <@sunmail2.sfbay.sun.com:psarc@Sun.COM>; Thu, 19 Jan 2006 04:49:58 +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 <0ITB00D0Z3788P00@nwk-avmta-1.sfbay.Sun.COM> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Wed, 18 Jan 2006 12:49:56 -0800 (PST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0ITB00AQY377IW40@nwk-avmta-1.sfbay.Sun.COM> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Wed, 18 Jan 2006 12:49:56 -0800 (PST) Received: from negril.East.Sun.COM (negril.East.Sun.COM [129.148.183.104]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0IKnrWa023302; Wed, 18 Jan 2006 15:49:53 -0500 (EST) Received: from negril.East.Sun.COM (localhost [127.0.0.1]) by negril.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k0IKnqSe113978; Wed, 18 Jan 2006 15:49:52 -0500 (EST) Received: (from nn35248@localhost) by negril.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k0IKnqBk113977; Wed, 18 Jan 2006 15:49:52 -0500 (EST) Date: Wed, 18 Jan 2006 15:49:52 -0500 From: Nils Nieuwejaar Subject: Re: PDF of Design Doc for PSARC/2005/471 In-reply-to: <200601182008.k0IK8MUq026296@marduk.eng.sun.com> To: Gary Winiger Cc: Nils.Nieuwejaar@sun.com, Sherri.Shieh@sun.com, Ed.Gould@sun.com, psarc@sun.com Message-id: <20060118204952.GH113509@east.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.1.1.222179 References: <200601182008.k0IK8MUq026296@marduk.eng.sun.com> User-Agent: Mutt/1.4.2i Status: RO Content-Length: 452 On Wed 01/18/06 at 12:08 PM, gww@eng.sun.com wrote: > > > This new document has been put into the case directory: > > > > -rw-rw-r-- 1 ss146556 sac-2 2126216 Jan 18 12:04 design_doc.ps > > Still broken Could you be more specific? I have looked at the .ps with ggv and I have a printout in front of me. Both appear to be fine. Could you point to a particular page, section, or table that is broken, so I can look into it? Thanks, Nils From sacadmin Wed Jan 25 10:41:38 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PIfbIQ015688 for ; Wed, 25 Jan 2006 10:41:38 -0800 (PST) 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 k0PIfEhq017877; Thu, 26 Jan 2006 02:41:32 +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 <0ITN0011FVX51S00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jan 2006 10:41:29 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.104.45]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0ITN00FMIVX4L330@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jan 2006 10:41:28 -0800 (PST) Received: from sun.com (sr1-umpk-01.SFBay.Sun.COM [129.146.11.151]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k0PIfSop296571; Wed, 25 Jan 2006 10:41:28 -0800 (PST) Date: Wed, 25 Jan 2006 10:41:28 -0800 From: Sherri Shieh Subject: PSARC Meeting Minutes 01/18/2006 Inception: 2005/471 To: psarc@sun.com, Nils Nieuwejaar , Russell Blaine Message-id: <43D7C658.4050100@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_vvJa+Zh8RaYnKJH8DzfzLg)" X-Accept-Language: en-us, en X-PMX-Version: 5.1.1.222179 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 Status: RO Content-Length: 17854 This is a multi-part message in MIME format. --Boundary_(ID_vvJa+Zh8RaYnKJH8DzfzLg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT All, Meeting minutes from 01/18/2006 are now available and attached. Audio files are available as well: (1) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060118.arcbiz.mp3 (2)http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060118.2005.471.inception.mp3 Sum up available at: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060118.html If you have 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_vvJa+Zh8RaYnKJH8DzfzLg) Content-type: text/plain; name=20060118 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=20060118 SYSTEM ARCHITECTURE COUNCIL Platform Software ARC --------------------------------- PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 01/18/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 Andy Rudoff: no (on sabbatical) James Carlson: yes Shudong Zhou: yes Bill Sommerfeld: yes Gary Winiger: yes Tim Marsland: no (on sabbatical) Ed Gould: yes David Robinson no (on sabbatical) 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) Kais Belgaied: yes 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 Guests: Nils Nieuwejaar Bill Aucharski Ed Polatowitz Russ Blaine --------------------------------------------------------------------------- AGENDA ------- 01/18/2006 (late afternoon mtg - will start at 4pm PDT, Gary, Calum out) 4:00-4:10 project id - need owner/intern for: Solaris for OPL (2004/750), inception scheduled 02/01/2006 4:10-4:20 ARC Business - escalating issues 4:20-5:05 Inception: BrandX: Support for non-native zones (2005/471) Submitter: Nils Nieuwejaar Owner: Ed Gould Intern: Alan Hargreaves --------------------------------------------------------------------------- Case Anchors: 1) case 1: BrandX: Support for non-native zones (2005/471)
=========================================================================== ARC BUSINESS -------------- Fast tracks ----------- 2006/017 Arp Single Entry Display James Carlson waiting fast-track 01/19/2006 James Carlson * Approved 2006/018 cdb length capability Peter Dunlap waiting fast-track 01/19/2006 Eric Taylor * Approved 2006/019 OpenSSL upgrade to 0.9.8a Jen Pechanec waiting fast-track 01/23/2006 Darren Moffat * Approved Other Business --------------- * needing intern/owner Inception: Solaris for OPL (2004/750) Submitter: Johnny Hui Owner: Jim Carlson Intern: Kais Belgaied * Escalating issues? - none for this week ============================================================================== Inception: BrandX: Support for non-native zones (2005/471) Submitter: Nils Nieuwejaar Owner: Ed Gould Intern: Alan Hargreaves SUMMARY ======= * Need spec - Full list of things that will keep this project from being LSB compliant. * Need spec - List what features are not going to work and what are. * Admin issues - More precise boundaries of what you can do and what you cannot do would be better for everyone to understand (list apps for example or a one paragraph explanation) * Man page clarification for wes-3 * Need spec - list how system calls work * fix the init(1M) invocation * ARC members: go back and take a look into the Janus case again ISSUES ======= wes-1 20q9: can you explain in a little more detail how the brand-specific hooks in mdb are plugged in? do you have to run mdb in a solaris-branded zone or a linux-branded zone? if the latter, how does it coexist? if the former, how does it figure out which brand library to load? * mdb would only run under Solaris brand but others can run Solaris to run mdb. - This should be documented as well in what works and what doesn't wes-2 brandz zones and networking: will there be any supported/documented configuration which works in cases where the system (e.g., standalone developer's laptop using typical ISP) only has one externally reachable ip address? (alternatives here include sharing ip address & port space with global zone; NAT; ...?) * This would be able to show you how to run and be supported in the global zone. * If this was a commitment review, Advice to the PAC - support for global zone wes-3 non-solaris zones, smf, and zoneadm boot -s? "Boots only to milestone svc:/milestone/single-user:default" if the lx zone doesn't have SMF, ??? or are you making the lx brand bits SMF-aware? * Booting a linux zone usually works. This may be a man page clarification. wes-4 NIT: zonecfg(1m) starts with a list of properties. I would have expected to see (global) brand in there. wes-5 NIT: zonecfg(1m): I would expect to see an example of setting "brand" wes-6 NIT: zones(5): "The software may include Solaris software configured our laid out differently" s/our/or/ ? wes-7 NIT: zonecfg(1m) doesn't document the "create -B brand" syntax found in design_doc.pdf page 1 wes-8 NIT? design_doc.pdf page 2: %Z or %R for zone root path? * Project team will check this. wes-9 design_doc.pdf page 4: when to run "preboot" is obvious, but how does the framework know when to run "postboot" - i.e., what event in the zone boot sequence triggers it and what is the postboot script guaranteed is set up? * This has been changed to a single boot - there is no pre-boot and post boot. wes-10 design_doc.pdf 2.1.5: interposing on kill may not be sufficient (e.g., kernel-originated signals?) * Project team will go back and look at this. This should also be documented. wes-11 design_doc.pdf page 5 (and perhaps elsewhere): text is clipped on the right end of the line? I think I can guess what it's saying but can't be sure.. * This has already been fixed. wes-12 design_doc.pdf page 6: "it again demonstrates that the ability for third parties to develop radically new brands will be limited"? unless they use the opensolaris dev process to request integration, right? * People can develop and send it to the project team if needed. gcs-0) transition from Janus: How does this project address the deficiencies noted in the Janus opinion? What does it give up that Janus provided? (And I assume that the intent is to have this project supercede Janus -- right?) * The project team is based on the zone model right now. What the project team loses through this is running Linux and Solaris running zones side by side. The project team does own these zones. There will be some stuff not accessible such as D-Trace inside the zone. gcs-0a) messiness and incompleteness of emulation: How will we know that the emulation is good enough? When something doesn't work, how will support be handled? (Does the design include provisions for helping assign blame?) * When something doesn't work, there will be a log message if something doesn't work or is not supported. If for some reason there is a feature that is not supported, again there will be a message displayed. * The project team is running a bunch of Linux applications and trying to be LSB compliant. However, there are things that run on LSB that does not run on Linux. The source is opened to the community (OpenSource) and so the code is public. gcs-0b) administration issues: Sketch out how attempts to use Linux administrative tools in a lx-brand zone will play out. What will work? What won't? * Anything that doesn't try to touch real hardware should work. - ping does however work in the zone (project team will go and look into this) - More precise boundaries of what you can do and what you cannot do would be better for everyone to understand (list apps for example or a one paragraph explanation) gcs-1) brand-specific librtld_db.so: delivered in brand-specific package? Installed where? (If in the branded zone itself, is there risk of conflict with a native file of the same name?) * Already discussed. gcs-2) emulating complex system calls (section 3.4.3): So how _are_ they emulated? Do you introduce new (non-branded, native Solaris) system calls and do the dirty work in the kernel? * This might not be embedded in the design document right now. The project team is introducing a single system call. - What kind of machinery, etc. should be listed...otherwise it will be hard to find out how this is working gcs-3) interface table is way too sketchy; will need to be fleshed out for commitment (e.g., uucopy() isn't mentioned in it, but should be). gcs-4) returning from signals (section 3.6.2): Are you saying that non-branded Solaris processes will experience a change in behavior due to changing how %gs is restored? If so, is there any way to avoid the change? * If this is a bug fix, then it needs to be explained as well. eg-0 There are several places in the design where the authors are vague about actual Linux behavior. Should we expect further inception review(s) as these details are investigated? * Nils: I don't think so - it might just be text that is lingering that needs to be cleaned up perhaps. However, where ever possible we track down where Linux is running but we cannot look at that code so this is how we document what it may be doing. - Possible chance to ask externally about what Linux is doing? - Tracking down what Linux could be doing regarding this project will be better eg-1 20q6 It strikes me as folly to integrate only the x86/x64 code. How can we ensure that the SPARC code actually works, and continues to work, if nothing is integrated with which to test it. There may be a business case that says not to support this functionality, but it does not seem architecturally sound to leave it out. * Nils: If we put back the SPARC code, it is potentially dead code. This is more or less frowned upon. If the ARC would like us to put back SPARC support, we'd be willing to do that. * In the kernel nothing is 32 specific. Basically, a tiny fraction is 32 specific. * More information is needed here eg-2 20q10 Why is a non-Linux tool being introduced into a Linux zone? Shouldn't everything inside that zone just be Linux? * ptchmod is an existing tool in Solaris right now. NFS is working right now but locking doesn't. eg-3 20q15 The answer suggests that multiple versions of the Linux syscall interface will *not* be supported. Does this mean that users may not retain an old version of a Linux zone if a Solaris update contains a newer Linux interface? Doesn't this put customers into an unnecessary bind? (Consider NetBSD - it has compatibility with all previous syscall versions, back to the start of [its] time.) * It might be a suggestion to do your system call early. [observation from sommerfeld: actually, NetBSD's compatibility is via kernel-compile-time options -- COMPAT_x for various values of x -- which on solaris are typically handled via boot-time or run-time configiration]. eg-4 Design 2.1.5 Why not just fix the init(1M) invocation now? Without knowing the details, I would expect it to be fairly easy to do, and not doing so leaves a large hole in the architecture. Also, does Linux auto-reboot when it discovers that init has died? BSD systems do. * The project team can make the change if needed right now. eg-5 Design 2.2.1 The new struct brand appears to contain enough information to support multiple versions of a given brand simultaneously, yet the text seems to forbid this. Why? Isn't the (name, version) pair sufficient to identify the underlying implementation? * Already discussed eg-6 Design 3.5.1 What happens if a Linux process calls clone() with an unsupported set of flags? * 2 of the 4 are supported and should be detailed. eg-7 Design 3.7.1.1 The text suggests that the investigation of actual Linux behavior is incomplete. Is the proposed model that networking should work from a branded zone, but control of network devices (including such things as IP address assignment), using branded tools, will not? * Already discussed eg-8 Design 3.7.3.1 Does the driver name-to-major mapping ever need to be redone at Solaris boot? * This is checked dynamically when needed. the checking can be done any time. - Doc should be cleaned up to specifically say when it it is redone. eg-9 Design 3.7.4 Is /dev/null really write only in Linux? It has always been read-write in Unix (with read returning EOF). * This will be changed. eg-10 Design 3.7.5.3 There are uses of /dev/fd other than in shell scripts. One common use is on the command line, when a program does not, by default or conventional argument (e.g., "-"), read standard input. It can then be invoked with an explicit /dev/fd/0 argument. * This should be included in the design doc. eg-11 Design 3.7.5.4 What if a branded zone wants access to multiple sound devices? Is the proposed mechanism extensible in that way? * You can only have one audio device in the zone. We cannot support more than one audio device in a zone. You would need to create another zone for more than one. eg-997 Design 3.8.2 (typo) Email cruft ">From ..." eg-998 Design 3.8.1 (nit) Note that multi-threaded debugging in Linux has frequently been broken, and may be broken now. It will undoubtedly break again in the future. eg-999 Design 3.7.5.2 (typo) "user and" -> "userland" dwc-1 20Q, Q1, "By what criteria will you judge its success?" & Q17 I see no reference to the LSB in your materials. Shouldn't we require that the LSB test suites pass in an lx branded zone? * Already discussed. dwc-2 NIT: zones(5): Brands heading: 1st paragraph "configured our laid" -> "configured or laid" kb-1 The name "lx" leads to believe this is a generic brand for Linux. Yet it seems that what the project id delivering is a brand specific to Red Hat Entreprise Linux 3. So, will future brands for other flavors of Linux also be named 'lx' and differentiated with the int b_version? * The brand name is "lx". You could probably support RedHat 3 and 4 using the same brand but not quite sure right now. The next release of Red Hat might have the same brand name but again, it could change. - There has been no pushback from marketing about using the word "brand" in naming things. The project team has already gotten sign off from marketing and from legal on this. kb-2 About section 2.2.1 "The b_version number is currently used to determine whether the brand is eligible to be loaded into the system. If the version number doesn't match the one compiled into the kernel, then we simply refuse to load the band module" Any way to know up front the (list of) brand(s) that a the kernel has built0in support for? I'm thinking about the case where I want to order new brand modules or newer versions of the lx, and want to know beforehand if they'll get installed sucessfully or not. * The project team will this about this. kb-3 I am not clear on the upgrade model and constraints for applications running within a BrandZ emulated environemnt. Example, say I set up an 'lx' band (based on RHEL 4) in a zone, and install a few applications there, and deploy that in production and populate some state in that zone. Later, I need to upgrade one of the application, and the new version would nornally requires an OS upgarde to RHEL 5. In a non-BrandZ enviroenment it is just an OS upgrade, everything is expected to be compatble. For a BrandZ environement, how would I achive that upgrade, given the fact that a zone's brand cannot be changed (according to section 2.1.1 Configuration) ? * We do not intend to upgrade Linux and zones. Nothing like a live upgrade will be done. * Maybe a best practice doc should be written up about this issue from the Linux point of view. gw-1 Nit: please communicate with the Layered Trusted Solaris team (PSARC/2002/762). There seems to be overlap in zoneadm and zonecfg. Perhaps this case's architecture of config.xml is also applicable there. Contact Glenn Faden. gw-2 Would it be useful to extend ucred to return the brand? Would a network or door server ever be interested? * Project team will think about this. On white board: --------------- eg-12 syscall vector * Tied with eg-3 NEXT STEP ========= * Project team will go back and resolve all issues from today's review. --Boundary_(ID_vvJa+Zh8RaYnKJH8DzfzLg)-- From sacadmin Tue May 9 19:39:18 2006 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 k4A2dHFb009656 for ; Tue, 9 May 2006 19:39:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k4A2dE9v021262; Wed, 10 May 2006 03:39:15 +0100 (BST) 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 <0IZ100G013DDEH00@nwk-avmta-2.sfbay.sun.com>; Tue, 09 May 2006 19:39:13 -0700 (PDT) Received: from sac.sfbay.sun.com ([129.146.175.66]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IZ1007T93DD9WD0@nwk-avmta-2.sfbay.sun.com>; Tue, 09 May 2006 19:39:13 -0700 (PDT) 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 k4A2dD23009645; Tue, 09 May 2006 19:39:13 -0700 (PDT) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id k4A2dDX3009644; Tue, 09 May 2006 19:39:13 -0700 (PDT) Date: Tue, 09 May 2006 19:39:13 -0700 (PDT) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/471 BrandZ Support for non-native zones To: PSARC@sun.com Cc: Nils.Nieuwejaar@sun.com, PSARC-coord@sun.com Message-id: <200605100239.k4A2dDX3009644@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 894 New Materials submitted for PSARC 2005/471 BrandZ Support for non-native zones Status: commitment scheduled 05/17/2006 Files: /shared/sac/PSARC/2005/471/commitment.materials/20_questions /shared/sac/PSARC/2005/471/commitment.materials/brand.dtd.1 /shared/sac/PSARC/2005/471/commitment.materials/brands.5 /shared/sac/PSARC/2005/471/commitment.materials/design.pdf /shared/sac/PSARC/2005/471/commitment.materials/inception_issues /shared/sac/PSARC/2005/471/commitment.materials/lx.5 /shared/sac/PSARC/2005/471/commitment.materials/onepager /shared/sac/PSARC/2005/471/commitment.materials/what_works /shared/sac/PSARC/2005/471/commitment.materials/zone_platform.dtd.1 /shared/sac/PSARC/2005/471/commitment.materials/zoneadm.1m /shared/sac/PSARC/2005/471/commitment.materials/zonecfg.1m /shared/sac/PSARC/2005/471/commitment.materials/zones.5 Please let me know if you have questions. - PSARC From sacadmin Tue May 23 09:19:33 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 k4NGJRbn024535 for ; Tue, 23 May 2006 09:19:32 -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 k4NGJ28J011593 for <@sunmail2.sfbay.sun.com:psarc@sun.com>; Wed, 24 May 2006 00:19:26 +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 <0IZQ0090L80BJM00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Tue, 23 May 2006 09:19:23 -0700 (PDT) Received: from nwkea-pix-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IZQ00M7X80AW2F0@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Tue, 23 May 2006 09:19:22 -0700 (PDT) Received: from d1-sfbay-02.sun.com ([192.18.39.112]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4NGJMba012470 for ; Tue, 23 May 2006 09:19:22 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-02.sun.com by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZQ00F017M0C200@d1-sfbay-02.sun.com> (original mail from Sherri.Shieh@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Tue, 23 May 2006 09:19:22 -0700 (PDT) Received: from [129.146.11.181] by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZQ006FB809UX40@d1-sfbay-02.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Tue, 23 May 2006 09:19:22 -0700 (PDT) Date: Tue, 23 May 2006 09:19:21 -0700 From: Sherri Shieh Subject: PSARC Meeting Minutes 05/17/2006 Commitment: 2005/471; Presentation: Crossbow Sender: Sherri.Shieh@sun.com To: psarc@sun.com, James McPherson , Nils Nieuwejaar , Shawn.Emery@sun.com, Mark.Phalan@sun.com, Jan.Pechanec@sun.com Message-id: <44733609.3040409@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_cw1KimgZA8PI19WIK8XAUA)" X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 18874 This is a multi-part message in MIME format. --Boundary_(ID_cw1KimgZA8PI19WIK8XAUA) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT All, Meeting minutes from 05/17/2006 are now available and are attached. Audio files are also available: (1) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060517.arcbiz. mp3 (2) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060517.2005.471.commitment.mp3 More notes: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060517.2005.471.commitment.alan (3) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060517.crossbow.preso.mp3 Sum up available at: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060517.html If you have any feedback/corrections, 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_cw1KimgZA8PI19WIK8XAUA) Content-type: text/plain; name=20060517.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=20060517.txt SYSTEM ARCHITECTURE COUNCIL Platform Software ARC --------------------------------- PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 05/17/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: yes (on sabbatical) Glenn Skinner: yes Robert Berube no Andy Rudoff: no (on sabbatical) James Carlson: yes Shudong Zhou: yes Bill Sommerfeld: yes Gary Winiger: yes Tim Marsland: no (on sabbatical) Ed Gould: yes David Robinson no (on sabbatical) 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) Kais Belgaied: yes Phil Harman: no Calum Mackay yes Michael Speer no Ienup Sung no Cecilia Hu: no Brian Utterback no Michael Haines no Sebastien Roy no Alan Hargreaves yes Guests: Allan Perry James McPherson Nils Nieuwejaar Will Sean Emery Mark Phalan Jan Pechanec --------------------------------------------------------------------------- AGENDA ------- 05/17/2006 10:00-10:10 project id 10:10-10:20 ARC Business 10:20-11:05 Commitment: BrandZ: Support for non-native zones (2005/471) Submitter: Nils Nieuwejaar Owner: Ed Gould 11:05-11:50 Presentation: Crossbow - Network Virtualization and Resource Management Submitter: Kais Belgaied --------------------------------------------------------------------------- Case Anchors: 1) case 1: BrandZ: Support for non-native zones (2005/471)
2) case 2: Presentation: Crossbow - Network Virtualization and Resource Management
=========================================================================== ARC BUSINESS -------------- Fast tracks ----------- 2006/288 zpool history Eric Kustarz waiting fast-track 05/12/2006 Mike Shapiro * Approved last week 2006/303 ZFS Clone Promotion Matt Ahrens waiting fast-track 05/12/2006 Jeff Bonwick * Approved last week 2006/308 ZFS list sort option Sarah Jelinek waiting fast-track 05/16/2006 Sarah Jelinek * Approved last week 2006/313 NFSv4: nfsd "-s" distributed stable stor Calum Mackay waiting fast-track 05/17/2006 Calum Mackay * Approved 2006/320 Host-based LUN Masking John Forte waiting fast-track 05/23/2006 Paul von Behren * let it run 2006/321 ARP packet filtering Hooks Darren Reed waiting fast-track 05/23/2006 Kais Belgaied * more time Other Business -------------- * fasttrack license for Tim Haley - request from the FMA grouop to get a couple of fast track lincensees - add him to the alias and a greeting message * Alan.Hargreaves: Vote on PSARC/2005/573 Solaris Trusted Extensions for Printing - call for a vote: yes: gary, shudong, ed, bill, jim no: abstain: NP: glenn, joek Final vote was approved. - A draft opinion will be sent out with the formal vote. Escalating Issues ----------------- ============================================================================== Commitment: BrandZ: Support for non-native zones (2005/471) Submitter: Nils Nieuwejaar Owner: Ed Gould Intern: Alan Hargreaves SUMMARY ======= * Advice to the project team: brand.dtd.1 - there might be something simpler for this issue * /opt/sfw/bin/lxrun: make this a seperate fast track * Strongly advise: make /opt/sfw/bin/lxrun go away ISSUES ====== jdc-0 What's changed since inception? * Everything that has changed is in the issues from inception. jdc-1 What exactly does the name "lx" mean? I'm worried we're headed into a confusing forest of "lx-ubuntu" and "lx-2.6" (i.e., both distribution-based and kernel version based brands) in the future. * The project team chose LX instead of Linux - it seemed unwise to choose Linux to be named in the branding. LX is the team's way of delivering Linux support. * Suggestion: remove the what the future is out of the design doc - should at least mention the concern of the future in the document jdc-2 What's the point to supporting RHEL3 and the 2.4 kernel? It seems that RHEL3 is several years out of date and 2.6 is pretty far along. RHEL3 is older than FC0.94, and they're on FC5 now. jdc-3 glibc-2.3.2 is old and still has executable stacks (potential security problem). More importantly: what do we (or don't we) tell customers about the security of BrandZ-hosted Linux on Solaris? jdc-4 Are users dependent on reading ext[23]fs data? How usable is migration without file system support? What else is missing if we want people to migrate? * Supporting linux file systems is not on the roadmap and project team has made it clear to customers. This doesn't seem to be a huge obstacle about having to deal with migration for Linux. jdc-5 Is the "s10" brand included in this project the right architectural direction to take the system, and has the Zones team been involved in this decision? Could we ever really support old releases in zones? (And can't and don't users _already_ do this more simply by hacking uname?) (Merely changing the uname value and calling it an "s10 branded zone" seems like a dangerous bait-and-switch to me.) * The S10 brand is only designed for testing. This isn't going to be sent to customers whatsoever. This is not a real Solaris 10 environment (won't be shipped). jdc-6 For the system calls that are missing, do we have an idea of what might be affected? (Have we done searches?) In particular, what Linux things are broken by lack of chroot support? jdc-7 20q9: truss and apptrace aren't mentioned here. If mdb understands brands, should dbx also understand them? * nits - truss has been updated and appt race will soon. jdc-8 Mdb's kernel-space dcmds (e.g., ::ps, ::pgrep, and ::threadlist) should probably be enhanced to understand brands. * nits jdc-9 Is there an Install-related project on which this one depends, or does this project also deliver the necessary Install changes to skip over branded zones? (If it's the latter, then zonecfg_get_brand() is probably Contracted.) * Live upgrade doesn't run zones. The packaging pack tools will go into the install gate. There is an RFE file that the project team and link to this PSARC case. As for live upgrade, the p-team doesn't know what to do about that right now. (ARC is talking about Zulu) jdc-10 Now that there are entries in zone_platform.dtd.1 for the various mounts and links that need to be created, can the hard-coded lists in zoneadmd be refactored into these more flexible files? (If that's not this project, then there's probably advice here to create one so that the result is a complete design.) * The hard coded device names will be made into the flexible files. jdc-11 What does TIOCSETLD actually do on Solaris? (Shouldn't that be TIOCSETD rather than TIOCSETLD? The latter doesn't appear to be in the Linux kernel sources, but 20q mentions the former.) How can line disciplines be used on a STREAMS-based system? * This should be put into the interface table... jdc-12 Audio support seems clumsy. Why is a separate attr needed? Doesn't export of /dev/dsp to the zone imply that audio is accessible? If attributes are needed, shouldn't they be part of the device import? * Please talk to the trusted Solaris team about the audio issue. jdc-13 20q19: this project is probably strictly dependent on integrating rpm into the WOS. (The SPARC question here looks like a marketing or business issue, but I think it'd look bad to customers if we didn't even support our own products.) * The project team is using the exisiting linux version of the RPM. jdc-14 nit:20q13: this case _exports_ the things listed in the import table. jdc-15 design?:nit?:brand.dtd.1: why are there function names here? Why not just specify a particular shared library interface that all brand libraries must implement -- just like the _init/_fini/_info functions used by kernel modules? And why have the name of the shared object here? Why not just have both verify() and validate() in the same object with some well-known (brand-name-based) file name? (There are a lot of degrees of freedom here, and it looks like a lot of them lead to accidents.) * Advice to the team - there might be something simpler here.... jdc-16 What is the behavior of cloning if no post-clone script is present? jdc-17 Does /opt/sfw/bin/lxrun go away? * EOL? * Make this a sperate fast track gcs-5 Section 3.7.4 (Device minor nodes and paths): Trails off into "If we decide to do this, then...". What specifically do you plan to deliver? (That is, reword the spec to clarify the boundary between this project and possible future extensions.) gcs-6 Section 3.7.5.2 (ptys): Case dependency on 2003/246 [fs-driven device naming]? If so, it seems that your life would be simplified a bit here. * There is overlap between the 2 cases.... gcs-7 interface table incompleteness: changes to mdb (via librtld_db.so); layered drivers (e.g., audio char dev); lx_autofs; etc. (Suggest case owner and project team perform audit.) * Project team will update this. gw-3 Solaris Audit Sorry, I missed this at the inception ;-{ There seems to be two new system calls at the Solaris level. How are they captured in the audit subsystem? While the lx branded zone will not be participating in Solaris Auditing, the globalzone may be auditing for all zones. Is anything done as part of lx branded zone startup to reset the audit state? (I don't recall if native zone startup does anything.) You should probably test with auditing turned on -- I'll be happy to consult. * This is best worked offline with Gary. gw-4 20Q 6 "solaris 10" brand Should this track the native system? Is there an intent to have an S10 brand that carries on into S11 days? Should other < S10 brands be built? * It is not possible to have older brands of Solaris available. * The S10 brand should be able to run on S11... gw-5 What issues might arise from branded suid (or uid 0 admin actions) not having full privileges? How will any failures be documented for CUs? gw-6 Design 3.8.1.4 libnsl plugin This team should likely contact the Sparks team to ensure compatibility going forward. gw-7 Design 3.8.1.6 privileges Why are the file_dac privileges needed? eg-12 design 2.1.5 What does the Linux kernel actually do about signals to init? Why are we speculating here? eg-13 design 2.2.1 How is brand code different from any LKM WRT stepping on the kernel? eg-14 design 2.2.2 Why are there HW specific vectors that are non parallel constructions? When do they get called? When is the implementation of them likely to change? wes-13 delegated administration of solaris-specific capabilities (forward-looking question) zfs allows for chunks of a pool's namespace to be delegated to a zone's administrator. crossbow is talking about doing something similar for network interfaces. These undoubtedly won't be the only type of administrative delegation we'll allow for. Are branded zones forever second-class citizens with respect to these capabilities? Do we need to put this into /native ? * ZFS delagation is probalby not going to work. wes-14 random observation: the "fake" solaris 10 brand might prove to be useful. (see 6334395/6334928, but not immediately after lunch) wes-15 brands(5): "Optionally, a brand can provide a boot routine" ? who's the target audience of this man page? it provides an overview of the implementation changes, but doesn't provide enough detail to let someone plug into or customize the interface. (for instance, I don't see enough detail about how to customize the post-clone or pre-boot script). wes-16 design.pdf 3.6: what, if anything, would prevent solaris from providing 32 real-time signals instead of the current 8? (in other words, if this does become an issue, how bad is it?) wes-17 design.pdf 3.7.2: does the device major/minor mapping mechanism avoid false positives? You mention major 136 being known well-known to linux apps; for instance, on a couple x86 systems here, ls -lLR /dev /devices | grep 136 turns up a collision with "keysock"; amusingly, making keysock zone-aware is on my TODO list.. wes-18 design.pdf 3.7.5.4: have you talked with the Trusted Extensions folks about what they're doing with respect to audio devices in zones? * piggyback onto jdc-12 wes-19 3.8.1: NFSv1? I thought solaris just supported v2..v4? sz-1 nit: design doc 2.1.3 non-intuitive rule < match="zconsole" name="console" /> can we do zconsole -> console? sz-2 Impact on Zones upgrade -- how do you ensure lx zone continues to work when Solaris is upgraded? sz-3 Solaris 10 brand: is it going to track S10 updates? ======================= CASE INTERN/OWNER'S NOTES ======================== 2005/471 Committment Team noted that DTrace support will be a seperate putback. jdc-0 - just the issues jdc-1 - linux is a trademarked term - lx - RedHat and Debian - Distribution names also have trademark issues - lx is for 2.6 and futur RedHat distributions What are the rules for the namespace? - we don't want customers to have to access a decoder ring to find these out - there is a man page for all brands - created only if absolutely needed We don't plan to do it now is not a complete answer. concern that we are designing on the fly *** Project team to review this. Think about how to use this going *** forward "We see land mines on that bridge" RECOMMENDATION: The recommendation is to remove references to future names from this case, and to leave the issue to future cases. jdc-2 - 2.4 is a stable target - Customers want 2.4 * There may be additional pressure to upgrade based on Gnome and KDE versions that are getting quite old. jdc-3 - We can't support "download latest source and build" model - We *are* running in an s10 zone and have all of the things that this implies We need to communicate ths to set our customer expectation appropriately - We *can* update user space packages using the linux mechanisms as you would expect jdc-4 - Team made it clear that filesystems was never on the roadmap and that this appears beyond the scope of this project Concern: this make it difficult to migrate data. - Xen might be the only viable answer jdc-5 not shipping this brand, it is for testing on SPARC jdc-6 - have not found applications that depend on this - Apache and ftpd can work without chroot - if customers need this we would suggest running in a native solaris zone "What will we do if customers complain/ask for this?" A: "these don't work ..." jdc-7 - should be ok and transparent ** The spec should be clear about these. Truss works today and apptrace is in progress. jdc-8 eg display brand name in a process listing - will take care of this * spec updatem required jdc-9 - live upgrade not yet addressed should this be a different project? - team expects to putback well before zulu *** both projects need to talk - need a case dependancy on (I missed this) - zulu ignores non-solaris zones * The dependency is on a yet-to-be-filed fast-trac jdc-10 - yes jdc-11 - inherited this streams module from Janus and it seems to work needs to go into interface table jdc-12 - Architectural decision to use zone attributes. - /dev/dsp is always there, you just need to enable it. wes-18 trusted solaris tackles a similar issue. - project team has not yet spoken with the trusted extensions team jdc-13 - now uses rpm2cpio from global zone thn use the zone's rpm. - no extra software to add jdc-15 - might be able to simplify jdc-16 - copy jdc-17 Should this case EOL lxrun or use a different fast track? - use a new fast track gw-3 - work offline with gw/team gw-4 - very difficult - not shipped (see jdc-5) gw-5 - you have all of the restrictions that you normally have with a zone gw-6 - already spoken with Sparks team --------TIME-------- Shudong's issues on teh whiteboard have been addressed Team understands the remaining issues VOTE ===== yes - no - abstain - NP - NEXT STEP ========= * Project team will go and update spec. Vote will be taken possibly in ARC Business. ============================================================================== Presentation: Crossbow - Network Virtualization and Resource Management Submitter: Kais Belgaied Interest: crossbow-core@sun.com SUMMARY ======= This is informational only. --Boundary_(ID_cw1KimgZA8PI19WIK8XAUA)-- From sacadmin Thu Jul 13 11:59:58 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6DIxvZl000094 for ; Thu, 13 Jul 2006 11:59:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k6DIxvN12847 for <@sunmail3.sfbay.sun.com:psarc@sun.com>; Thu, 13 Jul 2006 11:59:57 -0700 (PDT) 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 <0J2C00403VFWXM00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 13 Jul 2006 11:59:56 -0700 (PDT) Received: from nwkea-pix-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J2C000QDVFUO420@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 13 Jul 2006 11:59:55 -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 k6DIxse0026402 for ; Thu, 13 Jul 2006 11:59:54 -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 <0J2C00401VFEC400@d1-sfbay-10.sun.com> (original mail from Sherri.Shieh@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Thu, 13 Jul 2006 11:59:54 -0700 (PDT) Received: from [129.150.20.71] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J2C00IO2VFOIP80@d1-sfbay-10.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 13 Jul 2006 11:59:52 -0700 (PDT) Date: Thu, 13 Jul 2006 11:59:50 -0700 From: Sherri Shieh Subject: Re: PSARC Meeting Minutes 05/17/2006 Commitment: 2005/471 In-reply-to: <20060712152340.GF143658@east.sun.com> Sender: Sherri.Shieh@Sun.COM To: Nils Nieuwejaar , psarc@Sun.COM Reply-to: Sherri.Shieh@Sun.COM Message-id: <44B69826.9000200@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CgRMzOLcCXHNfdF4zYQ3pQ)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <44733609.3040409@Sun.COM> <20060712152340.GF143658@east.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: 135968 This is a multi-part message in MIME format. --Boundary_(ID_CgRMzOLcCXHNfdF4zYQ3pQ) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT All, Final materials have been put into the final.materials directory: -rw-rw-r-- 1 ss146556 sacmail 37072 Jul 13 11:53 20_questions drwxrwsr-x 2 ss146556 sacmail 512 Jul 13 11:53 ./ -rw-rw-r-- 1 ss146556 sacmail 26625 Jul 13 11:53 commitment_comments -rw-rw-r-- 1 ss146556 sacmail 339630 Jul 13 11:54 design.pdf - Sherri ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, Systems Architecture Sun Microsystems, Inc. Phone: 650-786-5245/x85245 Email: Sherri.Shieh@sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nils Nieuwejaar wrote: >Hi, > >Attached are our responses to all of the issues/questions raised during the >BrandZ commitment review. I am also attaching updated versions of our >design and 20-questions documents, both with changebars. All other docs >are unchanged since the commitment review. > >Our man pages are in the final editing stages now. If desired, I can >submit those to be added to our case directory when they are finished. > >To fully address the issues raised during the review, we still need to file >two fast track cases: one covering our changes to the pkg tools, and one >for the EOL of lxrun. Both cases are currently drafted and out with >individual PSARC members, awaiting comments and then formal submission. > >During the commitment review, PSARC decided that there was no need to have >a final review for this case. They/you just wanted to see the responses to >the new issues, and to review the updated documents, before voting. > >Assuming there are no significant new issues raised offline, when should we >expect this vote to take place? Even if there is no review planned, I >would like to dial into the meeting to answer any last-minute questions >people may have. > >Thanks, > Nils > > > >------------------------------------------------------------------------ > > > >>============================================================================== >>Commitment: BrandZ: Support for non-native zones (2005/471) >>Submitter: Nils Nieuwejaar >>Owner: Ed Gould >>Intern: Alan Hargreaves >> >> >> >>SUMMARY >>======= >>* Advice to the project team: brand.dtd.1 - there might be something simpler for this issue >>* /opt/sfw/bin/lxrun: make this a seperate fast track >>* Strongly advise: make /opt/sfw/bin/lxrun go away >> >>ISSUES >>====== >>jdc-0 What's changed since inception? >> >>* Everything that has changed is in the issues from inception. >> >>jdc-1 What exactly does the name "lx" mean? I'm worried we're >> headed into a confusing forest of "lx-ubuntu" and "lx-2.6" >> (i.e., both distribution-based and kernel version based >> brands) in the future. >> >>* The project team chose LX instead of Linux - it seemed unwise to choose >> Linux to be named in the branding. LX is the team's way of delivering >> Linux support. >> >> > >Specifically, we were concerned about possible trademark issues. > >We emulate the interface between the kernel and glibc, and that interface >is relatively stable across distributions and kernel versions. We expect >that any Linux distribution we support will be able to fit into the single >'lx' brand. We could conceivably have to add distro-specific or >kernel-specific operations, but those would be run-time decisions >implemented within the single 'lx' brand. > > > >>* Suggestion: remove the what the future is out of the design doc - >> should at least mention the concern of the future in the document >> >> > >Done. The design doc still mentions that Debian works with the existing >brand, but drops any discussion of support for future distributions. > > > >>jdc-2 What's the point to supporting RHEL3 and the 2.4 kernel? It >> seems that RHEL3 is several years out of date and 2.6 is >> pretty far along. RHEL3 is older than FC0.94, and they're on >> FC5 now. >> >> > >We are deliberately targeting an older version of Red Hat to minimize any >churn in the platform we are emulating. Trying to support Red Hat 5 would >require a substantial investment in ongoing, pro-active support. Red Hat 4 >would be a reasonable compromise, but it would delay our delivery by at >least another 6 months. Red Hat 4, including support for 64-bit >applications, would be a logical follow-on to this project should OPG >decide that there is sufficient demand to fund the work. > > > >>jdc-3 glibc-2.3.2 is old and still has executable stacks (potential >> security problem). More importantly: what do we (or don't we) >> tell customers about the security of BrandZ-hosted Linux on >> Solaris? >> >> > >For compatibility we have to allow Linux applications to run with >executable stacks, so those applications are vulnerable to any security >holes that are opened by those stacks. However, since you are running >inside a zone, any damage would be confined to that BrandZ instance. A >compromised zone will not be able to bring down the system, and will >neither have access to, nor be able to damage, applications or data in >other zones. > >Considered more generally, a BrandZ-hosted linux environment will be >subject to any security holes in the Linux user-space. However, it will >not be vulnerable to any security holes that depend on kernel support or >kernel bugs. This would arguably make a BrandZ-hosted RHEL 3 environment >more secure than a native RHEL 3 environment. > > > >>jdc-4 Are users dependent on reading ext[23]fs data? How usable is >> migration without file system support? What else is missing >> if we want people to migrate? >> >>* Supporting linux file systems is not on the roadmap and project team >>has made it clear to customers. This doesn't seem to be a huge obstacle >>about having to deal with migration for Linux. >> >> > >Support for Linux file systems is something that we do occasionally get >asked about, but so far we haven't run into a single customer who >considered this a necessary feature. In fact, I don't believe we have >found a single customer that was surprised that this support would not be >available. > >Developing an ext[23]fs VFS module for Solaris would be a useful part of an >overall Linux-to-Solaris migration story. That functionality is orthogonal >to the emulation we are developing here, and is beyond the scope of this >project. > > > >>jdc-5 Is the "s10" brand included in this project the right >> architectural direction to take the system, and has the Zones >> team been involved in this decision? Could we ever really >> support old releases in zones? (And can't and don't users >> _already_ do this more simply by hacking uname?) (Merely >> changing the uname value and calling it an "s10 branded zone" >> seems like a dangerous bait-and-switch to me.) >> >>* The S10 brand is only designed for testing. This isn't going to be sent >>to customers whatsoever. This is not a real Solaris 10 environment (won't >>be shipped). >> >> > >This brand is specifically designed to exercise the BrandZ framework on >SPARC-based systems - as requested by PSARC during our inception review. >It can also be used to exercise the framework on x86/amd64 systems without >adding any Linux software. > > > >>jdc-6 For the system calls that are missing, do we have an idea of >> what might be affected? (Have we done searches?) In >> particular, what Linux things are broken by lack of chroot >> support? >> >> > >The absence of chroot() will affect some network services (e.g., ftpd and >httpd) which may be configured to run within an alternate root environment. >These services are typically configured this way to minimize the potential >damage should the service be compromised. It seems reasonable to argue >that we have already achieved this level of compartmentation by running the >service within a zone. > > > >>jdc-7 20q9: truss and apptrace aren't mentioned here. If mdb >> understands brands, should dbx also understand them? >> >>* nits - truss has been updated and apptrace will soon. >> >> > >To be clear: truss has been updated to recognize the new system calls; it >has not been updated to understand and display the Linux system calls >issued by the application. We have added an lx-syscall DTrace provider to >make that information available. > >dbx does not currently work, but this appears to be a bug rather than a >fundamental limitation of the design. This is still under investigation >and is being tracked as: > 6445248 dbx cannot grok Linux processes > > > >>jdc-8 Mdb's kernel-space dcmds (e.g., ::ps, ::pgrep, and >> ::threadlist) should probably be enhanced to understand >> brands. >> >>* nits >> >>jdc-9 Is there an Install-related project on which this one depends, >> or does this project also deliver the necessary Install >> changes to skip over branded zones? (If it's the latter, then >> zonecfg_get_brand() is probably Contracted.) >> >> > >I have changed it from "Project private" to "Contracted Project private". >The contract has been signed and submitted. > > > >>* Live upgrade doesn't run zones. The packaging pack tools will go into >> the install gate. There is an RFE file that the project team and link to >> this PSARC case. As for live upgrade, the p-team doesn't know what to do >> about that right now. (ARC is talking about Zulu) >> >> > >The RFE for this change is: > 6342179 packaging tools need to be brand aware > >A PSARC fasttrack has been drafted and is being circulated for comment >prior to being officially submitted. > > > >>jdc-10 Now that there are entries in zone_platform.dtd.1 for the >> various mounts and links that need to be created, can the >> hard-coded lists in zoneadmd be refactored into these more >> flexible files? (If that's not this project, then there's >> probably advice here to create one so that the result is a >> complete design.) >> >>* The hard coded device names will be made into the flexible files. >> >> > >All the the device and privilege lists currently hardcoded into the zones >utilities have been moved to the platform.xml and config.xml files that >describe the native brand. > > > >>jdc-11 What does TIOCSETLD actually do on Solaris? (Shouldn't that >> be TIOCSETD rather than TIOCSETLD? The latter doesn't appear >> to be in the Linux kernel sources, but 20q mentions the >> former.) How can line disciplines be used on a STREAMS-based >> system? >> >>* This should be put into the interface table... >> >>jdc-12 Audio support seems clumsy. Why is a separate attr needed? >> Doesn't export of /dev/dsp to the zone imply that audio is >> accessible? If attributes are needed, shouldn't they be part >> of the device import? >> >> >> >/dev/dsp is always present on Linux systems, and in Linux zones, regardless >of whether there is any audio hardware available. Neither /dev/dsp nor >/dev/mixer exist on Solaris, so they are not part of the standard device >import list. > >There is no notion of a device-specific attribute, which is needed to >support systems with multiple audio devices, in the zone's infrastructure >now. Adding such a capability would have required an extensive overhaul of >how devices are configured and managed. > >The multiple-devices problem could also have been addressed by adding a >Linux-specific "audio resource". Unfortunately, the original design of >zonecfg and libzonecfg was to hardcode all the resource types into the >library and utility, and to hardcode their names into the parser. Adding >brand-specific resources would have required an extensive redesign of this >tool. > >Rather than redesign the core of the zones configuration tools simply to >solve one Linux corner case, we chose to use the generic attributes >mechanism to support audio devices. > >For single-device systems, adding an audio device is a trivial task. Most >of the complexity in this configuration is only encountered when working >with systems with multiple audio devices. This has been made clearer in >the design document. > > > >>* Please talk to the trusted Solaris team about the audio issue. >> >> > >We have done so. The concerns that Trusted Solaris has with branded zones >run much deeper than just the audio device. > >The zone/label management applications that are running in the global zone >are not prepared to deal with Linux branded zones. These applications in >the global zone are aware of all other zones (and their associated labels) >on the system. Also, these applications expect to be able to fork and >zone_enter() different zones based of their label types. Without making >these applications brand aware and modifying these applications so that >they can run successfully in branded zones it seems unsafe to allow branded >zones on a system where labels are enabled. > >As a result, we will not be able to support branded zones on trusted >systems where labels are active. This will be made clear in the BrandZ >documentation. > > > >>jdc-13 20q19: this project is probably strictly dependent on >> integrating rpm into the WOS. (The SPARC question here looks >> like a marketing or business issue, but I think it'd look bad >> to customers if we didn't even support our own products.) >> >>* The project team is using the exisiting linux version of the RPM. >> >> > >For the first stages of install we use rpm2cpio(1), which is already >delivered with Solaris. Once we have installed enough Linux packages to >boot the zone, we use the Linux rpm(1) tool to complete the installation. > > > >>jdc-14 nit:20q13: this case _exports_ the things listed in the import >> table. >> >> > >Fixed. > > > >>jdc-15 design?:nit?:brand.dtd.1: why are there function names here? >> Why not just specify a particular shared library interface >> that all brand libraries must implement -- just like the >> _init/_fini/_info functions used by kernel modules? And why >> have the name of the shared object here? Why not just have >> both verify() and validate() in the same object with some >> well-known (brand-name-based) file name? (There are a lot of >> degrees of freedom here, and it looks like a lot of them lead >> to accidents.) >> >>* Advice to the team - there might be something simpler here.... >> >> > >There are no function names in the config.xml file. The file contains: > > - The name of the kernel module needed to support the brand. Some > brands (e.g., a Nexenta brand) would not require a kernel module. > > - The binary to use for init(1M). This is determined by the system > being emulated, so we cannot dictate what it will be called. > > - The script to use for installing the zone, and those to be run > when the zone is booted, halted, and cloned. We could impose a > naming convention on these scripts, but that seems unnecessarily > restrictive. As an example, we currently use 'lucreatezone' as > the install tool for native zones, which would not fit into any > brand-specific naming scheme. > > - The names of the external programs to run to verify the zone at > configuration and boot times. These could probably be delivered > in a well-known shared object, but that would prevent the brand > developer from using script-based verification. > >It is certainly accurate to say that there are a lot of degrees of freedom >here. In the cases of init(1M) name and the install program, this is >needed to avoid adding an extra layer of indirection. We could impose a >naming convention on the other fields, but that would leave us with a >seemingly arbitrary distintion between 'imposed' and 'optional' names. > > > >>jdc-16 What is the behavior of cloning if no post-clone script is >> present? >> >> > >The initial stages of the clone process are the same for every brand: the >zone is copied from the source to the destination. The postclone script is >called after the copy successfully completes. For native zones, the >postclone script mounts the zone and run sys-unconfig. For Linux zones, we >do not provide a postclone script, so no further action is taken after the >copy completes. > >This is now addressed in section 2.1.5 of the design document. > > > >>jdc-17 Does /opt/sfw/bin/lxrun go away? >> >>* EOL? >>* Make this a sperate fast track >> >> > >A PSARC fasttrack to EOL lxrun has been drafted and passed to the BrandZ >case owner for official submission. > > > >>gcs-5 Section 3.7.4 (Device minor nodes and paths): Trails off into >> "If we decide to do this, then...". What specifically do you >> plan to deliver? (That is, reword the spec to clarify the >> boundary between this project and possible future extensions.) >> >> > >The speculation has been removed from the design doc, and it now reflects >what we are delivering with this project. > > > >>gcs-6 Section 3.7.5.2 (ptys): Case dependency on 2003/246 [fs-driven >> device naming]? If so, it seems that your life would be >> simplified a bit here. >> >>* There is overlap between the 2 cases.... >> >> > >2003/246 (aka "devnames") will make the BrandZ implementation simpler, and >we are working with the devnames project to ensure that we will be able to >merge with them easily. We intend to putback to Nevada at least one build >after them, to allow us time to resync and thoroughly test prior to our >integration. > >There is no strict dependency here. If the devnames project were derailed, >we could putback the implementation we currently have. > > > >>gcs-7 interface table incompleteness: changes to mdb (via >> librtld_db.so); layered drivers (e.g., audio char dev); >> lx_autofs; etc. (Suggest case owner and project team perform >> audit.) >> >>* Project team will update this. >> >> > >Fixed. > > > >>gw-3 Solaris Audit >> Sorry, I missed this at the inception ;-{ >> There seems to be two new system calls at the Solaris level. >> How are they captured in the audit subsystem? >> >> > >This is an operation that takes place entirely within the address space of >a single process, so uucopy(2) is not audited. > >The brandsys(2) call is captured using a new "AUE_BRANDSYS" event. An >audit record is issued at the start of the call. The brand architecture >does not define any structure to the call. Rather than trying to impose >some structure on it within the audit subsystem, we simply record all the >arguments to the call. In theory we could allow brands to supply routines >that interpret their brandsys(2) for the audit subsystem, but that seems >excessively complex. Alternatively, we could add brand-awareness to the >tools that post-process the audit records. > > > >> While the lx branded zone will not be participating in Solaris >> Auditing, the globalzone may be auditing for all zones. >> Is anything done as part of lx branded zone startup to reset >> the audit state? (I don't recall if native zone startup >> does anything.) >> >> You should probably test with auditing turned on -- I'll >> be happy to consult. >> >> > >Processes running in an lx-branded zone do not have their Linux system >calls audited. Otherwise, they are subject to all the standard auditing. >For example, Linux process creation/exit events are captured as for any >other process. The Solaris system calls that the brand library uses to >emulate the Linux system calls are subject to auditing. > >The only restriction is that the Solaris audit processing tools cannot run >inside the Linux zone, so the audit records must be consumed by tools >running in the global zone. > > > >>gw-4 20Q 6 "solaris 10" brand >> Should this track the native system? Is there an intent to have >> an S10 brand that carries on into S11 days? >> >> Should other < S10 brands be built? >> >>* It is not possible to have older brands of Solaris available. >>* The S10 brand should be able to run on S11... >> >> > >As mentioned elsewhere, this is not a real S10 brand. It is a tool for >testing, which will not be distributed. We are actually going to turn this >into a "Solaris n-1" brand, so we can use it when we integrate into the S10 >update tree. On S10, uname will return "Solaris 9", on Nevada it will >return "Solaris 10". > > > >>gw-5 What issues might arise from branded suid (or uid 0 admin actions) >> not having full privileges? >> >> > >The only significant issue we have enountered thus far arises from the >inability to create device nodes within a Linux zone. > >This only comes up during the initial zone installation. To address this >issue, we have a special "install mode", in which mknod(2) translates EPERM >and EACCESS into SUCCESS. The device nodes aren't actually created, but >the device package is recorded as being successfully installed, satisfying >the dependencies other packages have on it. > > > >>How will any failures be documented for CUs? >> >> > >Linux zones are documented as having "all the restrictions as native >Solaris zones". Attempts to perform an operation that is disallowed will >fail with the appropriate error code. > >For example, attempting a mknod(2) inside the zone fails with EPERM; > bash-2.05b# mknod /tmp/disk b 120 120 > mknod: `/tmp/disk': Operation not permitted > > > >>gw-6 Design 3.8.1.4 libnsl plugin >> This team should likely contact the Sparks team to ensure >> compatibility going forward. >> >> > >Done. We talked with the Sparks team before doing the implementation, and >hey didn't foresee any issues. After this issue was raised, we went back >to the team to verify that we are still OK. They said: > > "I did not do a thorough code review, but everything looked > straight forward, and I don't anticipate any issues with the work > we are doing in sparks at this time." > > > >>gw-7 Design 3.8.1.6 privileges >> Why are the file_dac privileges needed? >> >> > >The NFS daemons (lockd and statd) run as non root processes in the linux >environment, but they need to be able to create and destroy files in: > > /native/etc/svc/volatile > /native/var/statmon > > > >>eg-12 design 2.1.5 >> What does the Linux kernel actually do about signals to init? Why are >> we speculating here? >> >> > >We have been trying to locate somebody who is already tainted by looking at >Linux source, and who has the time and expertise to investigate the issue. >Thus far, we haven't had any luck. We will continue to pursue this, but >regardless of the answer no significant design or code changes will be >requried. > > > >>eg-13 design 2.2.1 >> How is brand code different from any LKM WRT stepping on the kernel? >> >> > >It isn't any different. There is always a risk that somebody will attempt >to load a broken or out-of-date kernel module, and that it might do random >damage to your system. By attempting to identify these modules at >load-time, we are simply adding a thin layer of protection. > > > >>eg-14 design 2.2.2 >> Why are there HW specific vectors that are non parallel constructions? >> When do they get called? When is the implementation of them likely to >> change? >> >> > >The mechanisms used to enter the kernel differs between platforms, so the >vectors we use to represent interpositions on these mechanisms also have to >differ. The vectors will only change when a new kernel-entry mechanism is >introduced. > >In theory we could provide just a single 'system call entry' vector, which >is identical across platforms, and which has different internal code paths >depending on the specific mechanism used to enter the kernel. This would >simplify the ops vector at the cost of increasing the complexity and >overhead of implementing the interposition mechanism. > >In addition, there is an x86-specific callback mechanism to update the >segment registers. This callback is called by the x86-specific >fixsegregs() function any time the "general" registers are reset - >generally on a context switch. There is no parallel callback in the SPARC >vector simply because the SPARC architecture does not have anything similar >to the x86 segment registers. > > > >>wes-13 delegated administration of solaris-specific capabilities >> (forward-looking question) >> >> zfs allows for chunks of a pool's namespace to be >> delegated to a zone's administrator. >> crossbow is talking about doing something similar for >> network interfaces. >> >> These undoubtedly won't be the only type of administrative >> delegation we'll allow for. Are branded zones forever >> second-class citizens with respect to these capabilities? >> Do we need to put this into /native ? >> >> > >Linux-branded zones will always be second-class citizens in many ways. As >our real goal is to increase Solaris adoption, using BrandZ as one part of >a migration strategy, we view this as a feature rather than a bug. > >To address these specific issues: ZFS delegation will not work within a >Linux zone. Given sufficient customer interest, we could possibly support >the ZFS utilities, but it would take a significant amount of engineering >work, and would violate our "one binary type per zone" model. > >Supporting network delegation is significantly more feasible. By emulating >the ioctl()s needed to perform network configuration tasks, we should be >able to support network delegation using Linux configuration tools. This >would not be a trivial engineering effort, but it would certainly fit >within the overall BrandZ model. > > > >>wes-14 random observation: the "fake" solaris 10 brand might prove to >> be useful. (see 6334395/6334928, but not immediately after lunch) >> >>wes-15 brands(5): "Optionally, a brand can provide a boot routine" ? >> who's the target audience of this man page? it provides an >> overview of the implementation changes, but doesn't provide >> enough detail to let someone plug into or customize the interface. >> (for instance, I don't see enough detail about how to >> customize the post-clone or pre-boot script). >> >> > >The audience for all of our man pages is intended to be the users of >systems with branded zones - not brand developers. We will go though our >man pages and ensure that we are providing the right level of detail. > > > >>wes-16 design.pdf 3.6: what, if anything, would prevent solaris from >> providing 32 real-time signals instead of the current 8? >> (in other words, if this does become an issue, how bad is it?) >> >> > >We would have to increase MAXSIG from 48 to 72. This would increase the >number of words needed to repesent a signal mask from 2 to 3. This >increases the sizes of size of user_t, proc_t, and kthread_t. These >changes are all to internal kernel structures, so there is no issue with >breaking user-space compatibility. > >We spoke with one kernel engineer who tried to increase MAXSIG some time >ago, and he quickly discovered that the current size is baked into >assumptions throughout the kernel. Although he couldn't recall the >specific breakages he ran into, he did recall that they were extensive and >often subtle. > >So, this is a change that we could make if we needed to, but it seems to be >risky enough that we should avoid it if we can. > > > >>wes-17 design.pdf 3.7.2: does the device major/minor mapping mechanism >> avoid false positives? You mention major 136 being known well-known >> to linux apps; for instance, on a couple x86 systems here, >> ls -lLR /dev /devices | grep 136 >> turns up a collision with "keysock"; amusingly, making keysock >> zone-aware is on my TODO list.. >> >> > >There is no opportunity for false positives. The Solaris system calls used >by the brand library always return Solaris dev_t values. We translate the >dev_t value into the Solaris device name, and then use the device name to >derive the Linux dev_t values. So, the fact that major number 136 may >reflect two different devices on Solaris and Linux does not pose any >difficulty. > > > >>wes-18 design.pdf 3.7.5.4: have you talked with the Trusted Extensions folks >> about what they're doing with respect to audio devices in zones? >> >>* piggyback onto jdc-12 >> >> >>wes-19 3.8.1: NFSv1? I thought solaris just supported v2..v4? >> >> > >Correct. This is an error in the doc. > > > >>sz-1 nit: design doc 2.1.3 non-intuitive rule >> < match="zconsole" name="console" /> >> can we do zconsole -> console? >> >> > >I don't think I understand this question. I'm not sure whether the concern >is with the syntax, with the specific device names, or something else. > >I don't know if this helps or hurts, but this line is now: > > > > > >>sz-2 Impact on Zones upgrade -- how do you ensure lx zone continues >> to work when Solaris is upgraded? >> >> > >The zones test suite, which is run as a regular part of the PIT suite, will >be extended to include testing of lx-branded zones. > > > >>sz-3 Solaris 10 brand: is it going to track S10 updates? >> >> > >No. > > > >------------------------------------------------------------------------ > >1. What specifically is the proposal that we are reviewing? > > - What is the technical content of the project? > > BrandZ is a framework that allows for the creation of Branded > Zones, which are zones that run a non-native userspace on a Solaris > system. Each non-native environment is implemented by a "Brand". > > 'lx' is the initial brand we are delivering, and it supports the > execution of a Linux userspace environment by emulating the > following Linux kernel interfaces: system calls, /proc, some of > /dev. The lx brand specifically supports the interfaces provided > by the 2.4.21-32.ELsmp kernel, which is the version used by Red Hat > Enterprise Linux (RHEL) 3.x. > > The product, combining the framework and initial brand, is called > "Solaris Containers for Linux Applications". > > The technical details of the project are encapsulated in the design > document, which is available online at: > http://opensolaris.org/os/community/brandz/design > > A copy of the design document is included in the materials for this > case. > > - Is this a new product, or a change to a pre-existing one? > > This is a change to Solaris. As described below, it will have patch > binding. > > - If your project is an evolution of a previous project, what > changed from one version to another? > > This project is an evolution of the Janus project (PSARC 2003/445), > and it differs from Janus in two fundamental ways. > > 1. BrandZ is tightly tied to the zones model introduced in > Solaris 10 (PSARC/2002/174). > > Janus required a new administrative tool (brandadm) to > manage brands, while we extend the existing administrative > model. More significantly, Janus introduced a complex and > non-intuitive 'pathmapping' mechanism to avoid namespace > conflicts in the filesystem, while we simply use the > namespace isolation inherent in the zones-based approach. > > 2. Our emulation is almost entirely performed in userspace, > following the approach introduced by the SunOS Binary > Compatibility Project. This approach reduces the amount of > the code introduced into the kernel, limits the interactions > between the brand support code and Solaris proper, and > increases the observability and debuggability of the brand > support code. > > 3. While Janus was strictly limited to supporting Linux > applications, The BrandZ infrastructure is designed to be > flexible enought to allow for the creation of distinctly new > brands. Possible brands include Solaris variants (whether > completely different versions or simply with different > userspace components), FreeBSD, or Apple's Darwin. > > - What is the motivation for it, in general as well as specific terms? > - What are the expected benefits for Sun? > > Much of the focus of the Janus project, and this one in its early > days, was on customers that are trying to transition from Linux to > Solaris, but have a number legacy Linux applications that are > preventing the switch. Linux emulation was viewed as a way to help > them make the switch to Solaris before their full software toolset > was available. Since that time, ISVs have been porting their > applications to Solaris on x86 in record numbers, somewhat reducing > the need for this transitional tool. There are still many > customers for whom this will be useful, but their interest is now > as likely to be on in-house applications as on ISV applications. > > Another area which is ripe for exploitation is consolidation. A > monocultural example would be a customer that wants to consolidate > multiple Linux applications onto a single machine, but is not sure > how, or if, they can cohabitate peacefully. This project allows > each application to run in its own Linux zone, eliminating those > issues. Alternatively, a customer may have a mix of Linux and > Solaris applications, and not want to maintain two different > machines. This use case is already being explored by an EDA group > in Sun. > > Another interesting market is the developer community. By enabling > Linux applications on to run on Solaris, developers are able to use > Solaris tools such as DTrace to develop, debug, and tune their > applications. This use case has attracted the most immediate > attention from customers, as it brings the most benefit with the > least risk. > >- By what criteria will you judge its success? > > - For correctness and completeness, we will be using the following > test suites: LSB, LTP, connectathon, and the zones test suite. > Note: we will be using the LSB test suite to evaluate the quality > of our implementation, but we do not anticipate being LSB > compliant. We will provide a list of the specific areas in which > we are non-compliant. > > - Surveying SEs and OS Ambassadors to gauge adoption rate. > > - Growth of the BrandZ OpenSolaris community and activity on the > BrandZ discussion list. > >2. Describe how your project changes the user experience, upon > installation and during normal operation. > > A Solaris user will see a single column added to the output of the > 'zoneadm info' command. There will be no other visible changes to > the installation or operation of their systems. The BrandZ > functionality is only perceptible when explicitly invoked by the > user. > >- What does the user perceive when the system is upgraded from a > previous release? > > There is no previous release of BrandZ. When upgrading from a > previous version of Solaris, the only visible change to the user > will be the additional output to "zoneadm info". > >3. What is its plan? > >- What is its current status? Has a design review been done? Are there > multiple delivery phases? > > Design and implementation of BrandZ and the lx brand have been > underway for 10 months, and the bulk of the core functionality is > nearing completion. There are many refinements to complete and > loose ends to tie up. We are transitioning to an OpenSolaris-based > development model and have released an initial snapshot on > opensolaris.org. > > A design review was done on 8/29/05. Detailed notes from the > design review are available: > http://perf.eng/twiki/bin/view/BrandX/DesignNotes > > A condensed list of the specific actions/changes the came out of > the review is included with the case materials. As items are > completed, they are noted here: > http://perf.eng/twiki/bin/view/BrandX/DesignActions > > We are currently committed to just a single delivery into Nevada > and into a Solaris 10 update. There are numerous opportunities to > update and extend this project in the future, but no commitment to > do so. > >4. Are there related projects in Sun? > > This project extends the zones infrastructure and modifies the zone > management commands. We are in regular contact with the zones > engineering team and management to ensure that we are not working > at cross-purposes. After integration, we expect that the BrandZ > features will be maintained as a first-class component of the zones > infrastructure. > > This project will affect the zones upgrade project, much of which > is contained in the Install consolidation. The extent of the > interaction appears to be that the packaging, patching, and > upgrading tools must be aware of the existence of Branded Zones, > and simply avoid modifying them. We have discussed this > interaction with the zones upgrade team, and are in agreement on > this approach. > > The feature set of this project has some overlap with that of the > Xen project, which allows a paravirtualized version of Linux to > boot on the same system as a paravirtualized Solaris. Some key > difference between the two projects: > > BrandZ only runs the Linux userspace, while Xen runs both > the Linux userspace and kernel. So, Xen delivers a higher > fidelity Linux environment, but it comes at a higher cost. > > Xen requires a custom Linux kernel, while BrandZ does not. > > BrandZ allows users in the global zone to manage, > manipulate, and examine the processes running in the Linux > zone. This includes the ability to use DTrace to probe > Linux applications. At least in its initial incarnation, > the activity within a Xen instance is completely opaque to > users in the 'dom0'. > > The differences between BrandZ and Xen are largely analogous to the > differences between zones and partitions on a SPARC server. > >5. How is the project delivered into the system? > >- Identify packages, directories, libraries, databases, etc. > > The BrandZ framework is delivered as a set of modifications to the > Solaris kernel and to the zones utilities. In addition, it > delivers a new package (SUNWbrand) containing the userspace support > needed to parse brand configuration files. > > The lx brand is delivered as two packages: SUNWlxr and SUNWlxu, > which contain the kernel and userspace components of the brand > respectively. A detailed list of these components can be found in > section 4.2 of the design document. > >6. Describe the project's hardware platform dependencies. > >- Explain any reasons why it would not work on both SPARC and Intel? > > The BrandZ framework can be applied to both SPARC and Intel. Since > the primary goal of this project is to enable the execution of > x86-based Linux applications, the initial release will only be > available in Solaris on x86/x64-based systems. While there is a > SPARC version of Linux available, there is not sufficient interest > in it to justify the work required to support it in this project. > > It is our intention to putback both the SPARC and Intel code, along > with a fake "Solaris n-1" brand. This brand will interpose only on | > the uname(2) system call. On Nevada, it will always return "5.10" | > in the 'release' field, rather than "5.11". On Solaris 10, it will | > return "5.9". This 'sn-1' brand will allow the framework to be | > exercised on both SPARC and Inteal machines. The zones test suite | > will be extended to include tests of this 'sn-1' brand. | > >7. System administration > >- How will the project's deliverables be installed and (re)configured? >- How will the project's deliverables be uninstalled? > > The project's deliverables will be installed using the standard > packaging mechanism and will be installed by default. The core > brand support cannot be uninstalled. The lx brand may be > uninstalled by removing the SUNWlxu and SUNWlxr packages. > > Neither the BrandZ framework, nor the lx brand, require any > administration. > > As is the case for non-branded zones, any branded zones that are > created will need to be administered. The key difference is that > the zones will need to be administered using Linux tools and > conventions, rather than Solaris. > >- Does it use inetd to start itself? > No > >- Does it need installation within any global system tables? > No > >- Does it use a naming service such as NIS, NIS+ or LDAP? > No > >- What are its on-going maintenance requirements (e.g. Keeping global > tables up to date, trimming files)? > > None > >- How does this project's administrative mechanisms fit into Sun's system > administration strategies? E.g., how does it fit under the Solaris > Management Console (SMC) and Web-Based Enterprise Management (WBEM), how > does it make use of roles, authorizations and rights profiles? > Additionally, how does it provide for administrative audit in support of > the Solaris BSM configuration? > > N/A > >- What tunable parameters are exported? Can they be changed without > rebooting the system? Examples include, but are not limited to, > entries in /etc/system and ndd(8) parameters. What ranges are > appropriate for each tunable? What are the commitment levels > associated with each tunable (these are interfaces)? > > None > >8. Reliability, Availability, Serviceability (RAS) > > BrandZ and the lx brand will have no measurable impact on boot time > or any other system performance. Neither the framework nor this > brand are expected to have any impact on RAS. > >- Does the project make any material improvement to RAS? > No > >- How can users/administrators diagnose failures or determine > operational state? (For example, how could a user tell the > difference between a failure and very slow performance?) > > The state of a branded zone is reported through the existing zone > administration tools. > >- What are the project's effects on boot time requirements? > None > >- How does the project handle dynamic reconfiguration (DR) events? > N/A > >- What mechanisms are provided for continuous availability of service? > None > >- Does the project call panic()? Explain why these panics > cannot be avoided. > No > >- How are significant administrative or error conditions > transmitted? SNMP traps? Email notification? > > Errors in the configuation or booting of a zone will be reported > through the existing zone mechanisms. Errors within a branded zone > will be logged using the standard Linux logging mechanisms. > >- Does it ever require reboot? If so, explain why this situation > cannot be avoided. > > No > >- How does the project deal with failure and recovery? >- How does your project deal with network failures (including > partition and re- integration)? How do you handle the failure > of hardware that your project depends on? >- Can it save/restore or checkpoint and recover? > > This project has no failure requirements, and provides no recovery > functionality, beyond that provided by Solaris. > >- Can its files be corrupted by failures? > No > >- Does it clean up any locks/files after crashes? > There are no locks or files that need cleaning up. > >9. Observability > >- Does the project export status, either via observable output > (e.g., netstat) or via internal data structures (kstats)? >- How would a user or administrator tell that this subsystem > is or is not behaving as anticipated? >- What statistics does the subsystem export, and by what mechanism? >- What state information is logged? > > The state of a branded zone is visible through the standard zoneadm > and zonecfg tools. > > As part of this project, mdb is being enhanced to understand both > running Linux processes and the core files they generate. This > functionality is provided by a brand-specific implementation of > librtld_db.so. > > The brand support added to librtld_db.so enables the DTrace PID > provider to probe Linux processes. > > This project includes an lx-syscall provider for DTrace, which > traces Linux system calls in the same way the syscall provider > traces Solaris system calls. > >- In principle, would it be possible for a program to tune the > activity of your project? > > No > >10. What are the security implications of this project? > >- What security issues do you address in your project? > > Branded zones are subject to all of the security restrictions > imposed on non-branded zones. We introduce no interfaces or > functionality that bypass existing security checks. > > The one area in which it could be argued that we are reducing user | > security is that we are re-introducing the presence of executable | > stacks within Linux zones. This is required for compatibility with | > Linux 2.4.21, in which applications (specifically JVMs) expect | > their stacks be executable. Executable stacks are only available | > to Linux applications and only within Linux zones. Thus, this | > change will have no security implications for Solaris applications, | > Solaris zones, or the global zone. | > >- Please justify the introduction of any (all) new setuid executables. > > N/A > >11. What is its UNIX operational environment: > >- Which Solaris release(s) does it run on? > > BrandZ will be provided for Nevada and a Solaris 10 update. > >- Environment variables? Exit status? Signals issued? > Signals caught? (See signal(3HEAD).) > > Environment variables, command line interfaces, libraries, and > device driver issues are all discussed in the design document. > >- Device drivers directly used (e.g. /dev/audio)? > > We do not use any device drivers directly. As with standard zones, > we allow some devices to be imported into branded zones. > >- Does it use any "hidden" (filename begins with ".") or temp files? > No > >- Does it use any locking files? > No > >- Command line or calling syntax: > What options are supported? (please include man pages if available) > Does it conform to getopt() parsing requirements? > > See attached man pages. Change bars are included to highlist added > functionality. > >- Is there support for standard forms, e.g. "-display" for X programs? > Are these propagated to sub-environments? > > N/A > >- What shared libraries does it use? (Hint: if you have code use "ldd" > and "dump -Lv")? > libaio.so.1 libavl.so.1 | > libbrand.so.1 libc.so.1 | > libctf.so.1 libelf.so.1 | > libnsl.so.1 libm.so.2 | > libmapmalloc.so.1 libmd5.so.1 | > libnvpair.so.1 libproc.so.1 | > libpthread.so.1 librtld_db.so.1 | > librt.so.1 libsec.so.1 | > libsocket.so.1 libsysevent.so.1 | > libuuid.so.1 libxml2.so.2 | > libz.so.1 libzonecfg.so.1 | > lx_brand.so.1 > >- Identify and justify the requirement for any static libraries. > None > >- Does it depend on kernel features not provided in your packages and > not in the default kernel (e.g. Berkeley compatibility package, > /usr/ccs, /usr/ucblib, optional kernel loadable modules)? > > No > >- Is your project 64-bit clean/ready? If not, are there any > architectural reasons why it would not work in a 64-bit environment? > Does it interoperate with 64-bit versions? > > The kernel portions of the project are 64-bit clean, but the user > space components are not. > > We support the execution of 32-bit applications on both 32-bit and > 64-bit machines, but the version of Linux we currently emulate does > not support 64-bit applications. 64-bit Linux is still more > experimental than the 32-bit version, and commercial 64-bit Linux > applications are still relatively rare. > > There are extensive changes in the Linux ABIs for 32-bit and 64-bit > applications, so adding 64-bit support will require significant > development work and is being considered as a follow-on project. > Whether that work is funded will be driven by market demand for > both BrandZ and for 64-bit Linux applications. > > The BrandZ architecture is designed to support different brands, > even simultaneously on a single system, so adding this support > should not require significant changes to anything discussed in > this case. > >- Does the project depend on particular versions of supporting software > (especially Java virtual machines)? If so, do you deliver a private > copy? What happens if a conflicting or incompatible version is > already or subsequently installed on the system? > > No > >- Is the project internationalized and localized? > > Yes > >- Is the project compatible with IPV6 interfaces and addresses? > > There in nothing in the BrandZ design that precludes or prevents > IPv6 support, but we haven't had the resources to test it. > >12. What is its window/desktop operational environment? > > Neither the BrandZ infrastructure, nor the lx brand, provide a > GUI or window-based environment. Branded Zones do not curently > support framebuffer devices, so X servers may not run inside a > branded zone. > > Applications within a Branded Zone may communicate with a remote X > server using the standard X protocols. > >13. What interfaces does your project import and export? > >The details of each interface may be found in the design document, > >_________________________________________________________________________ >| Interfaces Imported | >|_______________________________________________________________________| >| Interface | Classification | Comments | >|___________________|_________________|_________________________________| >| rpm2cpio(1M) CLI | External | Used to install RedHat software | | >| rpm CLI | External | Used to install RedHat software | | >| | | | >| Linux statd(1M) | External | Used to support NFS locking | >| and lockd(1M) | | within lx branded zones | >| uid/gid #'s | | | >| | | | >| glibc ABI | External | Used to provide naming services | >| gethostbyname_r | | to Solaris statd(1M) and | >| gethostbyaddr_r | | lockd(1M) daemons. See section | >| getservbyname_r | | 3.8 of the design doc. | >| getservbyport_r | | | >| openlog | | | >| syslog | | | >| closelog | | | >| __progname | | | >| | | | >| RHEL 3.x contents | External | /etc files, rc.d scripts, etc. | >| | | which we modify at install time | >| | | | >| Linux ELF format | External | Object file format for Linux | | >| | | binaries | | >_________________________________________________________________________ > >___________________________________________________________________________ >| Interfaces Exported | >|_________________________________________________________________________| >| Interface | Classification | Comments | >|________________________|_________________|______________________________| >| Linux Interfaces: | External | This category includes all | | >| System calls | | of the different Linux | | >| (structure, | | interfaces that the lx brand | | >| semantics, and | | emulates. | | >| calling conventions) | | | >| /dev (names and | | | | >| major/minor #s) | | | | >| /proc | | | | >| signal numbers | | | | >| error numbers | | | | >| | | | | >| AT_SUN_BRAND_BASE | Project private | Additional AUX vector flags | | >| AT_SUN_BRAND_LDDATA | | used to convey brand | | >| AT_SUN_BRAND_LDENTRY | | information to the Solaris | | >| AT_SUN_BRAND_BRANDNAME | | linker | | >| AT_SUN_BRAND_PHDR | | | | >| AT_SUN_BRAND_PHENT | | | | >| AT_SUN_BRAND_PHNUM | | | | >| AT_SUN_BRAND_ENTRY | | | | >| | | | | >| config.xml (*) | Project private | Brand definition | >| platform.xml (*) | Project private | Virtual platform definition | >| | | | >| struct modlbrand | Consolidation | kernel/brand module | | >| | Private | linkage interface | | >| | | | >| struct brand | Project private | kernel/brand configuration | >| | | interface | >| | | | >| struct brand_ops | Project private | kernel/brand operational | >| | | interface | >| | | | >| struct brand_mach_ops | Project private | Arch-specific kernel/brand | | >| | | operational interface | | >| | | | >| struct brand_attr | Project private | userspace/kernel interface | >| | | | >| struct | Project private | userspace/kernel interface | | >| lx_brand_registration| | | | >| | | | | >| rd_helper_ops_t | Consolidation | librtld_db.so helper plugin | | >| | Private | interface | | >| | | | >| brand_open() | Project Private | libbrand.so.1 is a new | >| brand_close() | | library for parsing the | >| brand_is_native() | | BrandZ .xml files | >| brand_get_boot() | | | >| brand_get_halt() | | | >| brand_get_initname() | | | >| brand_get_install() | | | >| brand_get_modname() | | | >| brand_get_postclone() | | | >| brand_get_verify() | | | >| brand_platform_iter_gmounts() | | >| brand_platform_iter_lmounts() | | >| brand_platform_iter_devdir() | | >| brand_platform_iter_link() | | >| | | | >| zonecfg_get_brand() | Contracted | Added to libzonecfg.so.1 | >| zone_get_brand() | Project private | | >| | | | >| zonecfg(1M) | Evolving | Added -B option | >| | | | >| zoneadm(1M) | Project private | Added -f (force) option to | >| | | mount and boot commands. | >| | | Added "brand" column to | >| | | verbose "list" output. | >| | | | >| zonecfg(1M) | Evolving | Added -B option | >| | | | >| lockd(1M) | Consolidation | Added -P option to indicate | >| statd(1M) | Private | portmapper usage | >| | | | >| libnsl(3LIB) | Consolidation | Add __use_portmapper() to | >| | Private | resurrect old portmapper | >| | | support | >| | | | >| streamio(7I) | Evolving | Add support for TIOCSCTTY, | >| | | TIOCNOTTY, TIOCSETLD, | >| | | and TIOCGETLD | >| | | | >| uucopy(2) | Evolving | Added to libc.so.1 | >| | | See design doc: 3.5.2 | >| set_setcontext_enforcement(3C) | | >| | Consolidation | Added to libc.so.1 | >| | Private | See design doc: 3.6.2 | >| setsigacthandler(3C) | Consolidation | Added to libc.so.1 | | >| | Private | See design doc: 3.6.1 | | >| | | | >| lx_install(1M) | Evolving | Invoked by zoneadm(1M), but | >| | | options are user-visible | >| | | | >| lx-syscall(7D) | Evolving | Linux syscall provider | >| | | | >| lx_ptm(7D) | Project private | Linux pty master driver | | >| | | | | >| ldlinux(7M) | Project private | STREAMS module that provides | | >| | | Linux termio(7I) semantics | | >| | | | | >| lx_afs(7D) | Project private | Linux automounter support | | >| | | | | >| lx_audio(7D) | Project private | Layered driver to convert | | >| | | Linux semantics to Solaris | | >___________________________________________________________________________ > > (*) The DTDs for the config.xml and platform.xml files are included > with the case materials. > >14. What are its other significant internal interfaces > inter-subsystem and inter-invocation)? > > Please see the design doc for these details. > >15. Is the interface extensible? How will the interface evolve? >- How is versioning handled? > > The interface between the kernel and the brand module is extensible > and versioned, as described in section 2.2.1 of the design > document. The interface between the lx brand library and the lx > kernel module is also versioned, as described in section 3.3.2 of > the design document. > >- What was the commitment level of the previous version? > N/A > >- Can this version co-exist with existing standards and with earlier > and later versions or with alternative implementations (perhaps by > other vendors)? >- What are the clients over which a change should be managed? >- How is transition to a new version to be accomplished? What are the > consequences to ISV's and their customers? > > Depending on the nature of the change, it is possible that the > BrandZ framework, and the kernel modules and brand libraries > provided by any brands, will all need to be upgraded at the same > time. All of these components (for Sun-distributed brands) are > part of the ON consolidation, and their interfaces are Project > Private, so managing these changes can be handled in the same > fashion as any Solaris patch. > > Since the Linux kernel and the GNU libc are maintained by different > groups of people, and since they are built and delivered > independently, the interface between the two is significantly more > stable than the interface between the Solaris kernel and our libc. > Since the BrandZ project emulates that interface, this stability > works to our benefit. > > Looking ahead, we anticipate that any future Linux brands (e.g., > for SUSE, Red Hat 4, etc.) can be incorporated in the 'lx' brand. > We expect to have to add functionality to the 'lx' brand to support > newer Linux distributions, but we do not expect there to be > significant incompatibilities introduced by this new functionality. > This means that we expect to be able to support RHEL-3 and RHEL-4 > zones simultaneously with a single 'lx' brand kernel module. > > We do not intend to support the upgrade of an installed Linux zone > from one Linux release to another. If it turns out that this > functionality is relatively low-risk to add, we will do so, but > that is not part of our current plan. > > When this product is initially released, the documentation will > make it clear that this upgrade functionality should not be > expected in future releases. The document will also include "best > practices", showing how a Linux zone should be configured to allow > a zone to be uninstalled and re-installed with a newer Linux > distro, without losing applications or data. > >16. How do the interfaces adapt to a changing world? > >- What is its relationship with (or difficulties with) multimedia? > 3D desktops? Nomadic computers? Storage-less clients? A networked > file system model (i.e., a network-wide file manager)? > > N/A > >17. Interoperability > >- If applicable, explain your project's interoperability with the > other major implementations in the industry. In particular, does > it interoperate with Microsoft's implementation, if one exists? > > N/A > >18. Performance > >- How will the project contribute (positively or negatively) to > "system load" and "perceived performance"? > > This project will have no impact on Solaris performance. The > presence of a Linux zone on a system will not impact the > performance perceived by any Solaris zones. > >- What are the performance goals of the project? How were they > evaluated? What is the test or reference platform? > > The project must have no performance impact on Solaris benchmarks. > > For some small set of Linux benchmarks, our emulation environment > will impose no more than a 10% performance penalty over the same > benchmarks running natively under Solaris on identical hardware. > The benchmarks will include SpecJBB, mysql benchmarks, and one or > two others. We are working with the Performance PIT team in > Ireland on this evaluation. > > This performance goal was validated by surveying OS Ambassadors and > customers. > >- Does the application pause for significant amounts of time? > Can the user interact with the application while it is performing > long-duration tasks? > > N/A > >- What is your project's MT model? How does it use threads internally? > How does it expect its client to use threads? If it uses callbacks, > can the called entity create a thread and recursively call back? > > We do not use threads ourselves, but we do support multithreaded > Linux applications. See section 3.5.1 of the design document. > >- What is the impact on overall system performance? What is the > average working set of this component? How much of this is > shared/sharable by other apps? > > There will be no impact on overall system performance. There is no > opportunity for sharing in this release, as we only support the > whole root model of zone installation. > >- Does this application "wake up" periodically? How often and under > what conditions? What is the working set associated with this behavior? > No > >- Will it require large files/databases (for example, new fonts)? > No > >- Do files, databases or heap space tend to grow with time/load? What > mechanisms does the user have to use to control this? What happens to > performance/system load? > > No > >19. Please identify any issues that you would like the ARC to address. > > - How should the SFWrpm package be made available to customers? > > - Is the filesystem layout used by the BrandZ framework and the lx > brand reasonable? (see section 4.2 of the design doc) > > - Even though there are no real clients for it, should we integrate > the SPARC support, along with a dummy 'stub' of a brand for > testing? > >20. Appendices to include > >- One-Pager. >- Prototype specification. >- References to other documents. (Place copies in case directory.) > > --Boundary_(ID_CgRMzOLcCXHNfdF4zYQ3pQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT All,

Final materials have been put into the final.materials directory:

-rw-rw-r--   1 ss146556 sacmail    37072 Jul 13 11:53 20_questions
drwxrwsr-x   2 ss146556 sacmail      512 Jul 13 11:53 ./
-rw-rw-r--   1 ss146556 sacmail    26625 Jul 13 11:53 commitment_comments
-rw-rw-r--   1 ss146556 sacmail   339630 Jul 13 11:54 design.pdf


- Sherri
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sherri Shieh
Program Manager, Systems Architecture
Sun Microsystems, Inc.
Phone: 650-786-5245/x85245
Email: Sherri.Shieh@sun.com    
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Nils Nieuwejaar wrote: 
Hi,

Attached are our responses to all of the issues/questions raised during the
BrandZ commitment review.  I am also attaching updated versions of our
design and 20-questions documents, both with changebars.  All other docs
are unchanged since the commitment review.

Our man pages are in the final editing stages now.  If desired, I can
submit those to be added to our case directory when they are finished.

To fully address the issues raised during the review, we still need to file
two fast track cases: one covering our changes to the pkg tools, and one
for the EOL of lxrun.  Both cases are currently drafted and out with
individual PSARC members, awaiting comments and then formal submission.

During the commitment review, PSARC decided that there was no need to have
a final review for this case.  They/you just wanted to see the responses to
the new issues, and to review the updated documents, before voting.

Assuming there are no significant new issues raised offline, when should we
expect this vote to take place?  Even if there is no review planned, I
would like to dial into the meeting to answer any last-minute questions
people may have.

Thanks,
   Nils

  

  
==============================================================================
Commitment: BrandZ: Support for non-native zones (2005/471)
Submitter: Nils Nieuwejaar
Owner: Ed Gould
Intern: Alan Hargreaves



SUMMARY
=======
* Advice to the project team: brand.dtd.1 - there might be something simpler for this issue
* /opt/sfw/bin/lxrun: make this a seperate fast track
* Strongly advise: make /opt/sfw/bin/lxrun go away

ISSUES
======
jdc-0	What's changed since inception?

* Everything that has changed is in the issues from inception.

jdc-1	What exactly does the name "lx" mean?  I'm worried we're
	headed into a confusing forest of "lx-ubuntu" and "lx-2.6"
	(i.e., both distribution-based and kernel version based
	brands) in the future.

* The project team chose LX instead of Linux - it seemed unwise to choose
  Linux to be named in the branding. LX is the team's way of delivering
  Linux support.
    

Specifically, we were concerned about possible trademark issues. 

We emulate the interface between the kernel and glibc, and that interface
is relatively stable across distributions and kernel versions.  We expect
that any Linux distribution we support will be able to fit into the single
'lx' brand.  We could conceivably have to add distro-specific or
kernel-specific operations, but those would be run-time decisions
implemented within the single 'lx' brand.

  
* Suggestion: remove the what the future is out of the design doc -
  should at least mention the concern of the future in the document
    

Done.  The design doc still mentions that Debian works with the existing
brand, but drops any discussion of support for future distributions.

  
jdc-2	What's the point to supporting RHEL3 and the 2.4 kernel?  It
	seems that RHEL3 is several years out of date and 2.6 is
	pretty far along.  RHEL3 is older than FC0.94, and they're on
	FC5 now.
    

We are deliberately targeting an older version of Red Hat to minimize any
churn in the platform we are emulating.  Trying to support Red Hat 5 would
require a substantial investment in ongoing, pro-active support.  Red Hat 4
would be a reasonable compromise, but it would delay our delivery by at
least another 6 months.  Red Hat 4, including support for 64-bit
applications, would be a logical follow-on to this project should OPG
decide that there is sufficient demand to fund the work.

  
jdc-3	glibc-2.3.2 is old and still has executable stacks (potential
	security problem).  More importantly: what do we (or don't we)
	tell customers about the security of BrandZ-hosted Linux on
	Solaris?
    

For compatibility we have to allow Linux applications to run with
executable stacks, so those applications are vulnerable to any security
holes that are opened by those stacks.  However, since you are running
inside a zone, any damage would be confined to that BrandZ instance.  A
compromised zone will not be able to bring down the system, and will
neither have access to, nor be able to damage, applications or data in
other zones.

Considered more generally, a BrandZ-hosted linux environment will be
subject to any security holes in the Linux user-space.  However, it will
not be vulnerable to any security holes that depend on kernel support or
kernel bugs.  This would arguably make a BrandZ-hosted RHEL 3 environment
more secure than a native RHEL 3 environment.

  
jdc-4	Are users dependent on reading ext[23]fs data?  How usable is
	migration without file system support?  What else is missing
	if we want people to migrate?

* Supporting linux file systems is not on the roadmap and project team
has made it clear to customers. This doesn't seem to be a huge obstacle
about having to deal with migration for Linux.
    

Support for Linux file systems is something that we do occasionally get
asked about, but so far we haven't run into a single customer who
considered this a necessary feature.  In fact, I don't believe we have
found a single customer that was surprised that this support would not be
available.

Developing an ext[23]fs VFS module for Solaris would be a useful part of an
overall Linux-to-Solaris migration story.  That functionality is orthogonal
to the emulation we are developing here, and is beyond the scope of this
project.

  
jdc-5	Is the "s10" brand included in this project the right
	architectural direction to take the system, and has the Zones
	team been involved in this decision?  Could we ever really
	support old releases in zones?  (And can't and don't users
	_already_ do this more simply by hacking uname?)  (Merely
	changing the uname value and calling it an "s10 branded zone"
	seems like a dangerous bait-and-switch to me.)

* The S10 brand is only designed for testing. This isn't going to be sent
to customers whatsoever. This is not a real Solaris 10 environment (won't
be shipped).
    

This brand is specifically designed to exercise the BrandZ framework on
SPARC-based systems - as requested by PSARC during our inception review.
It can also be used to exercise the framework on x86/amd64 systems without
adding any Linux software.

  
jdc-6	For the system calls that are missing, do we have an idea of
	what might be affected?  (Have we done searches?)  In
	particular, what Linux things are broken by lack of chroot
	support?
    

The absence of chroot() will affect some network services (e.g., ftpd and
httpd) which may be configured to run within an alternate root environment.
These services are typically configured this way to minimize the potential
damage should the service be compromised.  It seems reasonable to argue
that we have already achieved this level of compartmentation by running the
service within a zone.

  
jdc-7	20q9: truss and apptrace aren't mentioned here.  If mdb
	understands brands, should dbx also understand them?

* nits - truss has been updated and apptrace will soon.
    

To be clear: truss has been updated to recognize the new system calls; it
has not been updated to understand and display the Linux system calls
issued by the application.  We have added an lx-syscall DTrace provider to
make that information available.

dbx does not currently work, but this appears to be a bug rather than a
fundamental limitation of the design.  This is still under investigation
and is being tracked as:
	6445248 dbx cannot grok Linux processes

  
jdc-8	Mdb's kernel-space dcmds (e.g., ::ps, ::pgrep, and
	::threadlist) should probably be enhanced to understand
	brands.

* nits

jdc-9	Is there an Install-related project on which this one depends,
	or does this project also deliver the necessary Install
	changes to skip over branded zones?  (If it's the latter, then
	zonecfg_get_brand() is probably Contracted.)
    

I have changed it from "Project private" to "Contracted Project private".
The contract has been signed and submitted.

  
* Live upgrade doesn't run zones. The packaging pack tools will go into
  the install gate. There is an RFE file that the project team and link to
  this PSARC case. As for live upgrade, the p-team doesn't know what to do
  about that right now. (ARC is talking about Zulu)
    

The RFE for this change is:
	6342179 packaging tools need to be brand aware

A PSARC fasttrack has been drafted and is being circulated for comment
prior to being officially submitted.

  
jdc-10	Now that there are entries in zone_platform.dtd.1 for the
	various mounts and links that need to be created, can the
	hard-coded lists in zoneadmd be refactored into these more
	flexible files?  (If that's not this project, then there's
	probably advice here to create one so that the result is a
	complete design.)

* The hard coded device names will be made into the flexible files.
    

All the the device and privilege lists currently hardcoded into the zones
utilities have been moved to the platform.xml and config.xml files that
describe the native brand.

  
jdc-11	What does TIOCSETLD actually do on Solaris?  (Shouldn't that
	be TIOCSETD rather than TIOCSETLD?  The latter doesn't appear
	to be in the Linux kernel sources, but 20q mentions the
	former.)  How can line disciplines be used on a STREAMS-based
	system?

* This should be put into the interface table...

jdc-12	Audio support seems clumsy.  Why is a separate attr needed?
	Doesn't export of /dev/dsp to the zone imply that audio is
	accessible?  If attributes are needed, shouldn't they be part
	of the device import?

    
/dev/dsp is always present on Linux systems, and in Linux zones, regardless
of whether there is any audio hardware available.  Neither /dev/dsp nor
/dev/mixer exist on Solaris, so they are not part of the standard device
import list.

There is no notion of a device-specific attribute, which is needed to
support systems with multiple audio devices, in the zone's infrastructure
now.  Adding such a capability would have required an extensive overhaul of
how devices are configured and managed.

The multiple-devices problem could also have been addressed by adding a
Linux-specific "audio resource".  Unfortunately, the original design of
zonecfg and libzonecfg was to hardcode all the resource types into the
library and utility, and to hardcode their names into the parser.  Adding
brand-specific resources would have required an extensive redesign of this
tool.

Rather than redesign the core of the zones configuration tools simply to
solve one Linux corner case, we chose to use the generic attributes
mechanism to support audio devices.

For single-device systems, adding an audio device is a trivial task.  Most
of the complexity in this configuration is only encountered when working
with systems with multiple audio devices.  This has been made clearer in
the design document.

  
* Please talk to the trusted Solaris team about the audio issue.
    

We have done so.  The concerns that Trusted Solaris has with branded zones
run much deeper than just the audio device.  

The zone/label management applications that are running in the global zone
are not prepared to deal with Linux branded zones.  These applications in
the global zone are aware of all other zones (and their associated labels)
on the system.  Also, these applications expect to be able to fork and
zone_enter() different zones based of their label types.  Without making
these applications brand aware and modifying these applications so that
they can run successfully in branded zones it seems unsafe to allow branded
zones on a system where labels are enabled.

As a result, we will not be able to support branded zones on trusted
systems where labels are active.  This will be made clear in the BrandZ
documentation.

  
jdc-13	20q19: this project is probably strictly dependent on
	integrating rpm into the WOS.  (The SPARC question here looks
	like a marketing or business issue, but I think it'd look bad
	to customers if we didn't even support our own products.)

* The project team is using the exisiting linux version of the RPM.
    

For the first stages of install we use rpm2cpio(1), which is already
delivered with Solaris.  Once we have installed enough Linux packages to
boot the zone, we use the Linux rpm(1) tool to complete the installation.

  
jdc-14	nit:20q13: this case _exports_ the things listed in the import
	table.
    

Fixed.

  
jdc-15	design?:nit?:brand.dtd.1: why are there function names here?
	Why not just specify a particular shared library interface
	that all brand libraries must implement -- just like the
	_init/_fini/_info functions used by kernel modules?  And why
	have the name of the shared object here?  Why not just have
	both verify() and validate() in the same object with some
	well-known (brand-name-based) file name?  (There are a lot of
	degrees of freedom here, and it looks like a lot of them lead
	to accidents.)

* Advice to the team - there might be something simpler here....
    

There are no function names in the config.xml file.  The file contains:

	- The name of the kernel module needed to support the brand.  Some
	  brands (e.g., a Nexenta brand) would not require a kernel module.

	- The binary to use for init(1M).  This is determined by the system
	  being emulated, so we cannot dictate what it will be called.

	- The script to use for installing the zone, and those to be run
	  when the zone is booted, halted, and cloned.  We could impose a
	  naming convention on these scripts, but that seems unnecessarily
	  restrictive.  As an example, we currently use 'lucreatezone' as
	  the install tool for native zones, which would not fit into any
	  brand-specific naming scheme.

	- The names of the external programs to run to verify the zone at
	  configuration and boot times.  These could probably be delivered
	  in a well-known shared object, but that would prevent the brand
	  developer from using script-based verification.

It is certainly accurate to say that there are a lot of degrees of freedom
here.  In the cases of init(1M) name and the install program, this is
needed to avoid adding an extra layer of indirection.  We could impose a
naming convention on the other fields, but that would leave us with a
seemingly arbitrary distintion between 'imposed' and 'optional' names.

  
jdc-16	What is the behavior of cloning if no post-clone script is
	present?
    

The initial stages of the clone process are the same for every brand: the
zone is copied from the source to the destination.  The postclone script is
called after the copy successfully completes.  For native zones, the
postclone script mounts the zone and run sys-unconfig.  For Linux zones, we
do not provide a postclone script, so no further action is taken after the
copy completes.

This is now addressed in section 2.1.5 of the design document.

  
jdc-17	Does /opt/sfw/bin/lxrun go away?

* EOL?
* Make this a sperate fast track
    

A PSARC fasttrack to EOL lxrun has been drafted and passed to the BrandZ
case owner for official submission.

  
gcs-5	Section 3.7.4 (Device minor nodes and paths):  Trails off into
	"If we decide to do this, then...".  What specifically do you
	plan to deliver?  (That is, reword the spec to clarify the
	boundary between this project and possible future extensions.)
    

The speculation has been removed from the design doc, and it now reflects
what we are delivering with this project.

  
gcs-6	Section 3.7.5.2 (ptys):  Case dependency on 2003/246 [fs-driven
	device naming]?  If so, it seems that your life would be
	simplified a bit here.

* There is overlap between the 2 cases....
    

2003/246 (aka "devnames") will make the BrandZ implementation simpler, and
we are working with the devnames project to ensure that we will be able to
merge with them easily.  We intend to putback to Nevada at least one build
after them, to allow us time to resync and thoroughly test prior to our
integration. 

There is no strict dependency here.  If the devnames project were derailed,
we could putback the implementation we currently have.

  
gcs-7	interface table incompleteness:  changes to mdb (via
	librtld_db.so); layered drivers (e.g., audio char dev);
	lx_autofs; etc.  (Suggest case owner and project team perform
	audit.)

* Project team will update this.
    

Fixed.

  
gw-3	Solaris Audit
	Sorry, I missed this at the inception ;-{
	There seems to be two new system calls at the Solaris level.
	How are they captured in the audit subsystem?
    

This is an operation that takes place entirely within the address space of
a single process, so uucopy(2) is not audited.

The brandsys(2) call is captured using a new "AUE_BRANDSYS" event.  An
audit record is issued at the start of the call.  The brand architecture
does not define any structure to the call.  Rather than trying to impose
some structure on it within the audit subsystem, we simply record all the
arguments to the call.  In theory we could allow brands to supply routines
that interpret their brandsys(2) for the audit subsystem, but that seems
excessively complex.  Alternatively, we could add brand-awareness to the
tools that post-process the audit records.

  
	While the lx branded zone will not be participating in Solaris
	Auditing, the globalzone may be auditing for all zones.
	Is anything done as part of lx branded zone startup to reset
	the audit state?  (I don't recall if native zone startup
	does anything.)

	You should probably test with auditing turned on -- I'll
	be happy to consult.
    

Processes running in an lx-branded zone do not have their Linux system
calls audited.  Otherwise, they are subject to all the standard auditing.
For example, Linux process creation/exit events are captured as for any
other process.  The Solaris system calls that the brand library uses to
emulate the Linux system calls are subject to auditing.

The only restriction is that the Solaris audit processing tools cannot run
inside the Linux zone, so the audit records must be consumed by tools
running in the global zone.

  
gw-4	20Q 6 "solaris 10" brand
	Should this track the native system?  Is there an intent to have
	an S10 brand that carries on into S11 days?

	Should other < S10 brands be built?

* It is not possible to have older brands of Solaris available.
* The S10 brand should be able to run on S11...
    

As mentioned elsewhere, this is not a real S10 brand.  It is a tool for
testing, which will not be distributed.  We are actually going to turn this
into a "Solaris n-1" brand, so we can use it when we integrate into the S10
update tree.  On S10, uname will return "Solaris 9", on Nevada it will
return "Solaris 10".

  
gw-5	What issues might arise from branded suid (or uid 0 admin actions)
	not having full privileges?
    

The only significant issue we have enountered thus far arises from the
inability to create device nodes within a Linux zone.

This only comes up during the initial zone installation.  To address this
issue, we have a special "install mode", in which mknod(2) translates EPERM
and EACCESS into SUCCESS.  The device nodes aren't actually created, but
the device package is recorded as being successfully installed, satisfying
the dependencies other packages have on it.

  
How will any failures be documented for CUs?
    

Linux zones are documented as having "all the restrictions as native
Solaris zones".  Attempts to perform an operation that is disallowed will
fail with the appropriate error code.

For example, attempting a mknod(2) inside the zone fails with EPERM;
	bash-2.05b# mknod /tmp/disk b 120 120
	mknod: `/tmp/disk': Operation not permitted

  
gw-6	Design 3.8.1.4 libnsl plugin
	This team should likely contact the Sparks team to ensure
	compatibility going forward.
    

Done.  We talked with the Sparks team before doing the implementation, and
hey didn't foresee any issues.  After this issue was raised, we went back
to the team to verify that we are still OK.  They said: 

	"I did not do a thorough code review, but everything looked
	straight forward, and I don't anticipate any issues with the work
	we are doing in sparks at this time."

  
gw-7	Design 3.8.1.6 privileges
	Why are the file_dac privileges needed?
    

The NFS daemons (lockd and statd) run as non root processes in the linux
environment, but they need to be able to create and destroy files in:

         /native/etc/svc/volatile
         /native/var/statmon

  
eg-12	design 2.1.5
	What does the Linux kernel actually do about signals to init?  Why are
	we speculating here?
    

We have been trying to locate somebody who is already tainted by looking at
Linux source, and who has the time and expertise to investigate the issue.
Thus far, we haven't had any luck.  We will continue to pursue this, but
regardless of the answer no significant design or code changes will be
requried.

  
eg-13	design 2.2.1
	How is brand code different from any LKM WRT stepping on the kernel?
    

It isn't any different.  There is always a risk that somebody will attempt
to load a broken or out-of-date kernel module, and that it might do random
damage to your system.  By attempting to identify these modules at
load-time, we are simply adding a thin layer of protection.

  
eg-14	design 2.2.2
	Why are there HW specific vectors that are non parallel constructions?
	When do they get called?  When is the implementation of them likely to
	change?
    

The mechanisms used to enter the kernel differs between platforms, so the
vectors we use to represent interpositions on these mechanisms also have to
differ.  The vectors will only change when a new kernel-entry mechanism is
introduced.

In theory we could provide just a single 'system call entry' vector, which
is identical across platforms, and which has different internal code paths
depending on the specific mechanism used to enter the kernel.  This would
simplify the ops vector at the cost of increasing the complexity and
overhead of implementing the interposition mechanism. 

In addition, there is an x86-specific callback mechanism to update the
segment registers.  This callback is called by the x86-specific
fixsegregs() function any time the "general" registers are reset -
generally on a context switch.  There is no parallel callback in the SPARC
vector simply because the SPARC architecture does not have anything similar
to the x86 segment registers.

  
wes-13	delegated administration of solaris-specific capabilities
	(forward-looking question)

	zfs allows for chunks of a pool's namespace to be 
	delegated to a zone's administrator.  
	crossbow is talking about doing something similar for 
	network interfaces.

	These undoubtedly won't be the only type of administrative
	delegation we'll allow for.  Are branded zones forever
	second-class citizens with respect to these capabilities?  
	Do we need to put this into /native ?
    

Linux-branded zones will always be second-class citizens in many ways.  As
our real goal is to increase Solaris adoption, using BrandZ as one part of
a migration strategy, we view this as a feature rather than a bug.

To address these specific issues: ZFS delegation will not work within a
Linux zone.  Given sufficient customer interest, we could possibly support
the ZFS utilities, but it would take a significant amount of engineering
work, and would violate our "one binary type per zone" model.

Supporting network delegation is significantly more feasible.  By emulating
the ioctl()s needed to perform network configuration tasks, we should be
able to support network delegation using Linux configuration tools.  This
would not be a trivial engineering effort, but it would certainly fit
within the overall BrandZ model.

  
wes-14	random observation: the "fake" solaris 10 brand might prove to 
	be useful.  (see 6334395/6334928, but not immediately after lunch)

wes-15	brands(5): "Optionally, a brand can provide a boot routine" ?
	who's the target audience of this man page?  it provides an 
	overview of the implementation changes, but doesn't provide
	enough detail to let someone plug into or customize the interface.
	(for instance, I don't see enough detail about how to
	customize the post-clone or pre-boot script).
    

The audience for all of our man pages is intended to be the users of
systems with branded zones - not brand developers.  We will go though our
man pages and ensure that we are providing the right level of detail.

  
wes-16 	design.pdf 3.6: what, if anything, would prevent solaris from
	providing 32 real-time signals instead of the current 8? 
	(in other words, if this does become an issue, how bad is it?)
    

We would have to increase MAXSIG from 48 to 72.  This would increase the
number of words needed to repesent a signal mask from 2 to 3.  This
increases the sizes of size of user_t, proc_t, and kthread_t.  These
changes are all to internal kernel structures, so there is no issue with
breaking user-space compatibility.

We spoke with one kernel engineer who tried to increase MAXSIG some time
ago, and he quickly discovered that the current size is baked into
assumptions throughout the kernel.  Although he couldn't recall the
specific breakages he ran into, he did recall that they were extensive and
often subtle.

So, this is a change that we could make if we needed to, but it seems to be
risky enough that we should avoid it if we can.

  
wes-17	design.pdf 3.7.2: does the device major/minor mapping mechanism
	avoid false positives?  You mention major 136 being known well-known
	to linux apps; for instance, on a couple x86 systems here, 
		ls -lLR /dev /devices | grep 136
	turns up a collision with "keysock"; amusingly, making keysock 
	zone-aware is on my TODO list..
    

There is no opportunity for false positives.  The Solaris system calls used
by the brand library always return Solaris dev_t values.  We translate the
dev_t value into the Solaris device name, and then use the device name to
derive the Linux dev_t values.   So, the fact that major number 136 may
reflect two different devices on Solaris and Linux does not pose any
difficulty.

  
wes-18	design.pdf 3.7.5.4: have you talked with the Trusted Extensions folks
	about what they're doing with respect to audio devices in zones?

* piggyback onto jdc-12


wes-19	3.8.1: NFSv1?  I thought solaris just supported v2..v4?
    

Correct.  This is an error in the doc.

  
sz-1	nit: design doc 2.1.3 non-intuitive rule
		< match="zconsole" name="console" />
	can we do zconsole -> console?
    

I don't think I understand this question.  I'm not sure whether the concern
is with the syntax, with the specific device names, or something else.

I don't know if this helps or hurts, but this line is now:

        <device match="zcons/$zname/zoneconsole" name="console" />

  
sz-2	Impact on Zones upgrade -- how do you ensure lx zone continues
	to work when Solaris is upgraded?
    

The zones test suite, which is run as a regular part of the PIT suite, will
be extended to include testing of lx-branded zones.

  
sz-3	Solaris 10 brand: is it going to track S10 updates?
    

No.

  

1. What specifically is the proposal that we are reviewing?  

    - What is the technical content of the project? 

	BrandZ is a framework that allows for the creation of Branded
	Zones, which are zones that run a non-native userspace on a Solaris
	system.  Each non-native environment is implemented by a "Brand".
	
	'lx' is the initial brand we are delivering, and it supports the
	execution of a Linux userspace environment by emulating the
	following Linux kernel interfaces: system calls, /proc, some of
	/dev.  The lx brand specifically supports the interfaces provided
	by the 2.4.21-32.ELsmp kernel, which is the version used by Red Hat
	Enterprise Linux (RHEL) 3.x.

	The product, combining the framework and initial brand, is called
	"Solaris Containers for Linux Applications".

	The technical details of the project are encapsulated in the design
	document, which is available online at:
		http://opensolaris.org/os/community/brandz/design
		
	A copy of the design document is included in the materials for this
	case.

    - Is this a new product, or a change to a pre-existing one?

	This is a change to Solaris. As described below, it will have patch
	binding.

    - If your project is an evolution of a previous project, what
      changed from one version to another?

	This project is an evolution of the Janus project (PSARC 2003/445),
	and it differs from Janus in two fundamental ways.

	    1. BrandZ is tightly tied to the zones model introduced in
	       Solaris 10 (PSARC/2002/174).

	       Janus required a new administrative tool (brandadm) to
	       manage brands, while we extend the existing administrative
	       model.  More significantly, Janus introduced a complex and
	       non-intuitive 'pathmapping' mechanism to avoid namespace
	       conflicts in the filesystem, while we simply use the
	       namespace isolation inherent in the zones-based approach.

	    2. Our emulation is almost entirely performed in userspace,
	       following the approach introduced by the SunOS Binary
	       Compatibility Project.  This approach reduces the amount of
	       the code introduced into the kernel, limits the interactions
	       between the brand support code and Solaris proper, and
	       increases the observability and debuggability of the brand
	       support code.

	    3. While Janus was strictly limited to supporting Linux
	       applications, The BrandZ infrastructure is designed to be
	       flexible enought to allow for the creation of distinctly new
	       brands.  Possible brands include Solaris variants (whether
	       completely different versions or simply with different 
	       userspace components), FreeBSD, or Apple's Darwin.

    - What is the motivation for it, in general as well as specific terms? 
    - What are the expected benefits for Sun?   

	Much of the focus of the Janus project, and this one in its early
	days, was on customers that are trying to transition from Linux to
	Solaris, but have a number legacy Linux applications that are
	preventing the switch.  Linux emulation was viewed as a way to help
	them make the switch to Solaris before their full software toolset
	was available.  Since that time, ISVs have been porting their
	applications to Solaris on x86 in record numbers, somewhat reducing
	the need for this transitional tool.  There are still many
	customers for whom this will be useful, but their interest is now
	as likely to be on in-house applications as on ISV applications.

	Another area which is ripe for exploitation is consolidation.  A
	monocultural example would be a customer that wants to consolidate
	multiple Linux applications onto a single machine, but is not sure
	how, or if, they can cohabitate peacefully.  This project allows
	each application to run in its own Linux zone, eliminating those
	issues.  Alternatively, a customer may have a mix of Linux and
	Solaris applications, and not want to maintain two different
	machines.  This use case is already being explored by an EDA group
	in Sun.

	Another interesting market is the developer community.  By enabling
	Linux applications on to run on Solaris, developers are able to use
	Solaris tools such as DTrace to develop, debug, and tune their
	applications.  This use case has attracted the most immediate
	attention from customers, as it brings the most benefit with the
	least risk.

- By what criteria will you judge its success?

	- For correctness and completeness, we will be using the following
	  test suites: LSB, LTP, connectathon, and the zones test suite.
	  Note: we will be using the LSB test suite to evaluate the quality
	  of our implementation, but we do not anticipate being LSB
	  compliant.  We will provide a list of the specific areas in which
	  we are non-compliant.

	- Surveying SEs and OS Ambassadors to gauge adoption rate.

	- Growth of the BrandZ OpenSolaris community and activity on the
	  BrandZ discussion list.

2. Describe how your project changes the user experience, upon
   installation and during normal operation.

	A Solaris user will see a single column added to the output of the
	'zoneadm info' command.  There will be no other visible changes to
	the installation or operation of their systems.  The BrandZ
	functionality is only perceptible when explicitly invoked by the
	user.

- What does the user perceive when the system is upgraded from a
  previous release?

	There is no previous release of BrandZ.  When upgrading from a
	previous version of Solaris, the only visible change to the user
	will be the additional output to "zoneadm info".

3. What is its plan?

- What is its current status? Has a design review been done?  Are there 
  multiple delivery phases?

	Design and implementation of BrandZ and the lx brand have been
	underway for 10 months, and the bulk of the core functionality is
	nearing completion.  There are many refinements to complete and
	loose ends to tie up.  We are transitioning to an OpenSolaris-based
	development model and have released an initial snapshot on
	opensolaris.org.

	A design review was done on 8/29/05.  Detailed notes from the
	design review are available:
		http://perf.eng/twiki/bin/view/BrandX/DesignNotes

	A condensed list of the specific actions/changes the came out of
	the review is included with the case materials.  As items are
	completed, they are noted here:
		http://perf.eng/twiki/bin/view/BrandX/DesignActions

	We are currently committed to just a single delivery into Nevada
	and into a Solaris 10 update.  There are numerous opportunities to
	update and extend this project in the future, but no commitment to
	do so.

4. Are there related projects in Sun?  

	This project extends the zones infrastructure and modifies the zone
	management commands.  We are in regular contact with the zones
	engineering team and management to ensure that we are not working
	at cross-purposes.  After integration, we expect that the BrandZ
	features will be maintained as a first-class component of the zones
	infrastructure.

	This project will affect the zones upgrade project, much of which
	is contained in the Install consolidation.  The extent of the
	interaction appears to be that the packaging, patching, and
	upgrading tools must be aware of the existence of Branded Zones,
	and simply avoid modifying them.  We have discussed this
	interaction with the zones upgrade team, and are in agreement on
	this approach.

	The feature set of this project has some overlap with that of the
	Xen project, which allows a paravirtualized version of Linux to
	boot on the same system as a paravirtualized Solaris.  Some key
	difference between the two projects:
	
		BrandZ only runs the Linux userspace, while Xen runs both
		the Linux userspace and kernel.  So, Xen delivers a higher
		fidelity Linux environment, but it comes at a higher cost.

		Xen requires a custom Linux kernel, while BrandZ does not.

		BrandZ allows users in the global zone to manage,
		manipulate, and examine the processes running in the Linux
		zone.  This includes the ability to use DTrace to probe
		Linux applications.  At least in its initial incarnation,
		the activity within a Xen instance is completely opaque to
		users in the 'dom0'.

	The differences between BrandZ and Xen are largely analogous to the
	differences between zones and partitions on a SPARC server.

5. How is the project delivered into the system?  

- Identify packages, directories, libraries, databases, etc.

	The BrandZ framework is delivered as a set of modifications to the
	Solaris kernel and to the zones utilities.  In addition, it
	delivers a new package (SUNWbrand) containing the userspace support
	needed to parse brand configuration files.

	The lx brand is delivered as two packages: SUNWlxr and SUNWlxu,
	which contain the kernel and userspace components of the brand
	respectively.  A detailed list of these components can be found in
	section 4.2 of the design document.

6. Describe the project's hardware platform dependencies.

- Explain any reasons why it would not work on both SPARC and Intel?

	The BrandZ framework can be applied to both SPARC and Intel.  Since
	the primary goal of this project is to enable the execution of
	x86-based Linux applications, the initial release will only be
	available in Solaris on x86/x64-based systems.  While there is a
	SPARC version of Linux available, there is not sufficient interest
	in it to justify the work required to support it in this project.

	It is our intention to putback both the SPARC and Intel code, along
	with a fake "Solaris n-1" brand.  This brand will interpose only on   |
	the uname(2) system call.  On Nevada, it will always return "5.10"    |
	in the 'release' field, rather than "5.11".  On Solaris 10, it will   |
	return "5.9".  This 'sn-1' brand will allow the framework to be       |
	exercised on both SPARC and Inteal machines.  The zones test suite    |
	will be extended to include tests of this 'sn-1' brand.               |

7. System administration

- How will the project's deliverables be installed and (re)configured?
- How will the project's deliverables be uninstalled?  

	The project's deliverables will be installed using the standard
	packaging mechanism and will be installed by default.  The core
	brand support cannot be uninstalled.  The lx brand may be
	uninstalled by removing the SUNWlxu and SUNWlxr packages.

	Neither the BrandZ framework, nor the lx brand, require any
	administration.

	As is the case for non-branded zones, any branded zones that are
	created will need to be administered.  The key difference is that
	the zones will need to be administered using Linux tools and
	conventions, rather than Solaris.

- Does it use inetd to start itself? 
	No

- Does it need installation within any global system tables?  
	No

- Does it use a naming service such as NIS, NIS+ or LDAP? 
	No

- What are its on-going maintenance requirements (e.g. Keeping global
  tables up to date, trimming files)?

  	None

- How does this project's administrative mechanisms fit into Sun's system
  administration strategies?  E.g., how does it fit under the Solaris
  Management Console (SMC) and Web-Based Enterprise Management (WBEM), how
  does it make use of roles, authorizations and rights profiles?
  Additionally, how does it provide for administrative audit in support of
  the Solaris BSM configuration?

  	N/A

- What tunable parameters are exported? Can they be changed without
  rebooting the system?  Examples include, but are not limited to,
  entries in /etc/system and ndd(8) parameters. What ranges are
  appropriate for each tunable? What are the commitment levels
  associated with each tunable (these are interfaces)?

	None

8. Reliability, Availability, Serviceability (RAS)

	BrandZ and the lx brand will have no measurable impact on boot time
	or any other system performance.  Neither the framework nor this
	brand are expected to have any impact on RAS.

- Does the project make any material improvement to RAS?
	No

- How can users/administrators diagnose failures or determine
  operational state?  (For example, how could a user tell the
  difference between a failure and very slow performance?)

	The state of a branded zone is reported through the existing zone
	administration tools.

- What are the project's effects on boot time requirements?
	None

- How does the project handle dynamic reconfiguration (DR) events?
	N/A

- What mechanisms are provided for continuous availability of service?
	None

- Does the project call panic()?  Explain why these panics
  cannot be avoided.
  	No

- How are significant administrative or error conditions
  transmitted? SNMP traps? Email notification?  

	Errors in the configuation or booting of a zone will be reported
	through the existing zone mechanisms.  Errors within a branded zone
	will be logged using the standard Linux logging mechanisms.

- Does it ever require reboot?  If so, explain why this situation
  cannot be avoided.
 
 	No

- How does the project deal with failure and recovery?
- How does your project deal with network failures (including
  partition and re- integration)?  How do you handle the failure
  of hardware that your project depends on?
- Can it save/restore or checkpoint and recover?  

	This project has no failure requirements, and provides no recovery
	functionality, beyond that provided by Solaris.

- Can its files be corrupted by failures?
	No

- Does it clean up any locks/files after crashes?
	There are no locks or files that need cleaning up.

9. Observability

- Does the project export status, either via observable output
  (e.g., netstat) or via internal data structures (kstats)?
- How would a user or administrator tell that this subsystem
  is or is not behaving as anticipated? 
- What statistics does the subsystem export, and by what mechanism?
- What state information is logged?

	The state of a branded zone is visible through the standard zoneadm
	and zonecfg tools.

	As part of this project, mdb is being enhanced to understand both
	running Linux processes and the core files they generate.  This
	functionality is provided by a brand-specific implementation of
	librtld_db.so.

	The brand support added to librtld_db.so enables the DTrace PID
	provider to probe Linux processes.

	This project includes an lx-syscall provider for DTrace, which
	traces Linux system calls in the same way the syscall provider
	traces Solaris system calls.

- In principle, would it be possible for a program to tune the
  activity of your project?

	No

10. What are the security implications of this project?

- What security issues do you address in your project?

	Branded zones are subject to all of the security restrictions
	imposed on non-branded zones.  We introduce no interfaces or
	functionality that bypass existing security checks.

	The one area in which it could be argued that we are reducing user    |
	security is that we are re-introducing the presence of executable     |
	stacks within Linux zones.  This is required for compatibility with   |
	Linux 2.4.21, in which applications (specifically JVMs) expect        |
	their stacks be executable.  Executable stacks are only available     |
	to Linux applications and only within Linux zones.  Thus, this        |
	change will have no security implications for Solaris applications,   |
	Solaris zones, or the global zone.                                    |

- Please justify the introduction of any (all) new setuid executables.

	N/A

11. What is its UNIX operational environment:

- Which Solaris release(s) does it run on?

	BrandZ will be provided for Nevada and a Solaris 10 update.

- Environment variables? Exit status? Signals issued? 
  Signals caught? (See signal(3HEAD).)

	Environment variables, command line interfaces, libraries, and
	device driver issues are all discussed in the design document.

- Device drivers directly used (e.g. /dev/audio)?

	We do not use any device drivers directly.  As with standard zones,
	we allow some devices to be imported into branded zones.

- Does it use any "hidden" (filename begins with ".") or temp files?  
	No

- Does it use any locking files? 
	No

- Command line or calling syntax:  
  What options are supported?  (please include man pages if available)
  Does it conform to getopt() parsing requirements? 

	See attached man pages.  Change bars are included to highlist added
	functionality.

- Is there support for standard forms, e.g. "-display" for X programs? 
  Are these propagated to sub-environments?

	N/A

- What shared libraries does it use?  (Hint: if you have code use "ldd"
  and "dump -Lv")? 
	libaio.so.1		libavl.so.1                                   |
	libbrand.so.1		libc.so.1                                     |
	libctf.so.1		libelf.so.1                                   |
	libnsl.so.1		libm.so.2                                     |
	libmapmalloc.so.1	libmd5.so.1                                   |
	libnvpair.so.1		libproc.so.1                                  |
	libpthread.so.1		librtld_db.so.1                               |
	librt.so.1		libsec.so.1                                   |
	libsocket.so.1		libsysevent.so.1                              |
	libuuid.so.1		libxml2.so.2                                  |
	libz.so.1		libzonecfg.so.1                               |
	lx_brand.so.1

- Identify and justify the requirement for any static libraries.
	None

- Does it depend on kernel features not provided in your packages and
  not in the default kernel (e.g. Berkeley compatibility package,
  /usr/ccs, /usr/ucblib, optional kernel loadable modules)?

	No

- Is your project 64-bit clean/ready?  If not, are there any 
  architectural reasons why it would not work in a 64-bit environment?
  Does it interoperate with 64-bit versions?

	The kernel portions of the project are 64-bit clean, but the user
	space components are not.
	
	We support the execution of 32-bit applications on both 32-bit and
	64-bit machines, but the version of Linux we currently emulate does
	not support 64-bit applications.  64-bit Linux is still more
	experimental than the 32-bit version, and commercial 64-bit Linux
	applications are still relatively rare.
	
	There are extensive changes in the Linux ABIs for 32-bit and 64-bit
	applications, so adding 64-bit support will require significant
	development work and is being considered as a follow-on project.
	Whether that work is funded will be driven by market demand for
	both BrandZ and for 64-bit Linux applications.

	The BrandZ architecture is designed to support different brands,
	even simultaneously on a single system, so adding this support
	should not require significant changes to anything discussed in
	this case.

- Does the project depend on particular versions of supporting software 
  (especially Java virtual machines)?  If so, do you deliver a private
  copy?  What happens if a conflicting or incompatible version is
  already or subsequently installed on the system?

	No

- Is the project internationalized and localized?

	Yes

- Is the project compatible with IPV6 interfaces and addresses?

	There in nothing in the BrandZ design that precludes or prevents
	IPv6 support, but we haven't had the resources to test it.

12. What is its window/desktop operational environment?

	Neither the BrandZ infrastructure, nor the lx brand, provide a
	GUI or window-based environment.  Branded Zones do not curently
	support framebuffer devices, so X servers may not run inside a
	branded zone.

	Applications within a Branded Zone may communicate with a remote X
	server using the standard X protocols.

13. What interfaces does your project import and export?

The details of each interface may be found in the design document,

_________________________________________________________________________
|                         Interfaces Imported                           |
|_______________________________________________________________________|
| Interface         |  Classification | Comments                        |
|___________________|_________________|_________________________________|
| rpm2cpio(1M) CLI  | External        | Used to install RedHat software |     |
| rpm CLI           | External        | Used to install RedHat software |     |
|                   |                 |                                 |
| Linux statd(1M)   | External        | Used to support NFS locking     |
|    and lockd(1M)  |                 | within lx branded zones         |
|    uid/gid #'s    |                 |                                 |
|                   |                 |                                 |
| glibc ABI         | External        | Used to provide naming services |
|   gethostbyname_r |                 | to Solaris statd(1M) and        |
|   gethostbyaddr_r |                 | lockd(1M) daemons.  See section |
|   getservbyname_r |                 | 3.8 of the design doc.          |
|   getservbyport_r |                 |                                 |
|   openlog         |                 |                                 |
|   syslog          |                 |                                 |
|   closelog        |                 |                                 |
|   __progname      |                 |                                 |
|                   |                 |                                 |
| RHEL 3.x contents | External        | /etc files, rc.d scripts, etc.  |
|                   |                 | which we modify at install time |
|                   |                 |                                 |
| Linux ELF format  | External        | Object file format for Linux    |     |
|                   |                 |     binaries                    |     |
_________________________________________________________________________

___________________________________________________________________________
|                        Interfaces Exported                              |
|_________________________________________________________________________|
| Interface              |  Classification | Comments                     |
|________________________|_________________|______________________________|
| Linux Interfaces:      | External        | This category includes all   |   |
|    System calls        |                 | of the different Linux       |   |
|      (structure,       |                 | interfaces that the lx brand |   |
|       semantics, and   |                 | emulates.                    |   |
|       calling conventions)               |                              |   |
|    /dev (names and     |                 |                              |   |
|       major/minor #s)  |                 |                              |   |
|    /proc               |                 |                              |   |
|    signal numbers      |                 |                              |   |
|    error numbers       |                 |                              |   |
|                        |                 |                              |   |
| AT_SUN_BRAND_BASE      | Project private | Additional AUX vector flags  |   |
| AT_SUN_BRAND_LDDATA    |                 | used to convey brand         |   |
| AT_SUN_BRAND_LDENTRY   |                 | information to the Solaris   |   |
| AT_SUN_BRAND_BRANDNAME |                 | linker                       |   |
| AT_SUN_BRAND_PHDR      |                 |                              |   |
| AT_SUN_BRAND_PHENT     |                 |                              |   |
| AT_SUN_BRAND_PHNUM     |                 |                              |   |
| AT_SUN_BRAND_ENTRY     |                 |                              |   |
|                        |                 |                              |   |
| config.xml   (*)       | Project private | Brand definition             |
| platform.xml (*)       | Project private | Virtual platform definition  |
|                        |                 |                              |
| struct modlbrand       | Consolidation   | kernel/brand module          |   |
|                        | Private         | linkage interface            |   |
|                        |                 |                              |
| struct brand           | Project private | kernel/brand configuration   |
|                        |                 | interface                    |
|                        |                 |                              |
| struct brand_ops       | Project private | kernel/brand operational     |
|                        |                 | interface                    |
|                        |                 |                              |
| struct brand_mach_ops  | Project private | Arch-specific kernel/brand   |   |
|                        |                 | operational interface        |   |
|                        |                 |                              |
| struct brand_attr      | Project private | userspace/kernel interface   |
|                        |                 |                              |
| struct                 | Project private | userspace/kernel interface   |   |
|   lx_brand_registration|                 |                              |   |
|                        |                 |                              |   |
| rd_helper_ops_t        | Consolidation   | librtld_db.so helper plugin  |   |
|                        | Private         | interface                    |   |
|                        |                 |                              |
| brand_open()           | Project Private | libbrand.so.1 is a new       |
| brand_close()          |                 | library for parsing the      |
| brand_is_native()      |                 | BrandZ .xml files            |
| brand_get_boot()       |                 |                              |
| brand_get_halt()       |                 |                              |
| brand_get_initname()   |                 |                              |
| brand_get_install()    |                 |                              |
| brand_get_modname()    |                 |                              |
| brand_get_postclone()  |                 |                              |
| brand_get_verify()     |                 |                              |
| brand_platform_iter_gmounts()            |                              |
| brand_platform_iter_lmounts()            |                              |
| brand_platform_iter_devdir()             |                              |
| brand_platform_iter_link()               |                              |
|                        |                 |                              |
| zonecfg_get_brand()    | Contracted      | Added to libzonecfg.so.1     |
| zone_get_brand()       | Project private |                              |
|                        |                 |                              |
| zonecfg(1M)		 | Evolving        | Added -B <brand> option      |
|                        |                 |                              |
| zoneadm(1M)		 | Project private | Added -f (force) option to   |
|                        |                 | mount and boot commands.     |
|                        |                 | Added "brand" column to      |
|                        |                 | verbose "list" output.       |
|                        |                 |                              |
| zonecfg(1M)		 | Evolving        | Added -B <brand> option      |
|                        |                 |                              |
| lockd(1M)		 | Consolidation   | Added -P option to indicate  |
| statd(1M)              | Private         | portmapper usage             |
|                        |                 |                              |
| libnsl(3LIB)           | Consolidation   | Add __use_portmapper() to    |
|                        | Private         | resurrect old portmapper     |
|                        |                 | support                      |
|                        |                 |                              |
| streamio(7I)           | Evolving        | Add support for TIOCSCTTY,   |
|                        |                 | TIOCNOTTY, TIOCSETLD,        |
|                        |                 | and TIOCGETLD                |
|                        |                 |                              |
| uucopy(2)              | Evolving        | Added to libc.so.1	          |
|                        |                 |     See design doc: 3.5.2    |
| set_setcontext_enforcement(3C)           |                              |
|                        | Consolidation   | Added to libc.so.1	          |
|                        | Private         |     See design doc: 3.6.2    |
| setsigacthandler(3C)   | Consolidation   | Added to libc.so.1	          |   |
|                        | Private         |     See design doc: 3.6.1    |   |
|                        |                 |                              |
| lx_install(1M)	 | Evolving        | Invoked by zoneadm(1M), but  |
|                        |                 | options are user-visible     |
|                        |                 |                              |
| lx-syscall(7D)	 | Evolving        | Linux syscall provider       |
|                        |                 |                              |
| lx_ptm(7D)             | Project private | Linux pty master driver      |   |
|                        |                 |                              |   |
| ldlinux(7M)            | Project private | STREAMS module that provides |   |
|                        |                 | Linux termio(7I) semantics   |   |
|                        |                 |                              |   |
| lx_afs(7D)             | Project private | Linux automounter support    |   |
|                        |                 |                              |   |
| lx_audio(7D)           | Project private | Layered driver to convert    |   |
|                        |                 | Linux semantics to Solaris   |   |
___________________________________________________________________________

    (*) The DTDs for the config.xml and platform.xml files are included
	with the case materials.

14. What are its other significant internal interfaces 
    inter-subsystem and inter-invocation)?

	Please see the design doc for these details.

15. Is the interface extensible?  How will the interface evolve?  
- How is versioning handled?  

	The interface between the kernel and the brand module is extensible
	and versioned, as described in section 2.2.1 of the design
	document.  The interface between the lx brand library and the lx
	kernel module is also versioned, as described in section 3.3.2 of
	the design document.

- What was the commitment level of the previous version? 
	N/A

- Can this version co-exist with existing standards and with earlier
  and later versions or with alternative implementations (perhaps by
  other vendors)?
- What are the clients over which a change should be managed?
- How is transition to a new version to be accomplished? What are the 
  consequences to ISV's and their customers?

	Depending on the nature of the change, it is possible that the
	BrandZ framework, and the kernel modules and brand libraries
	provided by any brands, will all need to be upgraded at the same
	time.  All of these components (for Sun-distributed brands) are
	part of the ON consolidation, and their interfaces are Project
	Private, so managing these changes can be handled in the same
	fashion as any Solaris patch.

	Since the Linux kernel and the GNU libc are maintained by different
	groups of people, and since they are built and delivered
	independently, the interface between the two is significantly more
	stable than the interface between the Solaris kernel and our libc.
	Since the BrandZ project emulates that interface, this stability
	works to our benefit.
	
	Looking ahead, we anticipate that any future Linux brands (e.g.,
	for SUSE, Red Hat 4, etc.) can be incorporated in the 'lx' brand.
	We expect to have to add functionality to the 'lx' brand to support
	newer Linux distributions, but we do not expect there to be
	significant incompatibilities introduced by this new functionality.
	This means that we expect to be able to support RHEL-3 and RHEL-4
	zones simultaneously with a single 'lx' brand kernel module.

	We do not intend to support the upgrade of an installed Linux zone
	from one Linux release to another.  If it turns out that this
	functionality is relatively low-risk to add, we will do so, but
	that is not part of our current plan.
	
	When this product is initially released, the documentation will
	make it clear that this upgrade functionality should not be
	expected in future releases.  The document will also include "best
	practices", showing how a Linux zone should be configured to allow
	a zone to be uninstalled and re-installed with a newer Linux
	distro, without losing applications or data.

16. How do the interfaces adapt to a changing world?

- What is its relationship with (or difficulties with) multimedia?
  3D desktops? Nomadic computers?  Storage-less clients? A networked
  file system model (i.e., a network-wide file manager)?

	N/A

17. Interoperability

- If applicable, explain your project's interoperability with the
  other major implementations in the industry.  In particular, does
  it interoperate with Microsoft's implementation, if one exists?

	N/A

18. Performance

- How will the project contribute (positively or negatively) to
  "system load" and "perceived performance"?

	This project will have no impact on Solaris performance.  The
	presence of a Linux zone on a system will not impact the
	performance perceived by any Solaris zones.

- What are the performance goals of the project?  How were they
  evaluated? What is the test or reference platform?

	The project must have no performance impact on Solaris benchmarks.

	For some small set of Linux benchmarks, our emulation environment
	will impose no more than a 10% performance penalty over the same
	benchmarks running natively under Solaris on identical hardware.
	The benchmarks will include SpecJBB, mysql benchmarks, and one or
	two others.  We are working with the Performance PIT team in
	Ireland on this evaluation.

	This performance goal was validated by surveying OS Ambassadors and
	customers.

- Does the application pause for significant amounts of time?  
  Can the user interact with the application while it is performing
  long-duration tasks?

  	N/A

- What is your project's MT model? How does it use threads internally? 
  How does it expect its client to use threads?  If it uses callbacks,
  can the called entity create a thread and recursively call back?

  	We do not use threads ourselves, but we do support multithreaded
	Linux applications.  See section 3.5.1 of the design document.

- What is the impact on overall system performance?  What is the
  average working set of this component?  How much of this is
  shared/sharable by other apps?

  	There will be no impact on overall system performance.  There is no
	opportunity for sharing in this release, as we only support the
	whole root model of zone installation.

- Does this application "wake up" periodically?  How often and under
  what conditions?  What is the working set associated with this behavior?  
  	No

- Will it require large files/databases (for example, new fonts)?
	No

- Do files, databases or heap space tend to grow with time/load? What 
  mechanisms does the user have to use to control this? What happens to 
  performance/system load?

	No

19. Please identify any issues that you would like the ARC to address.

	- How should the SFWrpm package be made available to customers?

	- Is the filesystem layout used by the BrandZ framework and the lx
	  brand reasonable? (see section 4.2 of the design doc) 

	- Even though there are no real clients for it, should we integrate
	  the SPARC support, along with a dummy 'stub' of a brand for
	  testing? 

20. Appendices to include

- One-Pager.
- Prototype specification.
- References to other documents.  (Place copies in case directory.)
--Boundary_(ID_CgRMzOLcCXHNfdF4zYQ3pQ)-- From sacadmin Thu Jul 13 12:27:18 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 k6DJRI1c002651 for ; Thu, 13 Jul 2006 12:27:18 -0700 (PDT) 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 k6DJRHZ03991 for <@sunmail2.sfbay.sun.com:psarc@sun.com>; Thu, 13 Jul 2006 12:27:17 -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 (built Dec 2 2004)) id <0J2C00607WPF4900@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 13 Jul 2006 12:27:15 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J2C00IS3WPE6Q40@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 13 Jul 2006 12:27:15 -0700 (PDT) Received: from negril.East.Sun.COM (negril.East.Sun.COM [129.148.183.104]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6DJRETp012455; Thu, 13 Jul 2006 15:27:14 -0400 (EDT) Received: from negril.East.Sun.COM (localhost [127.0.0.1]) by negril.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k6DJQhn9147419; Thu, 13 Jul 2006 15:26:43 -0400 (EDT) Received: (from nn35248@localhost) by negril.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k6DJQhh0147418; Thu, 13 Jul 2006 15:26:43 -0400 (EDT) Date: Thu, 13 Jul 2006 15:26:43 -0400 From: Nils Nieuwejaar Subject: Re: PSARC Meeting Minutes 05/17/2006 Commitment: 2005/471 In-reply-to: <44B69826.9000200@sun.com> To: psarc@sun.com Cc: Nils Nieuwejaar Message-id: <20060713192643.GP146391@east.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <44733609.3040409@Sun.COM> <20060712152340.GF143658@east.sun.com> <44B69826.9000200@sun.com> User-Agent: Mutt/1.4.2i Status: RO Content-Length: 1084 On Thu 07/13/06 at 11:59 AM, Sherri.Shieh@Sun.COM wrote: > All, > > Final materials have been put into the final.materials directory: The file containing our responses to the issues raised during the commitment review missed one of Jim Carlson's questions: > jdc-11 What does TIOCSETLD actually do on Solaris? (Shouldn't > that > be TIOCSETD rather than TIOCSETLD? The latter doesn't appear > to be in the Linux kernel sources, but 20q mentions the > former.) How can line disciplines be used on a STREAMS-based > system? > > * This should be put into the interface table... TIOCSETLD and TIOCGETLD are new ioctl()s supported by our ldterm(7M) module, and they are included in the interface table. Despite the similarity in naming, these new ioctl()s have nothing to do with TIOCSETD or TIOCGETD. They are used by our brand library to emulate the following terminal ioctl()s: TCSETS, TCSETSW, TCSETSF, TCSETA, TCSETAW, TCSETAF, TCGETS, TCGETA. Both Solaris and Linux support these ioctl()s, but their parameters are defined differently. Nils From sacadmin Thu Jul 13 12:45:56 2006 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 k6DJjtX0003650 for ; Thu, 13 Jul 2006 12:45:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k6DJjpdB002040; Thu, 13 Jul 2006 20:45:53 +0100 (BST) 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 <0J2C00105XKGHZ00@brm-avmta-1.central.sun.com>; Thu, 13 Jul 2006 13:45:52 -0600 (MDT) Received: from phorcys.East.Sun.COM ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J2C00EWDXKFUS90@brm-avmta-1.central.sun.com>; Thu, 13 Jul 2006 13:45:52 -0600 (MDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k6DJl5a4026660; Thu, 13 Jul 2006 15:47:06 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k6DJl4FR026657; Thu, 13 Jul 2006 15:47:04 -0400 (EDT) Date: Thu, 13 Jul 2006 15:47:02 -0400 From: James Carlson Subject: Re: PSARC Meeting Minutes 05/17/2006 Commitment: 2005/471 In-reply-to: Nils Nieuwejaar's message of 13 July 2006 15:26:43 To: Nils Nieuwejaar Cc: psarc@sun.com Message-id: <17590.41782.769495.353828@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <44733609.3040409@Sun.COM> <20060712152340.GF143658@east.sun.com> <44B69826.9000200@sun.com> <20060713192643.GP146391@east.sun.com> Status: RO Content-Length: 914 Nils Nieuwejaar writes: > TIOCSETLD and TIOCGETLD are new ioctl()s supported by our ldterm(7M) > module, and they are included in the interface table. > > Despite the similarity in naming, these new ioctl()s have nothing to do > with TIOCSETD or TIOCGETD. They are used by our brand library to emulate > the following terminal ioctl()s: TCSETS, TCSETSW, TCSETSF, TCSETA, TCSETAW, > TCSETAF, TCGETS, TCGETA. Both Solaris and Linux support these ioctl()s, > but their parameters are defined differently. Ah, ok. Though I'm curious about why ldterm isn't just made brand- aware, my main concern was with line disciplines. As long as they're not supported, this looks like a fine answer. -- 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 Thu Jul 13 12:54:44 2006 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 k6DJshrf004661 for ; Thu, 13 Jul 2006 12:54:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k6DJscjY003516 for <@sunmail3.sfbay.sun.com:psarc@Sun.COM>; Thu, 13 Jul 2006 20:54:42 +0100 (BST) 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 <0J2C00805XZ5VZ00@nwk-avmta-2.sfbay.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Thu, 13 Jul 2006 12:54:41 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J2C000PHXZ5O740@nwk-avmta-2.sfbay.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Thu, 13 Jul 2006 12:54:41 -0700 (PDT) Received: from negril.East.Sun.COM (negril.East.Sun.COM [129.148.183.104]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6DJsenK000821; Thu, 13 Jul 2006 15:54:40 -0400 (EDT) Received: from negril.East.Sun.COM (localhost [127.0.0.1]) by negril.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k6DJs9ND147485; Thu, 13 Jul 2006 15:54:09 -0400 (EDT) Received: (from nn35248@localhost) by negril.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k6DJs9CR147484; Thu, 13 Jul 2006 15:54:09 -0400 (EDT) Date: Thu, 13 Jul 2006 15:54:09 -0400 From: Nils Nieuwejaar Subject: Re: PSARC Meeting Minutes 05/17/2006 Commitment: 2005/471 In-reply-to: <17590.41782.769495.353828@gargle.gargle.HOWL> To: James Carlson Cc: psarc@sun.com Message-id: <20060713195409.GS146391@east.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <44733609.3040409@Sun.COM> <20060712152340.GF143658@east.sun.com> <44B69826.9000200@sun.com> <20060713192643.GP146391@east.sun.com> <17590.41782.769495.353828@gargle.gargle.HOWL> User-Agent: Mutt/1.4.2i Status: RO Content-Length: 1074 On Thu 07/13/06 at 15:47 PM, James.D.Carlson@Sun.COM wrote: > Nils Nieuwejaar writes: > > TIOCSETLD and TIOCGETLD are new ioctl()s supported by our ldterm(7M) > > module, and they are included in the interface table. > > > > Despite the similarity in naming, these new ioctl()s have nothing to do > > with TIOCSETD or TIOCGETD. They are used by our brand library to emulate > > the following terminal ioctl()s: TCSETS, TCSETSW, TCSETSF, TCSETA, TCSETAW, > > TCSETAF, TCGETS, TCGETA. Both Solaris and Linux support these ioctl()s, > > but their parameters are defined differently. > > Ah, ok. Though I'm curious about why ldterm isn't just made brand- > aware, my main concern was with line disciplines. As long as they're > not supported, this looks like a fine answer. In this case it's not just a matter of being brand aware. We would have to add Linux-specific knowledge to ldterm (and presumably any other driver that interprets these ioctl()s), which would break our strict policy of isolating Linux-ness within the lx brand's library and kernel modules. Nils From sacadmin Thu Jul 20 14:36:36 2006 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 k6KLaaNe000326 for ; Thu, 20 Jul 2006 14:36:36 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6KLaags016598 for ; Thu, 20 Jul 2006 14:36:36 -0700 (PDT) Received: from d1-sfbay-06.sun.com ([192.18.39.116]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6KLaUFp015245 for ; Thu, 20 Jul 2006 14:36:30 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-06.sun.com by d1-sfbay-06.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J2Q00B010YRPB00@d1-sfbay-06.sun.com> (original mail from Ed.Gould@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 20 Jul 2006 14:36:30 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-06.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J2Q007JX1CUJT40@d1-sfbay-06.sun.com> for PSARC@sac.sfbay.sun.com; Thu, 20 Jul 2006 14:36:30 -0700 (PDT) Date: Thu, 20 Jul 2006 14:36:43 -0700 From: Ed Gould Subject: Vot on PSARC/2005/471 BrandZ: Support for non-native zones Sender: Ed.Gould@Sun.COM To: PSARC@sac.sfbay.sun.com Cc: Sherri Shieh Message-id: <44BFF76B.2090104@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_to6w3dmb9wblFn8withwKg)" User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1106 This is a multi-part message in MIME format. --Boundary_(ID_to6w3dmb9wblFn8withwKg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I have asked Sherri to schedule the vote on PSARC/2005/471 BrandZ: Support for non-native zones at the meeting on July 26. Unfortunately, neither Alan (intern) nor I (owner) will be at the meeting. If there are any remaining issues with this case (a new spec is in the final.materials subdirectory of the case directory), please raise them via email before the meeting, so they are recorded in the log. Thanks. -- --Ed --Boundary_(ID_to6w3dmb9wblFn8withwKg) 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.;N1GS: 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_to6w3dmb9wblFn8withwKg)-- From sacadmin Thu Jul 20 14:52:05 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 k6KLq51u000502 for ; Thu, 20 Jul 2006 14:52:05 -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 k6KLq4oo009576 for ; Thu, 20 Jul 2006 14:52:04 -0700 (PDT) Received: from d1-sfbay-01.sun.com (d1-sfbay-01 [192.18.39.111]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6KLpxlU017630 for ; Thu, 20 Jul 2006 14:51:59 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-01.sun.com by d1-sfbay-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J2Q00A011LXYD00@d1-sfbay-01.sun.com> (original mail from Ed.Gould@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 20 Jul 2006 14:51:59 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J2Q00H0922NN440@d1-sfbay-01.sun.com> for PSARC@sac.sfbay.sun.com; Thu, 20 Jul 2006 14:51:59 -0700 (PDT) Date: Thu, 20 Jul 2006 14:52:10 -0700 From: Ed Gould Subject: Re: Vot on PSARC/2005/471 BrandZ: Support for non-native zones In-reply-to: <44BFF76B.2090104@sun.com> Sender: Ed.Gould@Sun.COM To: PSARC@sac.sfbay.sun.com Cc: Sherri Shieh , Nils Nieuwejaar Message-id: <44BFFB0A.6040509@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_kzYKuigAjtNWRnWZmxAZog)" References: <44BFF76B.2090104@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1230 This is a multi-part message in MIME format. --Boundary_(ID_kzYKuigAjtNWRnWZmxAZog) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Ed Gould wrote: > I have asked Sherri to schedule the vote on PSARC/2005/471 BrandZ: > Support for non-native zones at the meeting on July 26. Unfortunately, > neither Alan (intern) nor I (owner) will be at the meeting. If there > are any remaining issues with this case (a new spec is in the > final.materials subdirectory of the case directory), please raise them > via email before the meeting, so they are recorded in the log. > > Thanks. And please don't forget to copy Nils on any of the issues, as I did on my original email. -- --Ed --Boundary_(ID_kzYKuigAjtNWRnWZmxAZog) 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.;N1GS: 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_kzYKuigAjtNWRnWZmxAZog)-- From sac-owner Fri Jul 28 08:33:38 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 k6SFXbGf017462 for ; Fri, 28 Jul 2006 08:33:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k6SFXS6x027511 for <@sunmail1brm.central.sun.com:sac-review@sun.com>; Fri, 28 Jul 2006 23:33:36 +0800 (SGT) 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 <0J340010DDVX4Z00@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@Sun.COM); Fri, 28 Jul 2006 09:33:33 -0600 (MDT) Received: from nwkea-pix-1.sun.com ([10.4.134.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J3400IAIDVV1KE0@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@Sun.COM); Fri, 28 Jul 2006 09:33:32 -0600 (MDT) Received: from d1-sfbay-01.sun.com ([192.18.39.111]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6SFXVbV006557 for ; Fri, 28 Jul 2006 08:33:31 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-01.sun.com by d1-sfbay-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J3400001CXECF00@d1-sfbay-01.sun.com> (original mail from Sherri.Shieh@Sun.COM) for sac-review@Sun.COM (ORCPT sac-review@Sun.COM); Fri, 28 Jul 2006 08:33:31 -0700 (PDT) Received: from [129.146.11.190] by d1-sfbay-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J3400HD0DVR9A40@d1-sfbay-01.sun.com> for sac-review@Sun.COM (ORCPT sac-review@Sun.COM); Fri, 28 Jul 2006 08:33:31 -0700 (PDT) Date: Fri, 28 Jul 2006 08:33:27 -0700 From: Sherri Shieh Subject: PSARC Case Approved 07/26/2006 - 2005/471 Sender: Sherri.Shieh@sun.com To: Sherri Shieh Reply-to: Sherri.Shieh@sun.com Message-id: <44CA2E47.6000001@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: 231 PSARC approved 07/26/2006 Case: BrandZ: Support for non-native zones (2005/471) Incompatible Changes: none Precedent: none If more information is needed, please contact the case owner/intern. From sacadmin Mon Aug 21 17:30:44 2006 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 k7M0UgUb019884 for ; Mon, 21 Aug 2006 17:30:43 -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 k7M0UaP4018512 for ; Tue, 22 Aug 2006 08:30:36 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4D00001IO6C900@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for PSARC-members@sac.sfbay.sun.com; Tue, 22 Aug 2006 08:30:36 +0800 (SGT) Received: from [192.168.10.101] ([129.150.152.31]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4D0084QIQX6KWY@mail-apac.sun.com> for PSARC-members@sac.sfbay.sun.com; Tue, 22 Aug 2006 08:30:36 +0800 (SGT) Date: Tue, 22 Aug 2006 10:29:42 +1000 From: Alan Hargreaves Subject: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones Sender: Alan.Hargreaves@Sun.COM To: PSARC-members@sac.sfbay.sun.com Message-id: <44EA4FF6.6010104@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_6yAPXURf2xRzal4lpCEyMA)" User-Agent: Mail/News 1.5.0.4 (X11/20060801) Status: RO Content-Length: 23656 This is a multi-part message in MIME format. --Boundary_(ID_6yAPXURf2xRzal4lpCEyMA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Included for review is the opinion for PSARC 2005/471 BrandZ Support for non-native zones. Please review and return comments by August 29th 2005. (Ed, I've added some input from Nils this morning too). There are postscript, acrobat, text and troff versions of the opinion in the case directory. alan. --Boundary_(ID_6yAPXURf2xRzal4lpCEyMA) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: BrandZ Support for non-native zones Submitted by: Nils Niewejaar File: PSARC/2005/471/opinion.ms Date: July 28th, 2006 Committee: Ed Gould (Opinion by Alan Hargreaves), James D Carlson, Glenn Skinner, William Sommerfeld, Gary Winiger. Product Approval Committee: solaris-pac-opinion@sun.com 1. Summary BrandZ is an extension of the zones infrastructure that allows the creation of zones that emulate non-native operat- ing system environments, such as Linux, FreeBSD, or older versions of Solaris. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. The project supercedes PSARC/2003/445: Janus: Linux binary compatibility for Solaris x86. The project depends on PSARC/2006/440: BrandZ-aware Installer and may not be delivered before it. 3. Interfaces The project exports the following interfaces. ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| | | | | | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 2 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |Linux Interfaces: | External | This category includes| | | | all of the different| |System calls (structure,| | Linux interfaces that the| |semantics and calling conven-| | lx brand emulates. | |tions) | | | | | | | |/dev (names and major/minor| | | |#'s) | | | |/proc | | | |signal numbers | | | |error numbers | | | |______________________________|_________________|___________________________| |AT_SUN_BRAND_BASE | Project Private| Additional AUX vector| |AT_SUN_BRAND_LDDATA | | flags used to convey| |AT_SUN_BRAND_LDENTRY | | brand information to the| |AT_SUN_BRAND_BRANDNAME | | Solaris linker | |AT_SUN_BRAND_PHDR | | | |AT_SUN_BRAND_PHENT | | | |AT_SUN_BRAND_PHNUM | | | |AT_SUN_BRAND_ENTRY | | | |______________________________|_________________|___________________________| |config.xml | Project Private| Brand definition | |______________________________|_________________|___________________________| |platform.xml | Project Private| Virtual platform defini-| | | | tion | |______________________________|_________________|___________________________| |struct modlbrand | Consolidation | kernel/brand module link-| | | Private | age interface | |______________________________|_________________|___________________________| |struct brand | Project Private| Kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_ops | Project Private| Kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_mach_ops | Project Private| Arch-specific | | | | kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_attr | Project Private| Userspace/kernel inter-| | | | face | |______________________________|_________________|___________________________| |struct lx_brand_registration | Project Private| Userspace/kernel inter-| | | | face | |______________________________|_________________|___________________________| |rd_helper_ops_t | Consolidation | librtld_db.so helper plu-| | | Private | gin interface | |______________________________|_________________|___________________________| | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 3 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |brand_open() brand_close() | Project Private| libbrand.so.1 is a new| |brand_is_native() | | library for parsing the| |brand_get_boot() | | BrandZ .xml files | |brand_get_halt() | | | |brand_get_initname() | | | |brand_get_install() | | | |brand_get_modename() | | | |brand_get_postclone() | | | |brand_get_verify() | | | |brand_platform_iter_gmounts() | | | |brand_platform_iter_lmounts() | | | |brand_platform_iter_devdir() | | | |brand_platform_iter_link() | | | |______________________________|_________________|___________________________| |zonecfg_get_brand() | Contracted Pro-| Added to libzonecfg.so.1 | |zone_get_brand() | ject Private | Contract in reference [4]| |______________________________|_________________|___________________________| |zonecfg(1M) | Evolving | Added -B option | |______________________________|_________________|___________________________| |zoneadm(1M) | Project Private| Added -f (force) option| | | | to mount and boot com-| | | | mands | | | | Added "brand" column to| | | | verbose "list" output | |______________________________|_________________|___________________________| |zonecfg(1M) | Evolving | Added -B option | |______________________________|_________________|___________________________| |lockd(1M) statd(1M) | Consolidation | Added -P option to indi-| | | Private | cate portportmapper usage| |______________________________|_________________|___________________________| |libnsl(3LIB) | Consolidation | Add __use_portmapper() to| | | Private | resurrect old portmapper| | | | support | |______________________________|_________________|___________________________| |streamio(7I) | Evolving | Add support for| | | | TIOCSCTTY, TIOCNOTTY,| | | | TIOCSETLD and TOICGETLD | |______________________________|_________________|___________________________| |uucopy(2) | Evolving | Added to libc.so.1 See | | | | design doc: 3.5.2 | |______________________________|_________________|___________________________| |set_setcontext_enforcement(3C)| Consolidation | Added to libc.so.1 See | | | Private | design doc 3.6.2 | |______________________________|_________________|___________________________| |setsigacthandler(3C) | Consolidation | Added to libc.so.1 See | | | Private | design doc 3.6.1 | |______________________________|_________________|___________________________| | | | | | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 4 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |lx-install(1M) | Evolving | Invoked by zoneadm(1M),| | | | but options are user-| | | | visible | |______________________________|_________________|___________________________| |lx-syscall(7D) | Evolving | Linux syscall provider | |______________________________|_________________|___________________________| |lx_ptm(7D) | Project Private| Linux pty master driver | |______________________________|_________________|___________________________| |ldlinux(7M) | Project Private| STREAMS module that pro-| | | | vides Linux termio(7I)| | | | semantics | |______________________________|_________________|___________________________| |lx_afs(7D) | Project Private| Linux automounter support| |______________________________|_________________|___________________________| |lx_audio(7D) | Project Private| Layered driver to convert| | | | Linux semantics to| | | | Solaris | |______________________________|_________________|___________________________| |______________________________|_________________|___________________________| The project imports the following interfaces. ____________________________________________________________________________ | Interfaces Imported | |_______________________|________________|_________________________________| |Interface | Classification| Comments | |_______________________|________________|_________________________________| |Linux syscall Interface| External | | |_______________________|________________|_________________________________| |rpm2cpio(1M) CLI rpm | External | Used to install RedHat software| |CLI | | | |_______________________|________________|_________________________________| |Linux statd(1M) and| External | Used to support NFS locking| |lockd(1M) uid/gid #'s | | within lx branded zones | |_______________________|________________|_________________________________| |glibc ABI | External | Used to provide naming services| | gethostbyname_r | | to Solaris statd(1M) and| | gethostbyaddr_r | | lockd(1M) daemons. See section| | getservbyname_r | | 3.8 of the design doc. | | getservbyport_r | | | | openlog | | | | syslog | | | | closelog | | | | __progname | | | |_______________________|________________|_________________________________| | | | | | | | | | | | | |_______________________|________________|_________________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 5 - ____________________________________________________________________________ | Interfaces Imported | |_______________________|________________|_________________________________| |Interface | Classification| Comments | |_______________________|________________|_________________________________| |RHEL 3.x contents | External | /etc files, rc.d scripts, etc.| | | | which we modify at install| | | | time. | |_______________________|________________|_________________________________| |Linux ELF format | External | Object file format for Linux| | | | binaries | |_______________________|________________|_________________________________| 4. Opinion 4.1. The lx Brand The word Linux is a trademark. To avoid issues, the name lx is used to reference linux branded zones. PSARC had concerns about the management of this namespace for future brands and releases of linux. As a result, refer- ences to specific releases of the linux kernel were removed from the documentation. 4.2. Executable Stacks For compatibility BrandZ has to allow Linux applications to run with executable stacks, so those applications are vulnerable to any security holes that are opened by those stacks. However, since it is running inside a zone, any dam- age would be confined to that BrandZ instance. A compromised zone will not be able to bring down the system, and will neither have access to, nor be able to damage applications or data in other zones. Considered more generally, a BrandZ-hosted linux environment will be subject to any security holes in the Linux user- space. However, it will not be vulnerable to any security holes that depend on kernel support or kernel bugs. This would arguably make a BrandZ-hosted RHEL 3 environment more secure than a native RHEL 3 environment. 4.3. Truss, Apptrace and Dbx Truss has been updated to recognize the new Solaris system calls; it has not been updated to understand and display the Linux system calls issued by the application. An lx-syscall DTrace provider makes that information available. PSARC/2005/471 Copyright 2006 Sun Microsystems - 6 - dbx does not currently work, but this appears to be a bug rather than a fundamental limitation of the design. This is still under investigation and is being tracked as: 6445248 dbx cannot grok Linux processes 4.4. Live Upgrade and Packaging Tools Live upgrade doesn't run with zones. The packaging tools will go into the install gate 63242179 packaging tools need to be brand aware has been filed and links to this case. PSARC/2006/440 has been submitted and approved for working with live upgrade. 4.5. Audio There is no notion of a device-specific attribute, which is needed to support systems with multiple audio devices, in the zone's infrastructure now. Adding such a capability would have required an extensive overhaul of how devices are configured and managed. Rather than redesign the core of the zones configuration tools simply to solve one Linux corner case, the project team chose to use the generic attributes mechanism to sup- port audio devices. 4.6. Trusted Solaris Extensions After discussions between the project teams for this case and for the Trusted Extensions, it was determined that branded zones will not be supportted on trusted systems where labels are active. 4.7. lxrun PSARC/2006/441 has been submitted and approved to EOL lxrun. 4.8. Process Auditing Processes running in an lx-branded zone do not have their Linux system calls audited. Otherwise, they are subject to all the standard auditing. For example, Linux process creation/exit events are captured as for any other process. The Solaris system calls that the brand library uses to PSARC/2005/471 Copyright 2006 Sun Microsystems - 7 - emulate the Linux system calls are subject to auditing. The only restriction is that the Solaris audit processing tools cannot run inside the Linux zone, so the audit records must be consumed by tools running in the global zone. 4.9. Signals to init During inception, PSARC expressed a concern about how the lx init would deal with system generated signals that it was not expecting. The project team has addressed these concerns as follows. With standard Solaris zones, the kernel and init are in agreement on how to handle the death of init: the kernel restarts the process, and the resurrected init process uses a state file to pick up where its predecessor left off. The Linux init is not prepared to handle this kind of res- tart. When it is restarted, it works its way through the entire boot process again. This means that all the rc.d scripts are rerun, and we end up with multiple instances of services like crond, syslogd, and so on. Since it cannot simply ignore SIGSEGV, and since the Linux init is not prepared to handle a warm restart, the only action that will deliver a sensible result is to reboot the zone. Regardless of whether this is the expected behavior on a native Linux system, it's the behavior that will be implemented inside a Linux zone. 4.10. Delegated Administration of Solaris-specific capabil- ities Linux-branded zones will always be second-class citizens in many ways. As our real goal is to increase Solaris adop- tion, using BrandZ as one part of a migration strategy, we view this as a feature rather than a bug. To address these specific issues: ZFS delegation will not work within a Linux zone. Given sufficient customer interest, we could possibly support the ZFS utilities, but it would take a significant amount of engineering work, and would violate our "one binary type per zone" model. It should be noted that this in no way affects being able to install and run a Linux zone on a ZFS filesystem. Supporting network delegation is significantly more feasi- ble. By emulating the ioctl()s needed to perform network configuration tasks, we should be able to support network delegation using Linux configuration tools. This would not be a trivial engineering effort, but it would certainly fit PSARC/2005/471 Copyright 2006 Sun Microsystems - 8 - within the overall BrandZ model. 4.11. Impact on Zones Upgrade The zones test suite, which is run as a regular part of the PIT suite, will be extended to include testing of lx-branded zones. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/471. 1. Specification File: final.materials/design.pdf File: committment.materials/onepager File: committment.materials/what_works 2. 20 Questions File: final.materials/20_questions 3. Man Pages File: committment.materials/brand.dtd.1 File: committment.materials/brands.5 File: committment.materials/design.pdf File: committment.materials/lx.5 File: committment.materials/zone_platform.dtd.1 File: committment.materials/zoneadm.1m File: committment.materials/zonecfg.1m File: committment.materials/zones.5 4. Contract between Solaris Core Technologies and Solaris Install PSARC/2005/471 Copyright 2006 Sun Microsystems - 9 - File: contract-01 PSARC/2005/471 Copyright 2006 Sun Microsystems --Boundary_(ID_6yAPXURf2xRzal4lpCEyMA)-- From sacadmin Mon Aug 21 17:46:22 2006 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 k7M0kLes020103 for ; Mon, 21 Aug 2006 17:46:21 -0700 (PDT) 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 k7M0kBjV016766 for ; Tue, 22 Aug 2006 08:46:15 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4D00601JC64D00@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 22 Aug 2006 08:46:11 +0800 (SGT) Received: from [192.168.10.101] ([129.150.152.31]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4D00HQ6JGWRLHZ@mail-apac.sun.com> for psarc@sac.sfbay.sun.com; Tue, 22 Aug 2006 08:46:11 +0800 (SGT) Date: Tue, 22 Aug 2006 10:45:17 +1000 From: Alan Hargreaves Subject: [Fwd: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones] Sender: Alan.Hargreaves@Sun.COM To: psarc@sac.sfbay.sun.com Message-id: <44EA539D.3050209@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_hxNlOxfKGIsgspG2dHEPuQ)" User-Agent: Mail/News 1.5.0.4 (X11/20060801) Status: RO Content-Length: 25751 This is a multi-part message in MIME format. --Boundary_(ID_hxNlOxfKGIsgspG2dHEPuQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Getting the alias right. alan. -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Systems Technical Service Center Sun Microsystems I went in the World's Greatest shave for Leukaemia. See http://blogs.sun.com/roller/page/tpenta?entry=hair_yesterday_gone_today --Boundary_(ID_hxNlOxfKGIsgspG2dHEPuQ) Content-type: message/rfc822; name*0="Opinion for Review: PSARC/2005/471 BrandZ Support for non-native"; name*1=" zones" Return-path: Received: from fe-apac-06.sun.com ([192.18.19.177]) by sedge1-mail1.singapore.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTP id <0J4D009YMIR05E20@sedge1-mail1.singapore.sun.com> for Alan.Hargreaves@Sun.COM; Tue, 22 Aug 2006 08:30:37 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4D00001IO6C900@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for Alan.Hargreaves@Sun.COM (ORCPT Alan.Hargreaves@Sun.COM); Tue, 22 Aug 2006 08:30:36 +0800 (SGT) Received: from [192.168.10.101] ([129.150.152.31]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4D0084QIQX6KWY@mail-apac.sun.com> for Alan.Hargreaves@Sun.COM (ORCPT Alan.Hargreaves@Sun.COM); Tue, 22 Aug 2006 08:30:36 +0800 (SGT) Date: Tue, 22 Aug 2006 10:29:42 +1000 From: Alan Hargreaves Subject: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones Sender: Alan.Hargreaves@Sun.COM To: PSARC-members@sac.sfbay.sun.com Message-id: <44EA4FF6.6010104@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_UnZMcdU9vaRDm/7PqCK2lQ)" User-Agent: Mail/News 1.5.0.4 (X11/20060801) Original-recipient: rfc822;Alan.Hargreaves@Sun.COM This is a multi-part message in MIME format. --Boundary_(ID_UnZMcdU9vaRDm/7PqCK2lQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Included for review is the opinion for PSARC 2005/471 BrandZ Support for non-native zones. Please review and return comments by August 29th 2005. (Ed, I've added some input from Nils this morning too). There are postscript, acrobat, text and troff versions of the opinion in the case directory. alan. --Boundary_(ID_UnZMcdU9vaRDm/7PqCK2lQ) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: BrandZ Support for non-native zones Submitted by: Nils Niewejaar File: PSARC/2005/471/opinion.ms Date: July 28th, 2006 Committee: Ed Gould (Opinion by Alan Hargreaves), James D Carlson, Glenn Skinner, William Sommerfeld, Gary Winiger. Product Approval Committee: solaris-pac-opinion@sun.com 1. Summary BrandZ is an extension of the zones infrastructure that allows the creation of zones that emulate non-native operat- ing system environments, such as Linux, FreeBSD, or older versions of Solaris. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. The project supercedes PSARC/2003/445: Janus: Linux binary compatibility for Solaris x86. The project depends on PSARC/2006/440: BrandZ-aware Installer and may not be delivered before it. 3. Interfaces The project exports the following interfaces. ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| | | | | | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 2 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |Linux Interfaces: | External | This category includes| | | | all of the different| |System calls (structure,| | Linux interfaces that the| |semantics and calling conven-| | lx brand emulates. | |tions) | | | | | | | |/dev (names and major/minor| | | |#'s) | | | |/proc | | | |signal numbers | | | |error numbers | | | |______________________________|_________________|___________________________| |AT_SUN_BRAND_BASE | Project Private| Additional AUX vector| |AT_SUN_BRAND_LDDATA | | flags used to convey| |AT_SUN_BRAND_LDENTRY | | brand information to the| |AT_SUN_BRAND_BRANDNAME | | Solaris linker | |AT_SUN_BRAND_PHDR | | | |AT_SUN_BRAND_PHENT | | | |AT_SUN_BRAND_PHNUM | | | |AT_SUN_BRAND_ENTRY | | | |______________________________|_________________|___________________________| |config.xml | Project Private| Brand definition | |______________________________|_________________|___________________________| |platform.xml | Project Private| Virtual platform defini-| | | | tion | |______________________________|_________________|___________________________| |struct modlbrand | Consolidation | kernel/brand module link-| | | Private | age interface | |______________________________|_________________|___________________________| |struct brand | Project Private| Kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_ops | Project Private| Kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_mach_ops | Project Private| Arch-specific | | | | kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_attr | Project Private| Userspace/kernel inter-| | | | face | |______________________________|_________________|___________________________| |struct lx_brand_registration | Project Private| Userspace/kernel inter-| | | | face | |______________________________|_________________|___________________________| |rd_helper_ops_t | Consolidation | librtld_db.so helper plu-| | | Private | gin interface | |______________________________|_________________|___________________________| | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 3 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |brand_open() brand_close() | Project Private| libbrand.so.1 is a new| |brand_is_native() | | library for parsing the| |brand_get_boot() | | BrandZ .xml files | |brand_get_halt() | | | |brand_get_initname() | | | |brand_get_install() | | | |brand_get_modename() | | | |brand_get_postclone() | | | |brand_get_verify() | | | |brand_platform_iter_gmounts() | | | |brand_platform_iter_lmounts() | | | |brand_platform_iter_devdir() | | | |brand_platform_iter_link() | | | |______________________________|_________________|___________________________| |zonecfg_get_brand() | Contracted Pro-| Added to libzonecfg.so.1 | |zone_get_brand() | ject Private | Contract in reference [4]| |______________________________|_________________|___________________________| |zonecfg(1M) | Evolving | Added -B option | |______________________________|_________________|___________________________| |zoneadm(1M) | Project Private| Added -f (force) option| | | | to mount and boot com-| | | | mands | | | | Added "brand" column to| | | | verbose "list" output | |______________________________|_________________|___________________________| |zonecfg(1M) | Evolving | Added -B option | |______________________________|_________________|___________________________| |lockd(1M) statd(1M) | Consolidation | Added -P option to indi-| | | Private | cate portportmapper usage| |______________________________|_________________|___________________________| |libnsl(3LIB) | Consolidation | Add __use_portmapper() to| | | Private | resurrect old portmapper| | | | support | |______________________________|_________________|___________________________| |streamio(7I) | Evolving | Add support for| | | | TIOCSCTTY, TIOCNOTTY,| | | | TIOCSETLD and TOICGETLD | |______________________________|_________________|___________________________| |uucopy(2) | Evolving | Added to libc.so.1 See | | | | design doc: 3.5.2 | |______________________________|_________________|___________________________| |set_setcontext_enforcement(3C)| Consolidation | Added to libc.so.1 See | | | Private | design doc 3.6.2 | |______________________________|_________________|___________________________| |setsigacthandler(3C) | Consolidation | Added to libc.so.1 See | | | Private | design doc 3.6.1 | |______________________________|_________________|___________________________| | | | | | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 4 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |lx-install(1M) | Evolving | Invoked by zoneadm(1M),| | | | but options are user-| | | | visible | |______________________________|_________________|___________________________| |lx-syscall(7D) | Evolving | Linux syscall provider | |______________________________|_________________|___________________________| |lx_ptm(7D) | Project Private| Linux pty master driver | |______________________________|_________________|___________________________| |ldlinux(7M) | Project Private| STREAMS module that pro-| | | | vides Linux termio(7I)| | | | semantics | |______________________________|_________________|___________________________| |lx_afs(7D) | Project Private| Linux automounter support| |______________________________|_________________|___________________________| |lx_audio(7D) | Project Private| Layered driver to convert| | | | Linux semantics to| | | | Solaris | |______________________________|_________________|___________________________| |______________________________|_________________|___________________________| The project imports the following interfaces. ____________________________________________________________________________ | Interfaces Imported | |_______________________|________________|_________________________________| |Interface | Classification| Comments | |_______________________|________________|_________________________________| |Linux syscall Interface| External | | |_______________________|________________|_________________________________| |rpm2cpio(1M) CLI rpm | External | Used to install RedHat software| |CLI | | | |_______________________|________________|_________________________________| |Linux statd(1M) and| External | Used to support NFS locking| |lockd(1M) uid/gid #'s | | within lx branded zones | |_______________________|________________|_________________________________| |glibc ABI | External | Used to provide naming services| | gethostbyname_r | | to Solaris statd(1M) and| | gethostbyaddr_r | | lockd(1M) daemons. See section| | getservbyname_r | | 3.8 of the design doc. | | getservbyport_r | | | | openlog | | | | syslog | | | | closelog | | | | __progname | | | |_______________________|________________|_________________________________| | | | | | | | | | | | | |_______________________|________________|_________________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 5 - ____________________________________________________________________________ | Interfaces Imported | |_______________________|________________|_________________________________| |Interface | Classification| Comments | |_______________________|________________|_________________________________| |RHEL 3.x contents | External | /etc files, rc.d scripts, etc.| | | | which we modify at install| | | | time. | |_______________________|________________|_________________________________| |Linux ELF format | External | Object file format for Linux| | | | binaries | |_______________________|________________|_________________________________| 4. Opinion 4.1. The lx Brand The word Linux is a trademark. To avoid issues, the name lx is used to reference linux branded zones. PSARC had concerns about the management of this namespace for future brands and releases of linux. As a result, refer- ences to specific releases of the linux kernel were removed from the documentation. 4.2. Executable Stacks For compatibility BrandZ has to allow Linux applications to run with executable stacks, so those applications are vulnerable to any security holes that are opened by those stacks. However, since it is running inside a zone, any dam- age would be confined to that BrandZ instance. A compromised zone will not be able to bring down the system, and will neither have access to, nor be able to damage applications or data in other zones. Considered more generally, a BrandZ-hosted linux environment will be subject to any security holes in the Linux user- space. However, it will not be vulnerable to any security holes that depend on kernel support or kernel bugs. This would arguably make a BrandZ-hosted RHEL 3 environment more secure than a native RHEL 3 environment. 4.3. Truss, Apptrace and Dbx Truss has been updated to recognize the new Solaris system calls; it has not been updated to understand and display the Linux system calls issued by the application. An lx-syscall DTrace provider makes that information available. PSARC/2005/471 Copyright 2006 Sun Microsystems - 6 - dbx does not currently work, but this appears to be a bug rather than a fundamental limitation of the design. This is still under investigation and is being tracked as: 6445248 dbx cannot grok Linux processes 4.4. Live Upgrade and Packaging Tools Live upgrade doesn't run with zones. The packaging tools will go into the install gate 63242179 packaging tools need to be brand aware has been filed and links to this case. PSARC/2006/440 has been submitted and approved for working with live upgrade. 4.5. Audio There is no notion of a device-specific attribute, which is needed to support systems with multiple audio devices, in the zone's infrastructure now. Adding such a capability would have required an extensive overhaul of how devices are configured and managed. Rather than redesign the core of the zones configuration tools simply to solve one Linux corner case, the project team chose to use the generic attributes mechanism to sup- port audio devices. 4.6. Trusted Solaris Extensions After discussions between the project teams for this case and for the Trusted Extensions, it was determined that branded zones will not be supportted on trusted systems where labels are active. 4.7. lxrun PSARC/2006/441 has been submitted and approved to EOL lxrun. 4.8. Process Auditing Processes running in an lx-branded zone do not have their Linux system calls audited. Otherwise, they are subject to all the standard auditing. For example, Linux process creation/exit events are captured as for any other process. The Solaris system calls that the brand library uses to PSARC/2005/471 Copyright 2006 Sun Microsystems - 7 - emulate the Linux system calls are subject to auditing. The only restriction is that the Solaris audit processing tools cannot run inside the Linux zone, so the audit records must be consumed by tools running in the global zone. 4.9. Signals to init During inception, PSARC expressed a concern about how the lx init would deal with system generated signals that it was not expecting. The project team has addressed these concerns as follows. With standard Solaris zones, the kernel and init are in agreement on how to handle the death of init: the kernel restarts the process, and the resurrected init process uses a state file to pick up where its predecessor left off. The Linux init is not prepared to handle this kind of res- tart. When it is restarted, it works its way through the entire boot process again. This means that all the rc.d scripts are rerun, and we end up with multiple instances of services like crond, syslogd, and so on. Since it cannot simply ignore SIGSEGV, and since the Linux init is not prepared to handle a warm restart, the only action that will deliver a sensible result is to reboot the zone. Regardless of whether this is the expected behavior on a native Linux system, it's the behavior that will be implemented inside a Linux zone. 4.10. Delegated Administration of Solaris-specific capabil- ities Linux-branded zones will always be second-class citizens in many ways. As our real goal is to increase Solaris adop- tion, using BrandZ as one part of a migration strategy, we view this as a feature rather than a bug. To address these specific issues: ZFS delegation will not work within a Linux zone. Given sufficient customer interest, we could possibly support the ZFS utilities, but it would take a significant amount of engineering work, and would violate our "one binary type per zone" model. It should be noted that this in no way affects being able to install and run a Linux zone on a ZFS filesystem. Supporting network delegation is significantly more feasi- ble. By emulating the ioctl()s needed to perform network configuration tasks, we should be able to support network delegation using Linux configuration tools. This would not be a trivial engineering effort, but it would certainly fit PSARC/2005/471 Copyright 2006 Sun Microsystems - 8 - within the overall BrandZ model. 4.11. Impact on Zones Upgrade The zones test suite, which is run as a regular part of the PIT suite, will be extended to include testing of lx-branded zones. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/471. 1. Specification File: final.materials/design.pdf File: committment.materials/onepager File: committment.materials/what_works 2. 20 Questions File: final.materials/20_questions 3. Man Pages File: committment.materials/brand.dtd.1 File: committment.materials/brands.5 File: committment.materials/design.pdf File: committment.materials/lx.5 File: committment.materials/zone_platform.dtd.1 File: committment.materials/zoneadm.1m File: committment.materials/zonecfg.1m File: committment.materials/zones.5 4. Contract between Solaris Core Technologies and Solaris Install PSARC/2005/471 Copyright 2006 Sun Microsystems - 9 - File: contract-01 PSARC/2005/471 Copyright 2006 Sun Microsystems --Boundary_(ID_UnZMcdU9vaRDm/7PqCK2lQ)-- --Boundary_(ID_hxNlOxfKGIsgspG2dHEPuQ)-- From sacadmin Tue Aug 22 03:44:22 2006 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 k7MAiKdA007376 for ; Tue, 22 Aug 2006 03:44:21 -0700 (PDT) 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 k7MAiEOM027701 for ; Tue, 22 Aug 2006 18:44:15 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4E00001B53VL00@mail-apac.sun.com> (original mail from Zoram.Thanga@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 22 Aug 2006 18:44:14 +0800 (SGT) Received: from [129.158.239.158] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4E008EVB5P9BW2@mail-apac.sun.com> for psarc@sac.sfbay.sun.com; Tue, 22 Aug 2006 18:44:14 +0800 (SGT) Date: Tue, 22 Aug 2006 16:13:00 +0530 From: Zoram Thanga Subject: Re: [Fwd: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones] In-reply-to: <44EA539D.3050209@Sun.COM> Sender: Zoram.Thanga@Sun.COM To: Alan Hargreaves Cc: psarc@sac.sfbay.sun.com Reply-to: Zoram.Thanga@Sun.COM Message-id: <44EADFB4.4090906@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <44EA539D.3050209@Sun.COM> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 693 > > 4.6. Trusted Solaris Extensions > > After discussions between the project teams for this case > and for the Trusted Extensions, it was determined that > branded zones will not be supportted on trusted systems > where labels are active. > This is probably a nit, but shouldn't the above specifically say that "lx branded zones will not be supported on trusted systems where labels are active"? Because, if I understand correctly, once the BrandZ infrastructure is integrated all zones will be branded zones - native, and lx at present. It sounds reasonable to forbid "lx" branded zones in a trusted system. Thanks, Zoram -- Zoram Thanga, Sun Cluster Development. From sacadmin Tue Aug 29 18:15:07 2006 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 k7U1F65T001055 for ; Tue, 29 Aug 2006 18:15:06 -0700 (PDT) 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 k7U1Eurb008607 for ; Wed, 30 Aug 2006 09:15:00 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4S00501DYOMQ00@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 30 Aug 2006 09:14:56 +0800 (SGT) Received: from [192.168.10.101] ([60.240.40.166]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4S003NFE4I5DQG@mail-apac.sun.com> for psarc@sac.sfbay.sun.com; Wed, 30 Aug 2006 09:14:56 +0800 (SGT) Date: Wed, 30 Aug 2006 10:10:13 +1000 From: Alan Hargreaves Subject: Re: [Fwd: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones] In-reply-to: <44EADFB4.4090906@Sun.COM> Sender: Alan.Hargreaves@Sun.COM To: Zoram.Thanga@Sun.COM Cc: psarc@sac.sfbay.sun.com Message-id: <44F4D765.8040801@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <44EA539D.3050209@Sun.COM> <44EADFB4.4090906@Sun.COM> User-Agent: Mail/News 1.5.0.4 (X11/20060801) Status: RO Content-Length: 976 OK folks, I've only had one suggestion (below) which I have incorporated. I'll be sending this off to sac-review shortly. alan. Zoram Thanga wrote: >> >> 4.6. Trusted Solaris Extensions >> >> After discussions between the project teams for this case >> and for the Trusted Extensions, it was determined that >> branded zones will not be supportted on trusted systems >> where labels are active. >> > > This is probably a nit, but shouldn't the above specifically say that > "lx branded zones will not be supported on trusted systems where labels > are active"? Because, if I understand correctly, once the BrandZ > infrastructure is integrated all zones will be branded zones - native, > and lx at present. > > It sounds reasonable to forbid "lx" branded zones in a trusted system. > > > Thanks, > Zoram -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Systems Technical Service Center Sun Microsystems From sac-owner Tue Aug 29 18:24:10 2006 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 k7U1O8gQ001121 for ; Tue, 29 Aug 2006 18:24:09 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7U1O2c1011540 for ; Wed, 30 Aug 2006 09:24:03 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4S00A01EJKYN00@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 30 Aug 2006 09:24:02 +0800 (SGT) Received: from [192.168.10.101] ([129.150.152.15]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4S003T1EJZ5DQG@mail-apac.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 30 Aug 2006 09:24:02 +0800 (SGT) Date: Wed, 30 Aug 2006 11:23:07 +1000 From: Alan Hargreaves Subject: Opinion for Review: PSARC/2005/471 - BrandZ Support for non-native zones Sender: Alan.Hargreaves@Sun.COM To: sac-review@sac.sfbay.sun.com Message-id: <44F4E87B.4070607@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_/iXrAkhVcezWxCbX4uuG2w)" User-Agent: Mail/News 1.5.0.4 (X11/20060801) Status: RO Content-Length: 23612 This is a multi-part message in MIME format. --Boundary_(ID_/iXrAkhVcezWxCbX4uuG2w) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Please review the attached opinion by 09/05/2006. Pdf, ps, txt & *roff are available in the case directory (opinion.*) alan. -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Systems Technical Service Center Sun Microsystems --Boundary_(ID_/iXrAkhVcezWxCbX4uuG2w) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: BrandZ Support for non-native zones Submitted by: Nils Niewejaar File: PSARC/2005/471/opinion.ms Date: July 28th, 2006 Committee: Ed Gould (Opinion by Alan Hargreaves), James D Carlson, Glenn Skinner, William Sommerfeld, Gary Winiger. Product Approval Committee: solaris-pac-opinion@sun.com 1. Summary BrandZ is an extension of the zones infrastructure that allows the creation of zones that emulate non-native operat- ing system environments, such as Linux, FreeBSD, or older versions of Solaris. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. The project supercedes PSARC/2003/445: Janus: Linux binary compatibility for Solaris x86. The project depends on PSARC/2006/440: BrandZ-aware Installer and may not be delivered before it. 3. Interfaces The project exports the following interfaces. ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| | | | | | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 2 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |Linux Interfaces: | External | This category includes| | | | all of the different| |System calls (structure,| | Linux interfaces that the| |semantics and calling conven-| | lx brand emulates. | |tions) | | | | | | | |/dev (names and major/minor| | | |#'s) | | | |/proc | | | |signal numbers | | | |error numbers | | | |______________________________|_________________|___________________________| |AT_SUN_BRAND_BASE | Project Private| Additional AUX vector| |AT_SUN_BRAND_LDDATA | | flags used to convey| |AT_SUN_BRAND_LDENTRY | | brand information to the| |AT_SUN_BRAND_BRANDNAME | | Solaris linker | |AT_SUN_BRAND_PHDR | | | |AT_SUN_BRAND_PHENT | | | |AT_SUN_BRAND_PHNUM | | | |AT_SUN_BRAND_ENTRY | | | |______________________________|_________________|___________________________| |config.xml | Project Private| Brand definition | |______________________________|_________________|___________________________| |platform.xml | Project Private| Virtual platform defini-| | | | tion | |______________________________|_________________|___________________________| |struct modlbrand | Consolidation | kernel/brand module link-| | | Private | age interface | |______________________________|_________________|___________________________| |struct brand | Project Private| Kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_ops | Project Private| Kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_mach_ops | Project Private| Arch-specific | | | | kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_attr | Project Private| Userspace/kernel inter-| | | | face | |______________________________|_________________|___________________________| |struct lx_brand_registration | Project Private| Userspace/kernel inter-| | | | face | |______________________________|_________________|___________________________| |rd_helper_ops_t | Consolidation | librtld_db.so helper plu-| | | Private | gin interface | |______________________________|_________________|___________________________| | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 3 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |brand_open() brand_close() | Project Private| libbrand.so.1 is a new| |brand_is_native() | | library for parsing the| |brand_get_boot() | | BrandZ .xml files | |brand_get_halt() | | | |brand_get_initname() | | | |brand_get_install() | | | |brand_get_modename() | | | |brand_get_postclone() | | | |brand_get_verify() | | | |brand_platform_iter_gmounts() | | | |brand_platform_iter_lmounts() | | | |brand_platform_iter_devdir() | | | |brand_platform_iter_link() | | | |______________________________|_________________|___________________________| |zonecfg_get_brand() | Contracted Pro-| Added to libzonecfg.so.1 | |zone_get_brand() | ject Private | Contract in reference [4]| |______________________________|_________________|___________________________| |zonecfg(1M) | Evolving | Added -B option | |______________________________|_________________|___________________________| |zoneadm(1M) | Project Private| Added -f (force) option| | | | to mount and boot com-| | | | mands | | | | Added "brand" column to| | | | verbose "list" output | |______________________________|_________________|___________________________| |zonecfg(1M) | Evolving | Added -B option | |______________________________|_________________|___________________________| |lockd(1M) statd(1M) | Consolidation | Added -P option to indi-| | | Private | cate portportmapper usage| |______________________________|_________________|___________________________| |libnsl(3LIB) | Consolidation | Add __use_portmapper() to| | | Private | resurrect old portmapper| | | | support | |______________________________|_________________|___________________________| |streamio(7I) | Evolving | Add support for| | | | TIOCSCTTY, TIOCNOTTY,| | | | TIOCSETLD and TOICGETLD | |______________________________|_________________|___________________________| |uucopy(2) | Evolving | Added to libc.so.1 See | | | | design doc: 3.5.2 | |______________________________|_________________|___________________________| |set_setcontext_enforcement(3C)| Consolidation | Added to libc.so.1 See | | | Private | design doc 3.6.2 | |______________________________|_________________|___________________________| |setsigacthandler(3C) | Consolidation | Added to libc.so.1 See | | | Private | design doc 3.6.1 | |______________________________|_________________|___________________________| | | | | | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 4 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |lx-install(1M) | Evolving | Invoked by zoneadm(1M),| | | | but options are user-| | | | visible | |______________________________|_________________|___________________________| |lx-syscall(7D) | Evolving | Linux syscall provider | |______________________________|_________________|___________________________| |lx_ptm(7D) | Project Private| Linux pty master driver | |______________________________|_________________|___________________________| |ldlinux(7M) | Project Private| STREAMS module that pro-| | | | vides Linux termio(7I)| | | | semantics | |______________________________|_________________|___________________________| |lx_afs(7D) | Project Private| Linux automounter support| |______________________________|_________________|___________________________| |lx_audio(7D) | Project Private| Layered driver to convert| | | | Linux semantics to| | | | Solaris | |______________________________|_________________|___________________________| |______________________________|_________________|___________________________| The project imports the following interfaces. ____________________________________________________________________________ | Interfaces Imported | |_______________________|________________|_________________________________| |Interface | Classification| Comments | |_______________________|________________|_________________________________| |Linux syscall Interface| External | | |_______________________|________________|_________________________________| |rpm2cpio(1M) CLI rpm | External | Used to install RedHat software| |CLI | | | |_______________________|________________|_________________________________| |Linux statd(1M) and| External | Used to support NFS locking| |lockd(1M) uid/gid #'s | | within lx branded zones | |_______________________|________________|_________________________________| |glibc ABI | External | Used to provide naming services| | gethostbyname_r | | to Solaris statd(1M) and| | gethostbyaddr_r | | lockd(1M) daemons. See section| | getservbyname_r | | 3.8 of the design doc. | | getservbyport_r | | | | openlog | | | | syslog | | | | closelog | | | | __progname | | | |_______________________|________________|_________________________________| | | | | | | | | | | | | |_______________________|________________|_________________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 5 - ____________________________________________________________________________ | Interfaces Imported | |_______________________|________________|_________________________________| |Interface | Classification| Comments | |_______________________|________________|_________________________________| |RHEL 3.x contents | External | /etc files, rc.d scripts, etc.| | | | which we modify at install| | | | time. | |_______________________|________________|_________________________________| |Linux ELF format | External | Object file format for Linux| | | | binaries | |_______________________|________________|_________________________________| 4. Opinion 4.1. The lx Brand The word Linux is a trademark. To avoid issues, the name lx is used to reference linux branded zones. PSARC had concerns about the management of this namespace for future brands and releases of linux. As a result, refer- ences to specific releases of the linux kernel were removed from the documentation. 4.2. Executable Stacks For compatibility BrandZ has to allow Linux applications to run with executable stacks, so those applications are vulnerable to any security holes that are opened by those stacks. However, since it is running inside a zone, any dam- age would be confined to that BrandZ instance. A compromised zone will not be able to bring down the system, and will neither have access to, nor be able to damage applications or data in other zones. Considered more generally, a BrandZ-hosted linux environment will be subject to any security holes in the Linux user- space. However, it will not be vulnerable to any security holes that depend on kernel support or kernel bugs. This would arguably make a BrandZ-hosted RHEL 3 environment more secure than a native RHEL 3 environment. 4.3. Truss, Apptrace and Dbx Truss has been updated to recognize the new Solaris system calls; it has not been updated to understand and display the Linux system calls issued by the application. An lx-syscall DTrace provider makes that information available. PSARC/2005/471 Copyright 2006 Sun Microsystems - 6 - dbx does not currently work, but this appears to be a bug rather than a fundamental limitation of the design. This is still under investigation and is being tracked as: 6445248 dbx cannot grok Linux processes 4.4. Live Upgrade and Packaging Tools Live upgrade doesn't run with zones. The packaging tools will go into the install gate 63242179 packaging tools need to be brand aware has been filed and links to this case. PSARC/2006/440 has been submitted and approved for working with live upgrade. 4.5. Audio There is no notion of a device-specific attribute, which is needed to support systems with multiple audio devices, in the zone's infrastructure now. Adding such a capability would have required an extensive overhaul of how devices are configured and managed. Rather than redesign the core of the zones configuration tools simply to solve one Linux corner case, the project team chose to use the generic attributes mechanism to sup- port audio devices. 4.6. Trusted Solaris Extensions After discussions between the project teams for this case and for the Trusted Extensions, it was determined that lx branded zones will not be supported on trusted systems where labels are active. 4.7. lxrun PSARC/2006/441 has been submitted and approved to EOL lxrun. 4.8. Process Auditing Processes running in an lx-branded zone do not have their Linux system calls audited. Otherwise, they are subject to all the standard auditing. For example, Linux process creation/exit events are captured as for any other process. The Solaris system calls that the brand library uses to PSARC/2005/471 Copyright 2006 Sun Microsystems - 7 - emulate the Linux system calls are subject to auditing. The only restriction is that the Solaris audit processing tools cannot run inside the Linux zone, so the audit records must be consumed by tools running in the global zone. 4.9. Signals to init During inception, PSARC expressed a concern about how the lx init would deal with system generated signals that it was not expecting. The project team has addressed these concerns as follows. With standard Solaris zones, the kernel and init are in agreement on how to handle the death of init: the kernel restarts the process, and the resurrected init process uses a state file to pick up where its predecessor left off. The Linux init is not prepared to handle this kind of res- tart. When it is restarted, it works its way through the entire boot process again. This means that all the rc.d scripts are rerun, and we end up with multiple instances of services like crond, syslogd, and so on. Since it cannot simply ignore SIGSEGV, and since the Linux init is not prepared to handle a warm restart, the only action that will deliver a sensible result is to reboot the zone. Regardless of whether this is the expected behavior on a native Linux system, it's the behavior that will be implemented inside a Linux zone. 4.10. Delegated Administration of Solaris-specific capabil- ities Linux-branded zones will always be second-class citizens in many ways. As our real goal is to increase Solaris adop- tion, using BrandZ as one part of a migration strategy, we view this as a feature rather than a bug. To address these specific issues: ZFS delegation will not work within a Linux zone. Given sufficient customer interest, we could possibly support the ZFS utilities, but it would take a significant amount of engineering work, and would violate our "one binary type per zone" model. It should be noted that this in no way affects being able to install and run a Linux zone on a ZFS filesystem. Supporting network delegation is significantly more feasi- ble. By emulating the ioctl()s needed to perform network configuration tasks, we should be able to support network delegation using Linux configuration tools. This would not be a trivial engineering effort, but it would certainly fit PSARC/2005/471 Copyright 2006 Sun Microsystems - 8 - within the overall BrandZ model. 4.11. Impact on Zones Upgrade The zones test suite, which is run as a regular part of the PIT suite, will be extended to include testing of lx-branded zones. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/471. 1. Specification File: final.materials/design.pdf File: committment.materials/onepager File: committment.materials/what_works 2. 20 Questions File: final.materials/20_questions 3. Man Pages File: committment.materials/brand.dtd.1 File: committment.materials/brands.5 File: committment.materials/design.pdf File: committment.materials/lx.5 File: committment.materials/zone_platform.dtd.1 File: committment.materials/zoneadm.1m File: committment.materials/zonecfg.1m File: committment.materials/zones.5 4. Contract between Solaris Core Technologies and Solaris Install PSARC/2005/471 Copyright 2006 Sun Microsystems - 9 - File: contract-01 PSARC/2005/471 Copyright 2006 Sun Microsystems --Boundary_(ID_/iXrAkhVcezWxCbX4uuG2w)-- From sac-owner Wed Aug 30 11:04:59 2006 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 k7UI4xod027240 for ; Wed, 30 Aug 2006 11:04:59 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UI4xeL029496 for ; Wed, 30 Aug 2006 11:04:59 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UI4sAj002641 for ; Wed, 30 Aug 2006 11:04:54 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4T00601ORN7900@d1-sfbay-09.sun.com> (original mail from edh@sun.com) for sac-review@sac.sfbay.sun.com; Wed, 30 Aug 2006 11:04:54 -0700 (PDT) Received: from [129.146.72.132] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4T001GGOW58PPD@d1-sfbay-09.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 30 Aug 2006 11:04:54 -0700 (PDT) Date: Wed, 30 Aug 2006 11:03:07 -0700 From: Edward Hunter Subject: Re: Opinion for Review: PSARC/2005/471 - BrandZ Support for non-native zones In-reply-to: <44F4E87B.4070607@Sun.COM> Sender: Ed.Hunter@sun.com To: Alan Hargreaves Cc: sac-review@sac.sfbay.sun.com Message-id: <44F5D2DB.9010904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <44F4E87B.4070607@Sun.COM> User-Agent: Mail/News 1.5.0.2 (X11/20060515) Status: RO Content-Length: 1221 Alan Hargreaves wrote: > > 4. Opinion > > 4.1. The lx Brand > > The word Linux is a trademark. To avoid issues, the name lx > is used to reference linux branded zones. > > PSARC had concerns about the management of this namespace > for future brands and releases of linux. As a result, refer- > ences to specific releases of the linux kernel were removed > from the documentation. > > Does this mean the namespace is no longer being managed? Or that future releases will not ever refer to specific releases of a kernel? > > 4.3. Truss, Apptrace and Dbx > > Truss has been updated to recognize the new Solaris system > calls; it has not been updated to understand and display the > Linux system calls issued by the application. An lx-syscall > Does this mean the plan is to not update Truss? Just curious. > DTrace provider makes that information available. > > PSARC/2005/471 > > - 6 - > > dbx does not currently work, but this appears to be a bug > rather than a fundamental limitation of the design. This is > still under investigation and is being tracked as: > > 6445248 dbx cannot grok Linux processes > > > From sacadmin Wed Aug 30 19:42:19 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 k7V2gIGl012651 for ; Wed, 30 Aug 2006 19:42:18 -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 k7V2gHlq005196; Wed, 30 Aug 2006 19:42:17 -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 k7V2hp1M008501; Wed, 30 Aug 2006 19:43:51 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k7V2hpLI008500; Wed, 30 Aug 2006 19:43:51 -0700 (PDT) Date: Wed, 30 Aug 2006 19:43:51 -0700 (PDT) From: Gary Winiger Message-Id: <200608310243.k7V2hpLI008500@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com, Alan.Hargreaves@sun.com Subject: Re: [Fwd: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones] X-Sun-Charset: US-ASCII Status: RO Content-Length: 540 > 1. Summary > > BrandZ is an extension of the zones infrastructure that > allows the creation of zones that emulate non-native operat- > ing system environments, such as Linux, FreeBSD, or older > versions of Solaris. My recollection is that this was discussed and the project team said it was overly optimistic, particularly for older versions of Solaris. > 4.6. Trusted Solaris Extensions Nit, I believe it is officially Solaris Trusted Extensions. Please check with the project team. rampart-dev-team@sun.com Gary.. From sacadmin Wed Sep 6 21:26:27 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k874QRI3022988 for ; Wed, 6 Sep 2006 21:26:27 -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 k874SBNu020966; Wed, 6 Sep 2006 21:28:11 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k874SBvp020965; Wed, 6 Sep 2006 21:28:11 -0700 (PDT) Date: Wed, 6 Sep 2006 21:28:11 -0700 (PDT) From: Gary Winiger Message-Id: <200609070428.k874SBvp020965@marduk.eng.sun.com> To: gww@eng.sun.com, Alan.Hargreaves@sun.com Subject: Re: [Fwd: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones] Cc: psarc@sac.sfbay.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1643 Alan, > Gary, I've fixed the nit. With regard to the first comment, I agree with > you, but that's what the materials say. Whether or not there are plans > to actually do it are probably not relevant to the opinion. As I replied to the case in psarc review and this is a valid question to pose to the committe as a whole, I've cc-ed the case. IMO, Summaries should reflect what the approved case is actually doing rather than what they might have done, or some speculation on what another project might build on this case. So, I stand by my comment that I don't believe the summary reflects what the project team said they were going to do. Of course, other's may have different opinions ;-) Gary.. > > alan. > > Gary Winiger wrote: > >> 1. Summary > >> > >> BrandZ is an extension of the zones infrastructure that > >> allows the creation of zones that emulate non-native operat- > >> ing system environments, such as Linux, FreeBSD, or older > >> versions of Solaris. > > > > My recollection is that this was discussed and the project team > > said it was overly optimistic, particularly for older versions > > of Solaris. > >> 4.6. Trusted Solaris Extensions > > > > Nit, I believe it is officially Solaris Trusted Extensions. > > Please check with the project team. rampart-dev-team@sun.com > > > > Gary.. > > > -- > Alan Hargreaves - http://blogs.sun.com/tpenta > Staff Engineer (Kernel/VOSJEC/Performance) > Systems Technical Service Center > Sun Microsystems > > I went in the World's Greatest shave for Leukaemia. See > http://blogs.sun.com/roller/page/tpenta?entry=hair_yesterday_gone_today > From sacadmin Thu Sep 7 03:21:42 2006 Received: from engmail4sca.SFBay.Sun.COM (engmail4sca.SFBay.Sun.COM [129.145.155.74]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k87ALgDf027999 for ; Thu, 7 Sep 2006 03:21:42 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by engmail4sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k87ALf1Z000943 for ; Thu, 7 Sep 2006 03:21:41 -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 k87ALZZE022352 for ; Thu, 7 Sep 2006 18:21:35 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5700C01WRBJE00@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for psarc@sac.eng.sun.com; Thu, 07 Sep 2006 18:21:35 +0800 (SGT) Received: from [192.168.10.101] ([129.150.152.5]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J57004K5WRTQP76@mail-apac.sun.com>; Thu, 07 Sep 2006 18:21:35 +0800 (SGT) Date: Thu, 07 Sep 2006 20:20:34 +1000 From: Alan Hargreaves Subject: Re: [Fwd: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones] In-reply-to: <200609070428.k874SBvp020965@marduk.eng.sun.com> Sender: Alan.Hargreaves@Sun.COM To: Gary Winiger Cc: psarc@sac.sfbay.sun.com Message-id: <44FFF272.6070904@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200609070428.k874SBvp020965@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060815) Status: RO Content-Length: 2043 The lead in paragraph currently reads: BrandZ is an extension of the zones infrastructure that allows the creation of zones that emulate non-native operat- ing system environments, such as Linux, FreeBSD, or older versions of Solaris. Would the following rewording satisfy folks? BrandZ is an extension of the zones infrastructure that allows the creation of zones that emulate non-native operat- ing system environments. While the design and implementation allows for such environments as Linux, FreeBSD, or older versions of Solaris, there are currently only plans for the implementation of the Linux branded zones. alan. Gary Winiger wrote: > Alan, > >> Gary, I've fixed the nit. With regard to the first comment, I agree with >> you, but that's what the materials say. Whether or not there are plans >> to actually do it are probably not relevant to the opinion. > > As I replied to the case in psarc review and this is a valid > question to pose to the committe as a whole, I've cc-ed the case. > > IMO, Summaries should reflect what the approved case is actually > doing rather than what they might have done, or some speculation > on what another project might build on this case. So, I stand > by my comment that I don't believe the summary reflects what > the project team said they were going to do. > Of course, other's may have different opinions ;-) > > Gary.. >> alan. >> >> Gary Winiger wrote: >>>> 1. Summary >>>> >>>> BrandZ is an extension of the zones infrastructure that >>>> allows the creation of zones that emulate non-native operat- >>>> ing system environments, such as Linux, FreeBSD, or older >>>> versions of Solaris. >>> My recollection is that this was discussed and the project team >>> said it was overly optimistic, particularly for older versions >>> of Solaris. >>>> 4.6. Trusted Solaris Extensions >>> Nit, I believe it is officially Solaris Trusted Extensions. >>> Please check with the project team. rampart-dev-team@sun.com >>> >>> Gary.. From sacadmin Thu Sep 7 05:36:35 2006 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 k87CaYg8029797 for ; Thu, 7 Sep 2006 05:36:34 -0700 (PDT) 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 k87CaR6C016119 for ; Thu, 7 Sep 2006 20:36:28 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J58008012TET300@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 07 Sep 2006 20:36:27 +0800 (SGT) Received: from [192.168.10.101] ([129.150.152.5]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5800JMU30P4FMA@mail-apac.sun.com>; Thu, 07 Sep 2006 20:36:27 +0800 (SGT) Date: Thu, 07 Sep 2006 22:35:30 +1000 From: Alan Hargreaves Subject: Re: [Fwd: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones] In-reply-to: <44FFF272.6070904@Sun.COM> Sender: Alan.Hargreaves@Sun.COM To: Gary Winiger Cc: psarc@sac.sfbay.sun.com Message-id: <45001212.1040202@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200609070428.k874SBvp020965@marduk.eng.sun.com> <44FFF272.6070904@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060815) Status: RO Content-Length: 971 Alan Hargreaves wrote: > The lead in paragraph currently reads: > > BrandZ is an extension of the zones infrastructure that > allows the creation of zones that emulate non-native operat- > ing system environments, such as Linux, FreeBSD, or older > versions of Solaris. > > Would the following rewording satisfy folks? > > BrandZ is an extension of the zones infrastructure that > allows the creation of zones that emulate non-native operat- > ing system environments. While the design and implementation > allows for such environments as Linux, FreeBSD, or older > versions of Solaris, there are currently only plans for the > implementation of the Linux branded zones. On re-reading that I could probably remove the words "and implementation" from line 3. alan. -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Systems Technical Service Center Sun Microsystems From sacadmin Thu Sep 7 07:57:17 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 k87EvGgw002257 for ; Thu, 7 Sep 2006 07:57:16 -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 k87EvGOb011276; Thu, 7 Sep 2006 07:57:16 -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 k87Ex15x021211; Thu, 7 Sep 2006 07:59:01 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k87Ex1Te021210; Thu, 7 Sep 2006 07:59:01 -0700 (PDT) Date: Thu, 7 Sep 2006 07:59:01 -0700 (PDT) From: Gary Winiger Message-Id: <200609071459.k87Ex1Te021210@marduk.eng.sun.com> To: gww@eng.sun.com, Alan.Hargreaves@sun.com Subject: Re: [Fwd: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones] Cc: psarc@sac.sfbay.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1142 > Alan Hargreaves wrote: > > The lead in paragraph currently reads: > > > > BrandZ is an extension of the zones infrastructure that > > allows the creation of zones that emulate non-native operat- > > ing system environments, such as Linux, FreeBSD, or older > > versions of Solaris. > > > > Would the following rewording satisfy folks? > > > > BrandZ is an extension of the zones infrastructure that > > allows the creation of zones that emulate non-native operat- > > ing system environments. While the design and implementation > > allows for such environments as Linux, FreeBSD, or older > > versions of Solaris, there are currently only plans for the > > implementation of the Linux branded zones. > > On re-reading that I could probably remove the words "and > implementation" from line 3. Perhaps just: BrandZ is an extension of the zones infrastructure that allows the creation of zones that emulate non-native operat- ing system environments, such as Linux. Future projects may extend this project to build other non-native operating environments. Gary.. From sacadmin Thu Sep 7 13:51:40 2006 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 k87Kpdxj015020 for ; Thu, 7 Sep 2006 13:51:39 -0700 (PDT) Received: from fe-apac-02.sun.com (fe-apac-02.sun.com [192.18.19.173] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k87KpTdJ005243 for ; Fri, 8 Sep 2006 04:51:33 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5800I01P9SDI00@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 08 Sep 2006 04:51:29 +0800 (SGT) Received: from [192.168.10.101] ([129.150.152.5]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5800NDCPXR4910@mail-apac.sun.com>; Fri, 08 Sep 2006 04:51:29 +0800 (SGT) Date: Fri, 08 Sep 2006 06:50:30 +1000 From: Alan Hargreaves Subject: Re: [Fwd: Opinion for Review: PSARC/2005/471 BrandZ Support for non-native zones] In-reply-to: <200609071459.k87Ex1Te021210@marduk.eng.sun.com> Sender: Alan.Hargreaves@Sun.COM To: Gary Winiger Cc: psarc@sac.sfbay.sun.com Message-id: <45008616.8040806@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200609071459.k87Ex1Te021210@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060815) Status: RO Content-Length: 1407 Gary Winiger wrote: >> Alan Hargreaves wrote: >>> The lead in paragraph currently reads: >>> >>> BrandZ is an extension of the zones infrastructure that >>> allows the creation of zones that emulate non-native operat- >>> ing system environments, such as Linux, FreeBSD, or older >>> versions of Solaris. >>> >>> Would the following rewording satisfy folks? >>> >>> BrandZ is an extension of the zones infrastructure that >>> allows the creation of zones that emulate non-native operat- >>> ing system environments. While the design and implementation >>> allows for such environments as Linux, FreeBSD, or older >>> versions of Solaris, there are currently only plans for the >>> implementation of the Linux branded zones. >> On re-reading that I could probably remove the words "and >> implementation" from line 3. > > Perhaps just: > > BrandZ is an extension of the zones infrastructure that > allows the creation of zones that emulate non-native operat- > ing system environments, such as Linux. Future projects may > extend this project to build other non-native operating > environments. > > Gary.. Thanks Gary, that is *exactly* what I was trying to capture with the change. alan. -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Systems Technical Service Center Sun Microsystems From sac-owner Thu Sep 7 16:24: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 k87NOa6C020272 for ; Thu, 7 Sep 2006 16:24:36 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k87NOYj2022300 for ; Thu, 7 Sep 2006 16:24:35 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k87NOS3g007253 for ; Fri, 8 Sep 2006 07:24:29 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5800701WPQFO00@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for sac-opinion@sac.eng.sun.com; Fri, 08 Sep 2006 07:24:28 +0800 (SGT) Received: from [192.168.10.101] ([129.150.152.5]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5800JXJX0O4FAC@mail-apac.sun.com>; Fri, 08 Sep 2006 07:24:27 +0800 (SGT) Date: Fri, 08 Sep 2006 09:23:27 +1000 From: Alan Hargreaves Subject: Opinion: PSARC/2005/471 BrandZ Support for non-native zones Sender: Alan.Hargreaves@Sun.COM To: sac-opinion@sac.sfbay.sun.com, solaris-pac-opinion@Sun.COM, Nils Nieuwejaar Message-id: <4500A9EF.2030208@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_8TyhygJco7SYjt/EMbKZiA)" User-Agent: Thunderbird 1.5.0.5 (X11/20060815) Status: RO Content-Length: 23727 This is a multi-part message in MIME format. --Boundary_(ID_8TyhygJco7SYjt/EMbKZiA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT PSARC case 2005/471 BrandZ Support for non-native zones is closed approved, and the IAM file has been updated. Below is the final opinion, which can be found at: http://sac.sfbay.sun.com/arc/PSARC/2005/471/opinion.txt along with troff, postscript and pdf versions thereof. alan. --Boundary_(ID_8TyhygJco7SYjt/EMbKZiA) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: BrandZ Support for non-native zones Submitted by: Nils Niewejaar File: PSARC/2005/471/opinion.ms Date: July 28th, 2006 Committee: Ed Gould (Opinion by Alan Hargreaves), James D Carlson, Glenn Skinner, William Sommerfeld, Gary Winiger. Product Approval Committee: solaris-pac-opinion@sun.com 1. Summary BrandZ is an extension of the zones infrastructure that allows the creation of zones that emulate non-native operat- ing system environments, such as Linux. Future projects may extend this project to build other non-native operating environments. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. The project supercedes PSARC/2003/445: Janus: Linux binary compatibility for Solaris x86. The project depends on PSARC/2006/440: BrandZ-aware Installer and may not be delivered before it. 3. Interfaces The project exports the following interfaces. ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 2 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |Linux Interfaces: | External | This category includes| | | | all of the different| |System calls (structure,| | Linux interfaces that the| |semantics and calling conven-| | lx brand emulates. | |tions) | | | | | | | |/dev (names and major/minor| | | |#'s) | | | |/proc | | | |signal numbers | | | |error numbers | | | |______________________________|_________________|___________________________| |AT_SUN_BRAND_BASE | Project Private| Additional AUX vector| |AT_SUN_BRAND_LDDATA | | flags used to convey| |AT_SUN_BRAND_LDENTRY | | brand information to the| |AT_SUN_BRAND_BRANDNAME | | Solaris linker | |AT_SUN_BRAND_PHDR | | | |AT_SUN_BRAND_PHENT | | | |AT_SUN_BRAND_PHNUM | | | |AT_SUN_BRAND_ENTRY | | | |______________________________|_________________|___________________________| |config.xml | Project Private| Brand definition | |______________________________|_________________|___________________________| |platform.xml | Project Private| Virtual platform defini-| | | | tion | |______________________________|_________________|___________________________| |struct modlbrand | Consolidation | kernel/brand module link-| | | Private | age interface | |______________________________|_________________|___________________________| |struct brand | Project Private| Kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_ops | Project Private| Kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_mach_ops | Project Private| Arch-specific | | | | kernel/brand operational| | | | interface | |______________________________|_________________|___________________________| |struct brand_attr | Project Private| Userspace/kernel inter-| | | | face | |______________________________|_________________|___________________________| |struct lx_brand_registration | Project Private| Userspace/kernel inter-| | | | face | |______________________________|_________________|___________________________| |rd_helper_ops_t | Consolidation | librtld_db.so helper plu-| | | Private | gin interface | |______________________________|_________________|___________________________| | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 3 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |brand_open() brand_close() | Project Private| libbrand.so.1 is a new| |brand_is_native() | | library for parsing the| |brand_get_boot() | | BrandZ .xml files | |brand_get_halt() | | | |brand_get_initname() | | | |brand_get_install() | | | |brand_get_modename() | | | |brand_get_postclone() | | | |brand_get_verify() | | | |brand_platform_iter_gmounts() | | | |brand_platform_iter_lmounts() | | | |brand_platform_iter_devdir() | | | |brand_platform_iter_link() | | | |______________________________|_________________|___________________________| |zonecfg_get_brand() | Contracted Pro-| Added to libzonecfg.so.1 | |zone_get_brand() | ject Private | Contract in reference [4]| |______________________________|_________________|___________________________| |zonecfg(1M) | Evolving | Added -B option | |______________________________|_________________|___________________________| |zoneadm(1M) | Project Private| Added -f (force) option| | | | to mount and boot com-| | | | mands | | | | Added "brand" column to| | | | verbose "list" output | |______________________________|_________________|___________________________| |zonecfg(1M) | Evolving | Added -B option | |______________________________|_________________|___________________________| |lockd(1M) statd(1M) | Consolidation | Added -P option to indi-| | | Private | cate portportmapper usage| |______________________________|_________________|___________________________| |libnsl(3LIB) | Consolidation | Add __use_portmapper() to| | | Private | resurrect old portmapper| | | | support | |______________________________|_________________|___________________________| |streamio(7I) | Evolving | Add support for| | | | TIOCSCTTY, TIOCNOTTY,| | | | TIOCSETLD and TOICGETLD | |______________________________|_________________|___________________________| |uucopy(2) | Evolving | Added to libc.so.1 See | | | | design doc: 3.5.2 | |______________________________|_________________|___________________________| |set_setcontext_enforcement(3C)| Consolidation | Added to libc.so.1 See | | | Private | design doc 3.6.2 | |______________________________|_________________|___________________________| |setsigacthandler(3C) | Consolidation | Added to libc.so.1 See | | | Private | design doc 3.6.1 | |______________________________|_________________|___________________________| | | | | | | | | |______________________________|_________________|___________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 4 - ______________________________________________________________________________ | Interfaces Exported | |______________________________|_________________|___________________________| |Interface | Classification | Comments | |______________________________|_________________|___________________________| |lx-install(1M) | Evolving | Invoked by zoneadm(1M),| | | | but options are user-| | | | visible | |______________________________|_________________|___________________________| |lx-syscall(7D) | Evolving | Linux syscall provider | |______________________________|_________________|___________________________| |lx_ptm(7D) | Project Private| Linux pty master driver | |______________________________|_________________|___________________________| |ldlinux(7M) | Project Private| STREAMS module that pro-| | | | vides Linux termio(7I)| | | | semantics | |______________________________|_________________|___________________________| |lx_afs(7D) | Project Private| Linux automounter support| |______________________________|_________________|___________________________| |lx_audio(7D) | Project Private| Layered driver to convert| | | | Linux semantics to| | | | Solaris | |______________________________|_________________|___________________________| |______________________________|_________________|___________________________| The project imports the following interfaces. ____________________________________________________________________________ | Interfaces Imported | |_______________________|________________|_________________________________| |Interface | Classification| Comments | |_______________________|________________|_________________________________| |Linux syscall Interface| External | | |_______________________|________________|_________________________________| |rpm2cpio(1M) CLI rpm | External | Used to install RedHat software| |CLI | | | |_______________________|________________|_________________________________| |Linux statd(1M) and| External | Used to support NFS locking| |lockd(1M) uid/gid #'s | | within lx branded zones | |_______________________|________________|_________________________________| |glibc ABI | External | Used to provide naming services| | gethostbyname_r | | to Solaris statd(1M) and| | gethostbyaddr_r | | lockd(1M) daemons. See section| | getservbyname_r | | 3.8 of the design doc. | | getservbyport_r | | | | openlog | | | | syslog | | | | closelog | | | | __progname | | | |_______________________|________________|_________________________________| | | | | | | | | | | | | |_______________________|________________|_________________________________| PSARC/2005/471 Copyright 2006 Sun Microsystems - 5 - ____________________________________________________________________________ | Interfaces Imported | |_______________________|________________|_________________________________| |Interface | Classification| Comments | |_______________________|________________|_________________________________| |RHEL 3.x contents | External | /etc files, rc.d scripts, etc.| | | | which we modify at install| | | | time. | |_______________________|________________|_________________________________| |Linux ELF format | External | Object file format for Linux| | | | binaries | |_______________________|________________|_________________________________| 4. Opinion 4.1. The lx Brand The word Linux is a trademark. To avoid issues, the name lx is used to reference linux branded zones. PSARC had concerns about the management of this namespace for future brands and releases of linux. As a result, refer- ences to specific releases of the linux kernel were removed from the documentation and the lx brand will not be associ- ated with specific releases of a linux kernel. 4.2. Executable Stacks For compatibility BrandZ has to allow Linux applications to run with executable stacks, so those applications are vulnerable to any security holes that are opened by those stacks. However, since it is running inside a zone, any dam- age would be confined to that BrandZ instance. A compromised zone will not be able to bring down the system, and will neither have access to, nor be able to damage applications or data in other zones. Considered more generally, a BrandZ-hosted linux environment will be subject to any security holes in the Linux user- space. However, it will not be vulnerable to any security holes that depend on kernel support or kernel bugs. This would arguably make a BrandZ-hosted RHEL 3 environment more secure than a native RHEL 3 environment. 4.3. Truss, Apptrace and Dbx Truss has been updated to recognize the new Solaris system calls; it has not been, and will not be, updated to under- stand and display the Linux system calls issued by the application. An lx-syscall DTrace provider makes that PSARC/2005/471 Copyright 2006 Sun Microsystems - 6 - information available. dbx does not currently work, but this appears to be a bug rather than a fundamental limitation of the design. This is still under investigation and is being tracked as: 6445248 dbx cannot grok Linux processes 4.4. Live Upgrade and Packaging Tools Live upgrade doesn't run with zones. The packaging tools will go into the install gate 63242179 packaging tools need to be brand aware has been filed and links to this case. PSARC/2006/440 has been submitted and approved for working with live upgrade. 4.5. Audio There is no notion of a device-specific attribute, which is needed to support systems with multiple audio devices, in the zone's infrastructure now. Adding such a capability would have required an extensive overhaul of how devices are configured and managed. Rather than redesign the core of the zones configuration tools simply to solve one Linux corner case, the project team chose to use the generic attributes mechanism to sup- port audio devices. 4.6. Solaris Trusted Extensions After discussions between the project teams for this case and for the Trusted Extensions, it was determined that lx branded zones will not be supported on trusted systems where labels are active. 4.7. lxrun PSARC/2006/441 has been submitted and approved to EOL lxrun. 4.8. Process Auditing Processes running in an lx-branded zone do not have their Linux system calls audited. Otherwise, they are subject to all the standard auditing. For example, Linux process PSARC/2005/471 Copyright 2006 Sun Microsystems - 7 - creation/exit events are captured as for any other process. The Solaris system calls that the brand library uses to emu- late the Linux system calls are subject to auditing. The only restriction is that the Solaris audit processing tools cannot run inside the Linux zone, so the audit records must be consumed by tools running in the global zone. 4.9. Signals to init During inception, PSARC expressed a concern about how the lx init would deal with system generated signals that it was not expecting. The project team has addressed these concerns as follows. With standard Solaris zones, the kernel and init are in agreement on how to handle the death of init: the kernel restarts the process, and the resurrected init process uses a state file to pick up where its predecessor left off. The Linux init is not prepared to handle this kind of res- tart. When it is restarted, it works its way through the entire boot process again. This means that all the rc.d scripts are rerun, and we end up with multiple instances of services like crond, syslogd, and so on. Since it cannot simply ignore SIGSEGV, and since the Linux init is not prepared to handle a warm restart, the only action that will deliver a sensible result is to reboot the zone. Regardless of whether this is the expected behavior on a native Linux system, it's the behavior that will be implemented inside a Linux zone. 4.10. Delegated Administration of Solaris-specific capabil- ities Linux-branded zones will always be second-class citizens in many ways. As our real goal is to increase Solaris adop- tion, using BrandZ as one part of a migration strategy, we view this as a feature rather than a bug. To address these specific issues: ZFS delegation will not work within a Linux zone. Given sufficient customer interest, we could possibly support the ZFS utilities, but it would take a significant amount of engineering work, and would violate our "one binary type per zone" model. It should be noted that this in no way affects being able to install and run a Linux zone on a ZFS filesystem. Supporting network delegation is significantly more feasi- ble. By emulating the ioctl()s needed to perform network configuration tasks, we should be able to support network PSARC/2005/471 Copyright 2006 Sun Microsystems - 8 - delegation using Linux configuration tools. This would not be a trivial engineering effort, but it would certainly fit within the overall BrandZ model. 4.11. Impact on Zones Upgrade The zones test suite, which is run as a regular part of the PIT suite, will be extended to include testing of lx-branded zones. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/471. 1. Specification File: final.materials/design.pdf File: committment.materials/onepager File: committment.materials/what_works 2. 20 Questions File: final.materials/20_questions 3. Man Pages File: committment.materials/brand.dtd.1 File: committment.materials/brands.5 File: committment.materials/design.pdf File: committment.materials/lx.5 File: committment.materials/zone_platform.dtd.1 File: committment.materials/zoneadm.1m File: committment.materials/zonecfg.1m File: committment.materials/zones.5 PSARC/2005/471 Copyright 2006 Sun Microsystems - 9 - 4. Contract between Solaris Core Technologies and Solaris Install File: contract-01 PSARC/2005/471 Copyright 2006 Sun Microsystems --Boundary_(ID_8TyhygJco7SYjt/EMbKZiA)--