From gjelinek@sac.sfbay.sun.com Wed Oct 22 12:16:57 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9MJGuve000231 for ; Wed, 22 Oct 2008 12:16:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9MJGlGJ002474; Thu, 23 Oct 2008 03:16:55 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K950090PMW4P200@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Oct 2008 12:16:52 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K950096PMVS5L00@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Oct 2008 12:16:40 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9MJGd6s032285; Wed, 22 Oct 2008 12:16:39 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9MJGcS5000226; Wed, 22 Oct 2008 12:16:38 -0700 (PDT) Received: (from gjelinek@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m9MJGcVq000222; Wed, 22 Oct 2008 12:16:38 -0700 (PDT) Date: Wed, 22 Oct 2008 12:16:38 -0700 (PDT) From: Gerald Jelinek Subject: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008] To: PSARC-ext@sun.com Cc: Jordan.Vaughan@sun.com, gerald.jelinek@sun.com Message-id: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 23700 I am sponsoring this fast-track for Jordan Vaughan. This seeks patch binding. Thanks, Jerry Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Configurable Hostids for Non-Global Zones 1.2. Name of Document Author/Supplier: Author: Jordan Vaughan 1.3 Date of This Document: 22 October, 2008 4. Technical Description PROBLEM: A machine's hostid is a number that is supposed to uniquely identify the machine. For the Solaris OS, hostids are 32-bit integers. Solaris 10, Solaris Nevada, and OpenSolaris currently store a single hostid in kernel memory as a decimal string named hw_serial. The hostid is shared among the global zone (GZ) and all non-global zones (NGZs) of the host machine. In other words, users that execute the hostid(1) command and processes that query the machine's hostid via sysinfo(2) from within an NGZ will receive the hostid of the host machine. There are two problems with the status quo: (1) Using zones to consolidate systems that have applications that rely on hostids to enforce licensing restrictions is problematic Any application that relies on hostids to enforce licensing restrictions cannot be run within zones when the hostids of the zones' host systems differ from that of the system for which the application was licensed. Customers can contact the application's licensors to relicense the application, but this is not always possible (e.g., the licensor no longer exists). Customers with such applications might be reluctant to use zones to consolidate systems because doing so would most likely incapacitate their applications. (2) If a zone that has licensed software that uses hostids to enforce licensing restrictions is migrated to another machine (e.g., via zone detach/attach), then if the new machine's hostid differs from that of the zone's originating machine, then the licensed software will be incapacitated. Several customers have requested that individual NGZs be allowed to emulate hostids to solve the above two problems (see [1] for a partial list of these customers). I propose to meet these customers' requests by adding a new zonecfg(1M) zone property, hostid, that users can set to makes NGZs emulate hostids. In other words, each NGZ could have its own hostid. Such an enhancement will resolve the above issues, provide a more complete virtualization solution to customers, and "ease adoption of the zones feature." [1] Hostid emulation is already implemented in Solaris 10 for Solaris 8 and Solaris 9 Containers. My solution will add hostid emulation to native- and sn1- branded zones in Solaris Nevada and provide a new framework for hostid emulation in Solaris 8 and Solaris 9 Containers in Solaris 10. The Solaris 8 and 9 brands will support both the already-existing "add attr hostid" interface and the new hostid property interface in zonecfg(1M). IMPORTED INTERFACES: GLOBAL VARIABLES: hw_serial Contract Private EXPORTED INTERFACES: FUNCTIONS: zone_get_hostid Consolidation Private Declared in usr/src/uts/common/sys/zone.h Defined in usr/src/uts/common/os/zone.c CONSTANTS: HW_INVALID_HOSTID Consolidation Private Defined in usr/src/uts/common/sys/systeminfo.h HW_HOSTID_LEN Consolidation Private Defined in usr/src/uts/common/sys/systeminfo.h ZONECFG(1M) ATTRIBUTES: hostid Committed TECHNICAL DESCRIPTION: There are currently at least two methods of emulating hostids within zones: (1) Run a destructive DTrace script that intercepts sysinfo(SI_HW_SERIAL) calls and returns a custom hostid for each zone. [1] [2] (2) Use LD_PRELOAD to intercept sysinfo(2) and return custom hostids. [1] It would be preferable to standardize zone hostid emulation and integrate it into kernel structures and already-existing zone tools (zonecfg(1M) and zoneadmd(1M)) so that customers would not have to rely on less efficient and more ad-hoc methods. My solution for NGZ hostid emulation is to add a 32-bit integral field to the zone structure zone_t that will contain the zone's hostid or HW_INVALID_HOSTID (-1) if the zone does not emulate a hostid. The GZ's hostid will be the host machine's hostid, which will be stored in hw_serial. NGZs will not emulate hostids by default. The new interface function zone_get_hostid() will have the following C prototype: uint32_t zone_get_hostid(zone_t *) zone_get_hostid() will return the hostid of the specified zone or the machine's hostid if the specified zone is NULL or if the zone does not emulate a hostid. If sysinfo(2) is used to query the machine's hostid, then sysinfo(2) will yield the caller's zone's hostid if the zone emulates a hostid. Otherwise, sysinfo(2) will yield the host machine's hostid. HW_HOSTID_LEN is the minimum string size needed to hold a hostid returned by sysinfo(2). Users will be able to configure a zone's hostid via the zonecfg(1M) tool. A zone's configured hostid will be stored in the zone's XML configuration file as the root property 'hostid'. zonecfg(1M) will only accept hexadecimal hostid strings of no more than eight digits. The hostid strings can be optionally prefixed with '0x' or '0X' and can contain uppercase or lowercase hexadecimal digits. Setting a zone's hostid to 0xFFFFFFFF, the value of HW_INVALID_HOSTID, results in an error. Changing a zone's hostid configuration with zonecfg(1M) will not update the hostid of a running instance of that zone. Users will not be able to modify the hostid of the GZ (i.e., the machine's hostid) with zonecfg(1M). A zone's zone_hostid field is set by zoneadmd(1M) when the zone is readied. zoneadmd(1M) will examine the hostid property stored in the configuration file of a zone that is transitioning to the ready state and fail to ready the zone if the hostid is invalid. (Validity is established according to the criteria set forth in the previous paragraph.) Thus readying, booting, or rebooting a zone with an invalid hostid in its configuration file will fail. Both native- and sn1-branded zones will be capable of emulating hostids. However, lx-branded zones will forbid hostid emulation because supported Linux distributions (e.g., CentOS) retrieve hostids from /etc/hostid rather than kernel memory (as in Solaris OS). Zone administrators desiring to change an lx-branded zone's hostid can modify the zone's /etc/hostid file. Solaris 10 users will be able to configure a Solaris 8 or 9 container's hostid through the already-existing "add attr hostid" interface and new hostid property interface in zonecfg(1M). RELATED BUGIDS: 6580939 RFE: provide unique hostid for each non-global zone 4160584 Support use of something other than hostid to lock software to 4762207 Fix the hostid generation in x86 RELATED ARC CASES: PSARC/2007/078: Hostid for x86 systems PSARC/2005/471: BrandZ: Support for non-native zones PSARC/2002/174: Virtualization and Namespace Isolation in Solaris REFERENCE DOCUMENTS: [1] 6580939 RFE: provide unique hostid for each non-global zone (http://monaco.sfbay.sun.com/detail.jsf?cr=6580939) [2] Ramblings from Richard's Ranch: spoofing hostids (http://blogs.sun.com/relling/entry/spoofing_hostids) PSARC/2007/078: Hostid for x86 systems (http://sac.sfbay/PSARC/2007/078/mail) Frank Hofmann's Weblog: The dark side of the source - hostids (http://blogs.sun.com/ambiguous/entry/introducing_myself) MODIFIED MAN PAGES: System Administration Commands sysdef(1M) NAME sysdef - output system definition SYNOPSIS /usr/sbin/sysdef [-i] [-n namelist] /usr/sbin/sysdef [-h] [-d] [-i] [-D] DESCRIPTION The sysdef utility outputs the current system definition in tabular form. It lists all hardware devices, as well as pseudo devices, system devices, loadable modules, and the values of selected kernel tunable parameters. It generates the output by analyzing the named bootable operating system file (namelist) and extracting the confi- guration information from it. The default system namelist is /dev/kmem. OPTIONS -i Prints the configuration information from /dev/kmem. This is the default and only needs to be specified if the configuration informa- tion from both /dev/kmem and the system file specified with the "-n namelist" option is needed. -nnamelist Specifies a namelist other than the default (/dev/kmem). The namelist specified must be a valid bootable operating system. -h Prints the identifier of the current host in --> hexadecimal. If sysdef -h is executed within --> a non-global zone and the zone emulates a host --> identifier, then the zone's host identifier is --> printed. This numeric value is not guaranteed to be unique. -d The output includes the configuration of sys- tem peripherals formatted as a device tree. [...] ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu | |_____________________________|_____________________________| SEE ALSO --> hostid(1), zones(5), prtconf(1M), nlist(3ELF), attributes(5) SunOS 5.11 Last change: 1 Jun 2007 3 User Commands hostid(1) NAME hostid - print the numeric identifier of the current host SYNOPSIS /usr/bin/hostid DESCRIPTION The hostid command prints the identifier of the current host --> in hexadecimal. If it is executed within a non-global zone --> that emulates a host identifier, then the emulated host --> identifier is printed. This numeric value is likely to differ when hostid is run on a different machine. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE ATTRIBUTE VALUE | | Availability SUNWcsu | |___________________________________________________________| SEE ALSO --> sysinfo(2), gethostid(3C), zones(5), attributes(5) SunOS 5.11 Last change: 14 Sep 1992 1 Standard C Library Functions gethostid(3C) NAME gethostid - get an identifier for the current host SYNOPSIS #include long gethostid(void); DESCRIPTION The gethostid() function returns the 32-bit identifier for the current host. If the hardware capability exists, this identifier is taken from platform-dependent stable storage; otherwise it is a randomly generated number. It is not guaranteed to be unique. --> --> If the calling thread's process is executing within a non- --> global zone that emulates a host identifier, then the --> zone's emulated 32-bit host identifier is returned. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Standard | |_____________________________|_____________________________| | MT-Level | MT-Safe | |_____________________________|_____________________________| SEE ALSO --> hostid(1), sysinfo(2), zones(5), attributes(5), standards(5) SunOS 5.11 Last change: 21 May 2007 1 System Calls sysinfo(2) NAME sysinfo - get and set system information strings SYNOPSIS #include int sysinfo(int command, char *buf, long count); DESCRIPTION The sysinfo() function copies information relating to the operating system on which the process is executing into the buffer pointed to by buf. It can also set certain informa- tion where appropriate commands are available. The count parameter indicates the size of the buffer. The POSIX P1003.1 interface (see standards(5)) sysconf(3C) provides a similar class of configuration information, but returns an integer rather than a string. The values for command are as follows: SI_SYSNAME Copy into the array pointed to by buf the string that would be returned by uname(2) in the sysnamefield. This is the name of the implementation of the operating sys- tem, for example, SunOS or UTS. [...] SI_HW_PROVIDER Copies the name of the hardware manufacturer into the array pointed to by buf. SI_HW_SERIAL Copy into the array pointed to by buf a string which is the ASCII representation of the hardware-specific serial number of the physical machine on which the function is executed. This might be implemented in Read-Only Memory, using software constants set when building the operating system, or by other means, and might contain non-numeric --> characters. If the function is executed within a non- --> global zone that emulates a host identifier, then the --> ASCII representation of the zone's host identifier is --> copied into the array pointed to by buf. It is anticipated that manufacturers will not issue the same "serial number" to more than one physical machine. The pair of strings returned by SI_HW_PROVIDER and SI_HW_SERIAL is not guaranteed to be unique across all vendor's SVR4 implementations and could change over the lifetime of a given system. SI_SRPC_DOMAIN Copies the Secure Remote Procedure Call domain name into the array pointed to by buf. [...] A good estimation for count is 257, which is likely to cover all strings returned by this interface in typical installa- tions. SEE ALSO boot(1M), dhcpagent(1M), getisax(2), uname(2), gethostid(3C), gethostname(3C), sysconf(3C), isalist(5), --> zones(5), privileges(5), standards(5) SunOS 5.11 Last change: 15 Apr 2008 5 Standards, Environments, and Macros zones(5) NAME zones - Solaris application containers DESCRIPTION The zones facility in Solaris provides an isolated environ- ment for running applications. Processes running in a zone are prevented from monitoring or interfering with other activity in the system. Access to other processes, network interfaces, file systems, devices, and inter-process commun- ication facilities are restricted to prevent interaction between processes in different zones. [...] Networking A zone has its own port number space for TCP, UDP, and SCTP applications and typically one or more separate IP addresses (but some configurations of Trusted Extensions share IP address(es) between zones). For the IP layer (IP routing, ARP, IPsec, IP Filter, and so on) a zone can either share the configuration and state with the global zone (a shared-IP zone), or have its distinct IP layer configuration and state (an exclusive-IP zone). If a zone is to be connected to the same datalink, that is, be on the same IP subnet or subnets as the global zone, then it is appropriate for the zone to use the shared IP instance. If a zone needs to be isolated at the IP layer on the net- work, for instance being connected to different VLANs or different LANs than the global zone and other non-global zones, then for isolation reasons the zone should have its exclusive IP. A shared-IP zone is prevented from doing certain things towards the network (such as changing its IP address or sending spoofed IP or Ethernet packets), but an exclusive-IP zone has more or less the same capabilities towards the net- work as a separate host that is connected to the same net- work interface. In particular, the superuser in such a zone can change its IP address and spoof ARP packets. The shared-IP zones are assigned one or more network inter- face names and IP addresses in zonecfg(1M). The network interface name(s) must also be configured in the global zone. The exclusive-IP zones are assigned one or more network interface names in zonecfg(1M). The network interface names must be exclusively assigned to that zone, that is, it (or they) can not be assigned to some other running zone, nor can they be used by the global zone. SunOS 5.11 Last change: 23 Jan 2007 4 Standards, Environments, and Macros zones(5) The full IP-level functionality in the form of DHCP client, IPsec and IP Filter, is available in exclusive-IP zones and not in shared-IP zones. --> ->Host Identifiers --> A zone is capable of emulating a 32-bit host identifier, --> which can be configured via zonecfg(1M), for the purpose --> of system consolidation. If a zone emulates a host --> identifier, then commands such as hostid(1) and sysdef(1M) --> as well as C interfaces such as sysinfo(2) and gethostid(3C) --> that are executed within the context of the zone will --> display or return the zone's emulated host identifier rather --> than the host machine's identifier. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu | |_____________________________|_____________________________| SEE ALSO zlogin(1), zonename(1), in.rlogind(1M), sshd(1M), zoneadm(1M), zonecfg(1M), getzoneid(3C), kill(2), priocntl(2), ucred_get(3C), proc(4), attributes(5), brands(5), privileges(5), crgetzoneid(9F) SunOS 5.11 Last change: 23 Jan 2007 5 System Administration Commands zonecfg(1M) NAME zonecfg - set up zone configuration SYNOPSIS zonecfg -z zonename zonecfg -z zonename subcommand zonecfg -z zonename -f command_file zonecfg help DESCRIPTION The zonecfg utility creates and modifies the configuration of a zone. Zone configuration consists of a number of resources and properties. [...] Properties Each resource type has one or more properties. There are also some global properties, that is, properties of the con- figuration as a whole, rather than of some particular resource. The following properties are supported: (global) zonename (global) zonepath (global) autoboot (global) bootargs (global) pool (global) limitpriv (global) brand (global) cpu-shares --> (global) --> --> hostid SunOS 5.11 Last change: 2 Apr 2008 3 [...] The following table summarizes resources, property-names, and types: resource property-name type (global) zonename simple (global) zonepath simple (global) autoboot simple (global) bootargs simple (global) pool simple (global) limitpriv simple (global) brand simple (global) ip-type simple --> (global) hostid simple (global) cpu-shares simple (global) max-lwps simple (global) max-msg-ids simple (global) max-sem-ids simple (global) max-shm-ids simple (global) max-shm-memory simple (global) scheduling-class simple fs dir simple special simple raw simple type simple options list of simple inherit-pkg-dir dir simple net address simple physical simple device match simple rctl name simple value list of complex attr name simple type simple value simple dataset name simple dedicated-cpu ncpus simple or range importance simple SunOS 5.11 Last change: 2 Apr 2008 11 [...] global: brand The zone's brand type. A zone that is not assigned a brand is considered a "native" zone. global: ip-type A zone can either share the IP instance with the global zone, which is the default, or have its own exclusive instance of IP. This property takes the values shared and exclusive. --> --> --> global: hostid --> --> A zone can emulate a 32-bit host identifier to ease --> system consolidation. A zone's hostid property is empty --> by default, meaning that the zone does not emulate a --> host identifier. Zone host identifiers must be --> hexadecimal values between 0 and FFFFFFFE. A '0x' or --> '0X' prefix is optional. Both uppercase and lowercase --> hexadecimal digits are acceptable. fs: dir, special, raw, type, options Values needed to determine how, where, and so forth to mount file systems. See mount(1M), mount(2), fsck(1M), and vfstab(4). SunOS 5.11 Last change: 2 Apr 2008 7 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From ric.aleshire@sun.com Wed Oct 22 16:06:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9MN6fYC010727 for ; Wed, 22 Oct 2008 16:06:41 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9MN6Y3i001284; Thu, 23 Oct 2008 00:06:36 +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 <0K950070BXIZ7B00@brm-avmta-1.central.sun.com>; Wed, 22 Oct 2008 17:06:35 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K950047SXIYU410@brm-avmta-1.central.sun.com>; Wed, 22 Oct 2008 17:06:34 -0600 (MDT) Received: from [127.0.0.1] (vpn-129-150-18-116.SFBay.Sun.COM [129.150.18.116]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9MN6Xh9365716; Wed, 22 Oct 2008 16:06:33 -0700 (PDT) Date: Wed, 22 Oct 2008 16:06:32 -0700 From: Ric Aleshire Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack, timeout 10/30/2008] To: Jordan.Vaughan@sun.com, gerald.jelinek@sun.com Cc: PSARC-ext@sun.com Message-id: <48FFB1F8.5080102@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Antivirus: avast! (VPS 081022-1, 10/22/2008), Outbound message X-Antivirus-Status: Clean User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 818 > > Both native- and sn1-branded zones will be capable of emulating hostids. > However, lx-branded zones will forbid hostid emulation because supported > Linux distributions (e.g., CentOS) retrieve hostids from /etc/hostid rather > than kernel memory (as in Solaris OS). Zone administrators desiring to change > an lx-branded zone's hostid can modify the zone's /etc/hostid file. > > Solaris 10 users will be able to configure a Solaris 8 or 9 container's hostid > through the already-existing "add attr hostid" interface and new hostid property > interface in zonecfg(1M). > Can you clarify how this applies to other brands? It sounds like only lx is specifically prohibited from using these hostid interfaces. How about other brands, such as the cluster brand and possible future native-based brands? -Ric From Jordan.Vaughan@sun.com Wed Oct 22 16:45:44 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9MNjhhl011119 for ; Wed, 22 Oct 2008 16:45:43 -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 m9MNjc6Q029836; Thu, 23 Oct 2008 07:45:38 +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 <0K9500A01ZC1AE00@brm-avmta-1.central.sun.com>; Wed, 22 Oct 2008 17:45:37 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K950045UZC1TT30@brm-avmta-1.central.sun.com>; Wed, 22 Oct 2008 17:45:37 -0600 (MDT) Received: from [129.146.228.104] (quidestveritas.SFBay.Sun.COM [129.146.228.104]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9MNjbZD406683; Wed, 22 Oct 2008 16:45:37 -0700 (PDT) Date: Wed, 22 Oct 2008 16:43:34 -0700 From: Jordan Vaughan Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack, timeout 10/30/2008] In-reply-to: <48FFB1F8.5080102@sun.com> To: Ric Aleshire Cc: gerald.jelinek@sun.com, PSARC-ext@sun.com Message-id: <48FFBAA6.4020302@Sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48FFB1F8.5080102@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 2017 Ric Aleshire wrote: >> >> Both native- and sn1-branded zones will be capable of emulating hostids. >> However, lx-branded zones will forbid hostid emulation because supported >> Linux distributions (e.g., CentOS) retrieve hostids from /etc/hostid >> rather >> than kernel memory (as in Solaris OS). Zone administrators desiring >> to change >> an lx-branded zone's hostid can modify the zone's /etc/hostid file. >> >> Solaris 10 users will be able to configure a Solaris 8 or 9 >> container's hostid >> through the already-existing "add attr hostid" interface and new >> hostid property >> interface in zonecfg(1M). >> > > Can you clarify how this applies to other brands? It sounds like only > lx is specifically prohibited from using these > hostid interfaces. How about other brands, such as the cluster brand > and possible future native-based brands? > > -Ric Ric, As long as sysinfo(SI_HW_SERIAL) system calls originating from within a branded zone are handled by the native Solaris kernel, the zone will be capable of emulating a hostid. All native-based brands will drop into the native kernel when sysinfo(SI_HW_SERIAL) system calls are made, so all native-based brands will be capable of emulating hostids. From what I have heard, cluster-branded zones are essentially native-branded zones with special callbacks, so cluster-branded zones will be capable of emulating hostids. Cluster-branded zones serve as an excellent example of the usefulness of non-global zone hostid emulation. Each cluster-branded zone could emulate a hostid. If clustering software migrates a cluster-branded zone between physical cluster nodes, then if the zone's configuration is preserved during the migration, then the zone's emulated hostid will be the same no matter which physical node hosts it. Without non-global zone hostid emulation, a cluster-branded zone's hostid can change when the zone migrates, potentially impacting how software within the zone will function. Regards, Jordan From Darren.Moffat@Sun.COM Thu Oct 23 01:41:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9N8fFNp024548 for ; Thu, 23 Oct 2008 01:41:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9N8f51d011751 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 23 Oct 2008 16:41:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9600107O4PCK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 23 Oct 2008 01:41:13 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9600LICO4OK330@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 23 Oct 2008 01:41:13 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9N8fBhm002479 for ; Thu, 23 Oct 2008 08:41:12 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9600101O1CZD00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 23 Oct 2008 09:41:11 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9600LRMO3NDND0@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 23 Oct 2008 09:40:36 +0100 (BST) Date: Thu, 23 Oct 2008 09:40:35 +0100 From: Darren J Moffat Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008] In-reply-to: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: Gerald.Jelinek@Sun.COM Cc: PSARC-ext@Sun.COM, Jordan.Vaughan@Sun.COM Message-id: <49003883.5080408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1346 First let me say I fully support what this case is providing and the way it is providing it. Particularly the fact that the hostid is "in the clear"! However this directly conflicts with PSARC/2007/078, in particular the long discussion that was had in that case the resulted in the (in my opinion) total pointless obfuscation of the hostid in the /etc/hostid file, after all one just needs to run "hostid" to see what it is, and the "obfuscation" code is open source. I'm actually glad that this case doesn't attempt to do any pointless obfuscation of the hostid. However it makes this case inconsistent with 2007/078. Given that 2007/078 stores the hostid in /etc/hostid (for x86 only) was any consideration given to just using the same mechanism for zones rather than having a different one ? I don't actually feel that strongly one way or the other (/etc/hostid or zonecfg file), and if anything and leaning slightly towards what the case proposes. I'm also leaning slightly towards having this case, if approved as specified, revoke the approval of 2007/078 and requiring it put the hostid in the clear in /etc/hostid. Though we don't quite have ARC words for that, so I guess it would really be that this case updates 2007/078 and this cases' spec is extended. The consistency is important. -- Darren J Moffat From Brian.Ruthven@sun.com Thu Oct 23 03:00:44 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NA0hOQ026034 for ; Thu, 23 Oct 2008 03:00:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9NA0ft6024646 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 23 Oct 2008 04:00:43 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9600F0DRT7MA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 23 Oct 2008 03:00:43 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9600FBLRT54B00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 23 Oct 2008 03:00:42 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9NA0fx3013597 for ; Thu, 23 Oct 2008 10:00:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9600I01QZCI400@fe-emea-10.sun.com> (original mail from Brian.Ruthven@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 23 Oct 2008 11:00:41 +0100 (BST) Received: from [129.156.173.239] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K960061WRSQF870@fe-emea-10.sun.com>; Thu, 23 Oct 2008 11:00:27 +0100 (BST) Date: Thu, 23 Oct 2008 11:00:26 +0100 From: Brian Ruthven - Sun UK Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008] In-reply-to: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> Sender: Brian.Ruthven@sun.com To: Gerald Jelinek Cc: PSARC-ext@sun.com, Jordan.Vaughan@sun.com, Gerald.Jelinek@sun.com Message-id: <49004B3A.7010700@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071119) Status: RO Content-Length: 25314 Just to make sure this has been covered: PSARC/2007/078 (hostids for x86) mentions the legal implications of software licensing against hostids. This case proposes that the hostids are user-supplied, thus may need a Sun Legal check too. Brian Gerald Jelinek wrote: > I am sponsoring this fast-track for Jordan Vaughan. This seeks > patch binding. > > Thanks, > Jerry > > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Configurable Hostids for Non-Global Zones > 1.2. Name of Document Author/Supplier: > Author: Jordan Vaughan > 1.3 Date of This Document: > 22 October, 2008 > > 4. Technical Description > PROBLEM: > > A machine's hostid is a number that is supposed to uniquely identify the > machine. For the Solaris OS, hostids are 32-bit integers. Solaris 10, Solaris > Nevada, and OpenSolaris currently store a single hostid in kernel memory as a > decimal string named hw_serial. The hostid is shared among the global zone (GZ) > and all non-global zones (NGZs) of the host machine. In other words, users that > execute the hostid(1) command and processes that query the machine's hostid via > sysinfo(2) from within an NGZ will receive the hostid of the host machine. > > There are two problems with the status quo: > > (1) Using zones to consolidate systems that have applications that rely on > hostids to enforce licensing restrictions is problematic Any > application that relies on hostids to enforce licensing restrictions > cannot be run within zones when the hostids of the zones' host systems > differ from that of the system for which the application was licensed. > Customers can contact the application's licensors to relicense the > application, but this is not always possible (e.g., the licensor no > longer exists). Customers with such applications might be reluctant to > use zones to consolidate systems because doing so would most likely > incapacitate their applications. > (2) If a zone that has licensed software that uses hostids to enforce > licensing restrictions is migrated to another machine (e.g., via zone > detach/attach), then if the new machine's hostid differs from that of > the zone's originating machine, then the licensed software will be > incapacitated. > > Several customers have requested that individual NGZs be allowed to emulate > hostids to solve the above two problems (see [1] for a partial list of these > customers). I propose to meet these customers' requests by adding a new > zonecfg(1M) zone property, hostid, that users can set to makes NGZs emulate > hostids. In other words, each NGZ could have its own hostid. Such an > enhancement will resolve the above issues, provide a more complete > virtualization solution to customers, and "ease adoption of the zones feature." > [1] > > Hostid emulation is already implemented in Solaris 10 for Solaris 8 and > Solaris 9 Containers. My solution will add hostid emulation to native- and sn1- > branded zones in Solaris Nevada and provide a new framework for hostid emulation > in Solaris 8 and Solaris 9 Containers in Solaris 10. The Solaris 8 and 9 > brands will support both the already-existing "add attr hostid" interface and > the new hostid property interface in zonecfg(1M). > > > IMPORTED INTERFACES: > > GLOBAL VARIABLES: > hw_serial Contract Private > > > EXPORTED INTERFACES: > > FUNCTIONS: > zone_get_hostid Consolidation Private > Declared in usr/src/uts/common/sys/zone.h > Defined in usr/src/uts/common/os/zone.c > > CONSTANTS: > HW_INVALID_HOSTID Consolidation Private > Defined in > usr/src/uts/common/sys/systeminfo.h > HW_HOSTID_LEN Consolidation Private > Defined in > usr/src/uts/common/sys/systeminfo.h > > ZONECFG(1M) ATTRIBUTES: > hostid Committed > > > TECHNICAL DESCRIPTION: > > There are currently at least two methods of emulating hostids within zones: > > (1) Run a destructive DTrace script that intercepts sysinfo(SI_HW_SERIAL) > calls and returns a custom hostid for each zone. [1] [2] > (2) Use LD_PRELOAD to intercept sysinfo(2) and return custom hostids. [1] > > It would be preferable to standardize zone hostid emulation and integrate it > into kernel structures and already-existing zone tools (zonecfg(1M) and > zoneadmd(1M)) so that customers would not have to rely on less efficient and > more ad-hoc methods. > > My solution for NGZ hostid emulation is to add a 32-bit integral field to the > zone structure zone_t that will contain the zone's hostid or HW_INVALID_HOSTID > (-1) if the zone does not emulate a hostid. The GZ's hostid will be the host > machine's hostid, which will be stored in hw_serial. NGZs will not emulate > hostids by default. > > The new interface function zone_get_hostid() will have the following C > prototype: > > uint32_t zone_get_hostid(zone_t *) > > zone_get_hostid() will return the hostid of the specified zone or the machine's > hostid if the specified zone is NULL or if the zone does not emulate a hostid. > > If sysinfo(2) is used to query the machine's hostid, then sysinfo(2) will yield > the caller's zone's hostid if the zone emulates a hostid. Otherwise, sysinfo(2) > will yield the host machine's hostid. HW_HOSTID_LEN is the minimum string size > needed to hold a hostid returned by sysinfo(2). > > Users will be able to configure a zone's hostid via the zonecfg(1M) tool. A > zone's configured hostid will be stored in the zone's XML configuration file > as the root property 'hostid'. zonecfg(1M) will only accept hexadecimal hostid > strings of no more than eight digits. The hostid strings can be optionally > prefixed with '0x' or '0X' and can contain uppercase or lowercase hexadecimal > digits. Setting a zone's hostid to 0xFFFFFFFF, the value of HW_INVALID_HOSTID, > results in an error. Changing a zone's hostid configuration with zonecfg(1M) > will not update the hostid of a running instance of that zone. Users will not > be able to modify the hostid of the GZ (i.e., the machine's hostid) with > zonecfg(1M). > > A zone's zone_hostid field is set by zoneadmd(1M) when the zone is readied. > zoneadmd(1M) will examine the hostid property stored in the configuration file > of a zone that is transitioning to the ready state and fail to ready the zone > if the hostid is invalid. (Validity is established according to the criteria > set forth in the previous paragraph.) Thus readying, booting, or rebooting a > zone with an invalid hostid in its configuration file will fail. > > Both native- and sn1-branded zones will be capable of emulating hostids. > However, lx-branded zones will forbid hostid emulation because supported > Linux distributions (e.g., CentOS) retrieve hostids from /etc/hostid rather > than kernel memory (as in Solaris OS). Zone administrators desiring to change > an lx-branded zone's hostid can modify the zone's /etc/hostid file. > > Solaris 10 users will be able to configure a Solaris 8 or 9 container's hostid > through the already-existing "add attr hostid" interface and new hostid property > interface in zonecfg(1M). > > > RELATED BUGIDS: > > 6580939 RFE: provide unique hostid for each non-global zone > 4160584 Support use of something other than hostid to lock software to > 4762207 Fix the hostid generation in x86 > > > RELATED ARC CASES: > > PSARC/2007/078: Hostid for x86 systems > PSARC/2005/471: BrandZ: Support for non-native zones > PSARC/2002/174: Virtualization and Namespace Isolation in Solaris > > > REFERENCE DOCUMENTS: > > [1] 6580939 RFE: provide unique hostid for each non-global zone > (http://monaco.sfbay.sun.com/detail.jsf?cr=6580939) > [2] Ramblings from Richard's Ranch: spoofing hostids > (http://blogs.sun.com/relling/entry/spoofing_hostids) > > PSARC/2007/078: Hostid for x86 systems > (http://sac.sfbay/PSARC/2007/078/mail) > Frank Hofmann's Weblog: The dark side of the source - hostids > (http://blogs.sun.com/ambiguous/entry/introducing_myself) > > > MODIFIED MAN PAGES: > > System Administration Commands sysdef(1M) > > NAME > sysdef - output system definition > > SYNOPSIS > /usr/sbin/sysdef [-i] [-n namelist] > > > /usr/sbin/sysdef [-h] [-d] [-i] [-D] > > > DESCRIPTION > The sysdef utility outputs the current system definition in > tabular form. It lists all hardware devices, as well as > pseudo devices, system devices, loadable modules, and the > values of selected kernel tunable parameters. > > > It generates the output by analyzing the named bootable > operating system file (namelist) and extracting the confi- > guration information from it. > > > The default system namelist is /dev/kmem. > > OPTIONS > -i Prints the configuration information from > /dev/kmem. This is the default and only needs > to be specified if the configuration informa- > tion from both /dev/kmem and the system file > specified with the "-n namelist" option is > needed. > > > -nnamelist Specifies a namelist other than the default > (/dev/kmem). The namelist specified must be a > valid bootable operating system. > > > -h Prints the identifier of the current host in > --> hexadecimal. If sysdef -h is executed within > --> a non-global zone and the zone emulates a host > --> identifier, then the zone's host identifier is > --> printed. This numeric value is not guaranteed > to be unique. > > > -d The output includes the configuration of sys- > tem peripherals formatted as a device tree. > > [...] > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |_____________________________|_____________________________| > | Availability | SUNWcsu | > |_____________________________|_____________________________| > > > SEE ALSO > --> hostid(1), zones(5), prtconf(1M), nlist(3ELF), attributes(5) > > SunOS 5.11 Last change: 1 Jun 2007 3 > > > > User Commands hostid(1) > > NAME > hostid - print the numeric identifier of the current host > > SYNOPSIS > /usr/bin/hostid > > > DESCRIPTION > The hostid command prints the identifier of the current host > --> in hexadecimal. If it is executed within a non-global zone > --> that emulates a host identifier, then the emulated host > --> identifier is printed. This numeric value is likely > to differ when hostid is run on a different machine. > > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > ____________________________________________________________ > | ATTRIBUTE TYPE ATTRIBUTE VALUE | > | Availability SUNWcsu | > |___________________________________________________________| > > > SEE ALSO > --> sysinfo(2), gethostid(3C), zones(5), attributes(5) > > > SunOS 5.11 Last change: 14 Sep 1992 1 > > > > Standard C Library Functions gethostid(3C) > > NAME > gethostid - get an identifier for the current host > > SYNOPSIS > #include > > long gethostid(void); > > > DESCRIPTION > The gethostid() function returns the 32-bit identifier for > the current host. If the hardware capability exists, this > identifier is taken from platform-dependent stable storage; > otherwise it is a randomly generated number. It is not > guaranteed to be unique. > --> > --> If the calling thread's process is executing within a non- > --> global zone that emulates a host identifier, then the > --> zone's emulated 32-bit host identifier is returned. > > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > > > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |_____________________________|_____________________________| > | Interface Stability | Standard | > |_____________________________|_____________________________| > | MT-Level | MT-Safe | > |_____________________________|_____________________________| > > > SEE ALSO > --> hostid(1), sysinfo(2), zones(5), attributes(5), standards(5) > > > SunOS 5.11 Last change: 21 May 2007 1 > > > > System Calls sysinfo(2) > > NAME > sysinfo - get and set system information strings > > SYNOPSIS > #include > > int sysinfo(int command, char *buf, long count); > > > DESCRIPTION > The sysinfo() function copies information relating to the > operating system on which the process is executing into the > buffer pointed to by buf. It can also set certain informa- > tion where appropriate commands are available. The count > parameter indicates the size of the buffer. > > > The POSIX P1003.1 interface (see standards(5)) sysconf(3C) > provides a similar class of configuration information, but > returns an integer rather than a string. > > > The values for command are as follows: > > SI_SYSNAME > > Copy into the array pointed to by buf the string that > would be returned by uname(2) in the sysnamefield. This > is the name of the implementation of the operating sys- > tem, for example, SunOS or UTS. > > [...] > > SI_HW_PROVIDER > > Copies the name of the hardware manufacturer into the > array pointed to by buf. > > > SI_HW_SERIAL > > Copy into the array pointed to by buf a string which is > the ASCII representation of the hardware-specific serial > number of the physical machine on which the function is > executed. This might be implemented in Read-Only Memory, > using software constants set when building the operating > system, or by other means, and might contain non-numeric > --> characters. If the function is executed within a non- > --> global zone that emulates a host identifier, then the > --> ASCII representation of the zone's host identifier is > --> copied into the array pointed to by buf. It is > anticipated that manufacturers will not issue the same > "serial number" to more than one physical machine. The > pair of strings returned by SI_HW_PROVIDER and > SI_HW_SERIAL is not guaranteed to be unique across all > vendor's SVR4 implementations and could change over the > lifetime of a given system. > > > SI_SRPC_DOMAIN > > Copies the Secure Remote Procedure Call domain name into > the array pointed to by buf. > > [...] > > A good estimation for count is 257, which is likely to cover > all strings returned by this interface in typical installa- > tions. > > SEE ALSO > boot(1M), dhcpagent(1M), getisax(2), uname(2), > gethostid(3C), gethostname(3C), sysconf(3C), isalist(5), > --> zones(5), privileges(5), standards(5) > > > SunOS 5.11 Last change: 15 Apr 2008 5 > > > > Standards, Environments, and Macros zones(5) > > NAME > zones - Solaris application containers > > DESCRIPTION > The zones facility in Solaris provides an isolated environ- > ment for running applications. Processes running in a zone > are prevented from monitoring or interfering with other > activity in the system. Access to other processes, network > interfaces, file systems, devices, and inter-process commun- > ication facilities are restricted to prevent interaction > between processes in different zones. > > [...] > > Networking > A zone has its own port number space for TCP, UDP, and SCTP > applications and typically one or more separate IP addresses > (but some configurations of Trusted Extensions share IP > address(es) between zones). > > > For the IP layer (IP routing, ARP, IPsec, IP Filter, and so > on) a zone can either share the configuration and state with > the global zone (a shared-IP zone), or have its distinct IP > layer configuration and state (an exclusive-IP zone). > > > If a zone is to be connected to the same datalink, that is, > be on the same IP subnet or subnets as the global zone, then > it is appropriate for the zone to use the shared IP > instance. > > > If a zone needs to be isolated at the IP layer on the net- > work, for instance being connected to different VLANs or > different LANs than the global zone and other non-global > zones, then for isolation reasons the zone should have its > exclusive IP. > > > A shared-IP zone is prevented from doing certain things > towards the network (such as changing its IP address or > sending spoofed IP or Ethernet packets), but an exclusive-IP > zone has more or less the same capabilities towards the net- > work as a separate host that is connected to the same net- > work interface. In particular, the superuser in such a zone > can change its IP address and spoof ARP packets. > > > The shared-IP zones are assigned one or more network inter- > face names and IP addresses in zonecfg(1M). The network > interface name(s) must also be configured in the global > zone. > > > The exclusive-IP zones are assigned one or more network > interface names in zonecfg(1M). The network interface names > must be exclusively assigned to that zone, that is, it (or > they) can not be assigned to some other running zone, nor > can they be used by the global zone. > > SunOS 5.11 Last change: 23 Jan 2007 4 > > Standards, Environments, and Macros zones(5) > > The full IP-level functionality in the form of DHCP client, > IPsec and IP Filter, is available in exclusive-IP zones and > not in shared-IP zones. > --> > ->Host Identifiers > --> A zone is capable of emulating a 32-bit host identifier, > --> which can be configured via zonecfg(1M), for the purpose > --> of system consolidation. If a zone emulates a host > --> identifier, then commands such as hostid(1) and sysdef(1M) > --> as well as C interfaces such as sysinfo(2) and gethostid(3C) > --> that are executed within the context of the zone will > --> display or return the zone's emulated host identifier rather > --> than the host machine's identifier. > > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |_____________________________|_____________________________| > | Availability | SUNWcsu | > |_____________________________|_____________________________| > > SEE ALSO > zlogin(1), zonename(1), in.rlogind(1M), sshd(1M), > zoneadm(1M), zonecfg(1M), getzoneid(3C), kill(2), > priocntl(2), ucred_get(3C), proc(4), attributes(5), > brands(5), privileges(5), crgetzoneid(9F) > > SunOS 5.11 Last change: 23 Jan 2007 5 > > > > System Administration Commands zonecfg(1M) > > NAME > zonecfg - set up zone configuration > > SYNOPSIS > zonecfg -z zonename > > > zonecfg -z zonename subcommand > > > zonecfg -z zonename -f command_file > > > zonecfg help > > > DESCRIPTION > The zonecfg utility creates and modifies the configuration > of a zone. Zone configuration consists of a number of > resources and properties. > > [...] > > Properties > Each resource type has one or more properties. There are > also some global properties, that is, properties of the con- > figuration as a whole, rather than of some particular > resource. > > > The following properties are supported: > > (global) > > zonename > > > (global) > > zonepath > > > (global) > > autoboot > > > (global) > > bootargs > > > (global) > > pool > > > (global) > > limitpriv > > > (global) > > brand > > > (global) > > cpu-shares > > --> (global) > --> > --> hostid > > > SunOS 5.11 Last change: 2 Apr 2008 3 > > [...] > > The following table summarizes resources, property-names, > and types: > > resource property-name type > (global) zonename simple > (global) zonepath simple > (global) autoboot simple > (global) bootargs simple > (global) pool simple > (global) limitpriv simple > (global) brand simple > (global) ip-type simple > --> (global) hostid simple > (global) cpu-shares simple > (global) max-lwps simple > (global) max-msg-ids simple > (global) max-sem-ids simple > (global) max-shm-ids simple > (global) max-shm-memory simple > (global) scheduling-class simple > fs dir simple > special simple > raw simple > type simple > options list of simple > inherit-pkg-dir dir simple > net address simple > physical simple > device match simple > rctl name simple > value list of complex > attr name simple > type simple > value simple > dataset name simple > dedicated-cpu ncpus simple or range > importance simple > > > SunOS 5.11 Last change: 2 Apr 2008 11 > > [...] > > > global: brand > > The zone's brand type. A zone that is not assigned a > brand is considered a "native" zone. > > > global: ip-type > > A zone can either share the IP instance with the global > zone, which is the default, or have its own exclusive > instance of IP. > > This property takes the values shared and exclusive. > --> > --> > --> global: hostid > --> > --> A zone can emulate a 32-bit host identifier to ease > --> system consolidation. A zone's hostid property is empty > --> by default, meaning that the zone does not emulate a > --> host identifier. Zone host identifiers must be > --> hexadecimal values between 0 and FFFFFFFE. A '0x' or > --> '0X' prefix is optional. Both uppercase and lowercase > --> hexadecimal digits are acceptable. > > > fs: dir, special, raw, type, options > > Values needed to determine how, where, and so forth to > mount file systems. See mount(1M), mount(2), fsck(1M), > and vfstab(4). > > SunOS 5.11 Last change: 2 Apr 2008 7 > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > -- Brian Ruthven Sun Microsystems UK Solaris Revenue Product Engineering Tel: +44 (0)1252 422 312 Sparc House, Guillemont Park, Camberley, GU17 9QG From margot.miller@sun.com Thu Oct 23 07:48:50 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NEmnv3001983 for ; Thu, 23 Oct 2008 07:48:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9NEmi84005947; Thu, 23 Oct 2008 15:48:45 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9700M15558OR00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 23 Oct 2008 07:48:44 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9700GIA5577T80@nwk-avmta-1.sfbay.Sun.COM>; Thu, 23 Oct 2008 07:48:43 -0700 (PDT) Received: from [10.7.250.155] (punchin-client-10-7-250-155.SFBay.Sun.COM [10.7.250.155]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9NEllI0513959; Thu, 23 Oct 2008 07:47:53 -0700 (PDT) Date: Thu, 23 Oct 2008 07:46:39 -0700 From: Margot Miller Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008] In-reply-to: <49004B3A.7010700@sun.com> To: Brian Ruthven - Sun UK Cc: Gerald Jelinek , PSARC-ext@sun.com, Jordan.Vaughan@sun.com, Gerald.Jelinek@sun.com, Ken Erickson Message-id: <49008E4F.60703@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> <49004B3A.7010700@sun.com> User-Agent: Thunderbird 2.0b1 (X11/20070115) Status: RO Content-Length: 26342 We (PSARC/2007/078) have talked to this team about the hostid scheme and the angst it caused with those in MDE. My understanding is that this current team has talked to MDE to figure out the impact of this project on their ISV's. Margot Brian Ruthven - Sun UK wrote: > > Just to make sure this has been covered: > > PSARC/2007/078 (hostids for x86) mentions the legal implications of > software licensing against hostids. This case proposes that the > hostids are user-supplied, thus may need a Sun Legal check too. > > Brian > > Gerald Jelinek wrote: >> I am sponsoring this fast-track for Jordan Vaughan. This seeks >> patch binding. >> >> Thanks, >> Jerry >> >> Template Version: @(#)sac_nextcase %I% %G% SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Configurable Hostids for Non-Global Zones >> 1.2. Name of Document Author/Supplier: >> Author: Jordan Vaughan >> 1.3 Date of This Document: >> 22 October, 2008 >> >> 4. Technical Description >> PROBLEM: >> >> A machine's hostid is a number that is supposed to uniquely identify the >> machine. For the Solaris OS, hostids are 32-bit integers. Solaris >> 10, Solaris >> Nevada, and OpenSolaris currently store a single hostid in kernel >> memory as a >> decimal string named hw_serial. The hostid is shared among the >> global zone (GZ) >> and all non-global zones (NGZs) of the host machine. In other words, >> users that >> execute the hostid(1) command and processes that query the machine's >> hostid via >> sysinfo(2) from within an NGZ will receive the hostid of the host >> machine. >> >> There are two problems with the status quo: >> >> (1) Using zones to consolidate systems that have applications >> that rely on >> hostids to enforce licensing restrictions is problematic Any >> application that relies on hostids to enforce licensing >> restrictions >> cannot be run within zones when the hostids of the zones' >> host systems >> differ from that of the system for which the application was >> licensed. >> Customers can contact the application's licensors to >> relicense the >> application, but this is not always possible (e.g., the >> licensor no >> longer exists). Customers with such applications might be >> reluctant to >> use zones to consolidate systems because doing so would most >> likely >> incapacitate their applications. >> (2) If a zone that has licensed software that uses hostids to >> enforce >> licensing restrictions is migrated to another machine (e.g., >> via zone >> detach/attach), then if the new machine's hostid differs >> from that of >> the zone's originating machine, then the licensed software >> will be >> incapacitated. >> >> Several customers have requested that individual NGZs be allowed to >> emulate >> hostids to solve the above two problems (see [1] for a partial list >> of these >> customers). I propose to meet these customers' requests by adding a new >> zonecfg(1M) zone property, hostid, that users can set to makes NGZs >> emulate >> hostids. In other words, each NGZ could have its own hostid. Such an >> enhancement will resolve the above issues, provide a more complete >> virtualization solution to customers, and "ease adoption of the zones >> feature." >> [1] >> >> Hostid emulation is already implemented in Solaris 10 for Solaris 8 and >> Solaris 9 Containers. My solution will add hostid emulation to >> native- and sn1- >> branded zones in Solaris Nevada and provide a new framework for >> hostid emulation >> in Solaris 8 and Solaris 9 Containers in Solaris 10. The Solaris 8 >> and 9 >> brands will support both the already-existing "add attr hostid" >> interface and >> the new hostid property interface in zonecfg(1M). >> >> >> IMPORTED INTERFACES: >> >> GLOBAL VARIABLES: >> hw_serial Contract Private >> >> >> EXPORTED INTERFACES: >> >> FUNCTIONS: >> zone_get_hostid Consolidation Private >> Declared in >> usr/src/uts/common/sys/zone.h >> Defined in >> usr/src/uts/common/os/zone.c >> >> CONSTANTS: >> HW_INVALID_HOSTID Consolidation Private >> Defined in >> >> usr/src/uts/common/sys/systeminfo.h >> HW_HOSTID_LEN Consolidation Private >> Defined in >> >> usr/src/uts/common/sys/systeminfo.h >> >> ZONECFG(1M) ATTRIBUTES: >> hostid Committed >> >> >> TECHNICAL DESCRIPTION: >> >> There are currently at least two methods of emulating hostids within >> zones: >> >> (1) Run a destructive DTrace script that intercepts >> sysinfo(SI_HW_SERIAL) >> calls and returns a custom hostid for each zone. [1] [2] >> (2) Use LD_PRELOAD to intercept sysinfo(2) and return custom >> hostids. [1] >> >> It would be preferable to standardize zone hostid emulation and >> integrate it >> into kernel structures and already-existing zone tools (zonecfg(1M) and >> zoneadmd(1M)) so that customers would not have to rely on less >> efficient and >> more ad-hoc methods. >> >> My solution for NGZ hostid emulation is to add a 32-bit integral >> field to the >> zone structure zone_t that will contain the zone's hostid or >> HW_INVALID_HOSTID >> (-1) if the zone does not emulate a hostid. The GZ's hostid will be >> the host >> machine's hostid, which will be stored in hw_serial. NGZs will not >> emulate >> hostids by default. >> >> The new interface function zone_get_hostid() will have the following C >> prototype: >> >> uint32_t zone_get_hostid(zone_t *) >> >> zone_get_hostid() will return the hostid of the specified zone or the >> machine's >> hostid if the specified zone is NULL or if the zone does not emulate >> a hostid. >> >> If sysinfo(2) is used to query the machine's hostid, then sysinfo(2) >> will yield >> the caller's zone's hostid if the zone emulates a hostid. Otherwise, >> sysinfo(2) >> will yield the host machine's hostid. HW_HOSTID_LEN is the minimum >> string size >> needed to hold a hostid returned by sysinfo(2). >> >> Users will be able to configure a zone's hostid via the zonecfg(1M) >> tool. A >> zone's configured hostid will be stored in the zone's XML >> configuration file >> as the root property 'hostid'. zonecfg(1M) will only accept >> hexadecimal hostid >> strings of no more than eight digits. The hostid strings can be >> optionally >> prefixed with '0x' or '0X' and can contain uppercase or lowercase >> hexadecimal >> digits. Setting a zone's hostid to 0xFFFFFFFF, the value of >> HW_INVALID_HOSTID, >> results in an error. Changing a zone's hostid configuration with >> zonecfg(1M) >> will not update the hostid of a running instance of that zone. Users >> will not >> be able to modify the hostid of the GZ (i.e., the machine's hostid) with >> zonecfg(1M). >> >> A zone's zone_hostid field is set by zoneadmd(1M) when the zone is >> readied. >> zoneadmd(1M) will examine the hostid property stored in the >> configuration file >> of a zone that is transitioning to the ready state and fail to ready >> the zone >> if the hostid is invalid. (Validity is established according to the >> criteria >> set forth in the previous paragraph.) Thus readying, booting, or >> rebooting a >> zone with an invalid hostid in its configuration file will fail. >> >> Both native- and sn1-branded zones will be capable of emulating hostids. >> However, lx-branded zones will forbid hostid emulation because supported >> Linux distributions (e.g., CentOS) retrieve hostids from /etc/hostid >> rather >> than kernel memory (as in Solaris OS). Zone administrators desiring >> to change >> an lx-branded zone's hostid can modify the zone's /etc/hostid file. >> >> Solaris 10 users will be able to configure a Solaris 8 or 9 >> container's hostid >> through the already-existing "add attr hostid" interface and new >> hostid property >> interface in zonecfg(1M). >> >> >> RELATED BUGIDS: >> >> 6580939 RFE: provide unique hostid for each non-global zone >> 4160584 Support use of something other than hostid to lock >> software to >> 4762207 Fix the hostid generation in x86 >> >> >> RELATED ARC CASES: >> >> PSARC/2007/078: Hostid for x86 systems >> PSARC/2005/471: BrandZ: Support for non-native zones >> PSARC/2002/174: Virtualization and Namespace Isolation in Solaris >> >> >> REFERENCE DOCUMENTS: >> >> [1] 6580939 RFE: provide unique hostid for each non-global zone >> (http://monaco.sfbay.sun.com/detail.jsf?cr=6580939) >> [2] Ramblings from Richard's Ranch: spoofing hostids >> (http://blogs.sun.com/relling/entry/spoofing_hostids) >> >> PSARC/2007/078: Hostid for x86 systems >> (http://sac.sfbay/PSARC/2007/078/mail) >> Frank Hofmann's Weblog: The dark side of the source - hostids >> (http://blogs.sun.com/ambiguous/entry/introducing_myself) >> >> >> MODIFIED MAN PAGES: >> >> System Administration Commands sysdef(1M) >> >> NAME >> sysdef - output system definition >> >> SYNOPSIS >> /usr/sbin/sysdef [-i] [-n namelist] >> >> >> /usr/sbin/sysdef [-h] [-d] [-i] [-D] >> >> >> DESCRIPTION >> The sysdef utility outputs the current system definition in >> tabular form. It lists all hardware devices, as well as >> pseudo devices, system devices, loadable modules, and the >> values of selected kernel tunable parameters. >> >> >> It generates the output by analyzing the named bootable >> operating system file (namelist) and extracting the confi- >> guration information from it. >> >> >> The default system namelist is /dev/kmem. >> >> OPTIONS >> -i Prints the configuration information from >> /dev/kmem. This is the default and only needs >> to be specified if the configuration informa- >> tion from both /dev/kmem and the system file >> specified with the "-n namelist" option is >> needed. >> >> >> -nnamelist Specifies a namelist other than the default >> (/dev/kmem). The namelist specified must be a >> valid bootable operating system. >> >> >> -h Prints the identifier of the current host in >> --> hexadecimal. If sysdef -h is executed within >> --> a non-global zone and the zone emulates a host >> --> identifier, then the zone's host identifier is >> --> printed. This numeric value is not guaranteed >> to be unique. >> >> >> -d The output includes the configuration of sys- >> tem peripherals formatted as a device tree. >> >> [...] >> ____________________________________________________________ >> | ATTRIBUTE TYPE | ATTRIBUTE VALUE | >> |_____________________________|_____________________________| >> | Availability | SUNWcsu | >> |_____________________________|_____________________________| >> >> >> SEE ALSO >> --> hostid(1), zones(5), prtconf(1M), nlist(3ELF), attributes(5) >> >> SunOS 5.11 Last change: 1 Jun 2007 3 >> >> >> >> User Commands hostid(1) >> >> NAME >> hostid - print the numeric identifier of the current host >> >> SYNOPSIS >> /usr/bin/hostid >> >> >> DESCRIPTION >> The hostid command prints the identifier of the current host >> --> in hexadecimal. If it is executed within a non-global zone >> --> that emulates a host identifier, then the emulated host >> --> identifier is printed. This numeric value is likely >> to differ when hostid is run on a different machine. >> >> ATTRIBUTES >> See attributes(5) for descriptions of the following attri- >> butes: >> >> ____________________________________________________________ >> | ATTRIBUTE TYPE ATTRIBUTE VALUE | >> | Availability SUNWcsu | >> |___________________________________________________________| >> >> >> SEE ALSO >> --> sysinfo(2), gethostid(3C), zones(5), attributes(5) >> >> >> SunOS 5.11 Last change: 14 Sep 1992 1 >> >> >> >> Standard C Library Functions gethostid(3C) >> >> NAME >> gethostid - get an identifier for the current host >> >> SYNOPSIS >> #include >> >> long gethostid(void); >> >> >> DESCRIPTION >> The gethostid() function returns the 32-bit identifier for >> the current host. If the hardware capability exists, this >> identifier is taken from platform-dependent stable storage; >> otherwise it is a randomly generated number. It is not >> guaranteed to be unique. >> --> >> --> If the calling thread's process is executing within a non- >> --> global zone that emulates a host identifier, then the >> --> zone's emulated 32-bit host identifier is returned. >> >> ATTRIBUTES >> See attributes(5) for descriptions of the following attri- >> butes: >> >> >> >> ____________________________________________________________ >> | ATTRIBUTE TYPE | ATTRIBUTE VALUE | >> |_____________________________|_____________________________| >> | Interface Stability | Standard | >> |_____________________________|_____________________________| >> | MT-Level | MT-Safe | >> |_____________________________|_____________________________| >> >> >> SEE ALSO >> --> hostid(1), sysinfo(2), zones(5), attributes(5), standards(5) >> >> >> SunOS 5.11 Last change: 21 May 2007 1 >> >> >> >> System Calls sysinfo(2) >> >> NAME >> sysinfo - get and set system information strings >> >> SYNOPSIS >> #include >> >> int sysinfo(int command, char *buf, long count); >> >> >> DESCRIPTION >> The sysinfo() function copies information relating to the >> operating system on which the process is executing into the >> buffer pointed to by buf. It can also set certain informa- >> tion where appropriate commands are available. The count >> parameter indicates the size of the buffer. >> >> >> The POSIX P1003.1 interface (see standards(5)) sysconf(3C) >> provides a similar class of configuration information, but >> returns an integer rather than a string. >> >> >> The values for command are as follows: >> >> SI_SYSNAME >> >> Copy into the array pointed to by buf the string that >> would be returned by uname(2) in the sysnamefield. This >> is the name of the implementation of the operating sys- >> tem, for example, SunOS or UTS. >> >> [...] >> >> SI_HW_PROVIDER >> >> Copies the name of the hardware manufacturer into the >> array pointed to by buf. >> >> >> SI_HW_SERIAL >> >> Copy into the array pointed to by buf a string which is >> the ASCII representation of the hardware-specific serial >> number of the physical machine on which the function is >> executed. This might be implemented in Read-Only Memory, >> using software constants set when building the operating >> system, or by other means, and might contain non-numeric >> --> characters. If the function is executed within a non- >> --> global zone that emulates a host identifier, then the >> --> ASCII representation of the zone's host identifier is >> --> copied into the array pointed to by buf. It is >> anticipated that manufacturers will not issue the same >> "serial number" to more than one physical machine. The >> pair of strings returned by SI_HW_PROVIDER and >> SI_HW_SERIAL is not guaranteed to be unique across all >> vendor's SVR4 implementations and could change over the >> lifetime of a given system. >> >> >> SI_SRPC_DOMAIN >> >> Copies the Secure Remote Procedure Call domain name into >> the array pointed to by buf. >> >> [...] >> >> A good estimation for count is 257, which is likely to cover >> all strings returned by this interface in typical installa- >> tions. >> >> SEE ALSO >> boot(1M), dhcpagent(1M), getisax(2), uname(2), >> gethostid(3C), gethostname(3C), sysconf(3C), isalist(5), >> --> zones(5), privileges(5), standards(5) >> >> >> SunOS 5.11 Last change: 15 Apr 2008 5 >> >> >> >> Standards, Environments, and Macros zones(5) >> >> NAME >> zones - Solaris application containers >> >> DESCRIPTION >> The zones facility in Solaris provides an isolated environ- >> ment for running applications. Processes running in a zone >> are prevented from monitoring or interfering with other >> activity in the system. Access to other processes, network >> interfaces, file systems, devices, and inter-process commun- >> ication facilities are restricted to prevent interaction >> between processes in different zones. >> >> [...] >> >> Networking >> A zone has its own port number space for TCP, UDP, and SCTP >> applications and typically one or more separate IP addresses >> (but some configurations of Trusted Extensions share IP >> address(es) between zones). >> >> >> For the IP layer (IP routing, ARP, IPsec, IP Filter, and so >> on) a zone can either share the configuration and state with >> the global zone (a shared-IP zone), or have its distinct IP >> layer configuration and state (an exclusive-IP zone). >> >> >> If a zone is to be connected to the same datalink, that is, >> be on the same IP subnet or subnets as the global zone, then >> it is appropriate for the zone to use the shared IP >> instance. >> >> >> If a zone needs to be isolated at the IP layer on the net- >> work, for instance being connected to different VLANs or >> different LANs than the global zone and other non-global >> zones, then for isolation reasons the zone should have its >> exclusive IP. >> >> >> A shared-IP zone is prevented from doing certain things >> towards the network (such as changing its IP address or >> sending spoofed IP or Ethernet packets), but an exclusive-IP >> zone has more or less the same capabilities towards the net- >> work as a separate host that is connected to the same net- >> work interface. In particular, the superuser in such a zone >> can change its IP address and spoof ARP packets. >> >> >> The shared-IP zones are assigned one or more network inter- >> face names and IP addresses in zonecfg(1M). The network >> interface name(s) must also be configured in the global >> zone. >> >> >> The exclusive-IP zones are assigned one or more network >> interface names in zonecfg(1M). The network interface names >> must be exclusively assigned to that zone, that is, it (or >> they) can not be assigned to some other running zone, nor >> can they be used by the global zone. >> >> SunOS 5.11 Last change: 23 Jan 2007 4 >> >> Standards, Environments, and Macros zones(5) >> >> The full IP-level functionality in the form of DHCP client, >> IPsec and IP Filter, is available in exclusive-IP zones and >> not in shared-IP zones. >> --> >> ->Host Identifiers >> --> A zone is capable of emulating a 32-bit host identifier, >> --> which can be configured via zonecfg(1M), for the purpose >> --> of system consolidation. If a zone emulates a host >> --> identifier, then commands such as hostid(1) and sysdef(1M) >> --> as well as C interfaces such as sysinfo(2) and gethostid(3C) >> --> that are executed within the context of the zone will >> --> display or return the zone's emulated host identifier rather >> --> than the host machine's identifier. >> >> ATTRIBUTES >> See attributes(5) for descriptions of the following attri- >> butes: >> >> ____________________________________________________________ >> | ATTRIBUTE TYPE | ATTRIBUTE VALUE | >> |_____________________________|_____________________________| >> | Availability | SUNWcsu | >> |_____________________________|_____________________________| >> >> SEE ALSO >> zlogin(1), zonename(1), in.rlogind(1M), sshd(1M), >> zoneadm(1M), zonecfg(1M), getzoneid(3C), kill(2), >> priocntl(2), ucred_get(3C), proc(4), attributes(5), >> brands(5), privileges(5), crgetzoneid(9F) >> >> SunOS 5.11 Last change: 23 Jan 2007 5 >> >> >> >> System Administration Commands zonecfg(1M) >> >> NAME >> zonecfg - set up zone configuration >> >> SYNOPSIS >> zonecfg -z zonename >> >> >> zonecfg -z zonename subcommand >> >> >> zonecfg -z zonename -f command_file >> >> >> zonecfg help >> >> >> DESCRIPTION >> The zonecfg utility creates and modifies the configuration >> of a zone. Zone configuration consists of a number of >> resources and properties. >> >> [...] >> >> Properties >> Each resource type has one or more properties. There are >> also some global properties, that is, properties of the con- >> figuration as a whole, rather than of some particular >> resource. >> >> >> The following properties are supported: >> >> (global) >> >> zonename >> >> >> (global) >> >> zonepath >> >> >> (global) >> >> autoboot >> >> >> (global) >> >> bootargs >> >> >> (global) >> >> pool >> >> >> (global) >> >> limitpriv >> >> >> (global) >> >> brand >> >> >> (global) >> >> cpu-shares >> >> --> (global) >> --> >> --> hostid >> >> >> SunOS 5.11 Last change: 2 Apr 2008 3 >> >> [...] >> >> The following table summarizes resources, property-names, >> and types: >> >> resource property-name type >> (global) zonename simple >> (global) zonepath simple >> (global) autoboot simple >> (global) bootargs simple >> (global) pool simple >> (global) limitpriv simple >> (global) brand simple >> (global) ip-type simple >> --> (global) hostid simple >> (global) cpu-shares simple >> (global) max-lwps simple >> (global) max-msg-ids simple >> (global) max-sem-ids simple >> (global) max-shm-ids simple >> (global) max-shm-memory simple >> (global) scheduling-class simple >> fs dir simple >> special simple >> raw simple >> type simple >> options list of simple >> inherit-pkg-dir dir simple >> net address simple >> physical simple >> device match simple >> rctl name simple >> value list of complex >> attr name simple >> type simple >> value simple >> dataset name simple >> dedicated-cpu ncpus simple or range >> importance simple >> >> >> SunOS 5.11 Last change: 2 Apr 2008 11 >> >> [...] >> >> >> global: brand >> >> The zone's brand type. A zone that is not assigned a >> brand is considered a "native" zone. >> >> >> global: ip-type >> >> A zone can either share the IP instance with the global >> zone, which is the default, or have its own exclusive >> instance of IP. >> >> This property takes the values shared and exclusive. >> --> >> --> >> --> global: hostid >> --> >> --> A zone can emulate a 32-bit host identifier to ease >> --> system consolidation. A zone's hostid property is empty >> --> by default, meaning that the zone does not emulate a >> --> host identifier. Zone host identifiers must be >> --> hexadecimal values between 0 and FFFFFFFE. A '0x' or >> --> '0X' prefix is optional. Both uppercase and lowercase >> --> hexadecimal digits are acceptable. >> >> >> fs: dir, special, raw, type, options >> >> Values needed to determine how, where, and so forth to >> mount file systems. See mount(1M), mount(2), fsck(1M), >> and vfstab(4). >> >> SunOS 5.11 Last change: 2 Apr 2008 7 >> >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> > From Darren.Moffat@Sun.COM Thu Oct 23 07:59:32 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NExWWO002410 for ; Thu, 23 Oct 2008 07:59:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9NExQt7064442 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 23 Oct 2008 08:59:32 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K97000035N6JT00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 23 Oct 2008 07:59:30 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9700GUM5N67T90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 23 Oct 2008 07:59:30 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9NExTPL001957 for ; Thu, 23 Oct 2008 14:59:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9700F015H1JT00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 23 Oct 2008 15:59:29 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K97005GY5MOVKA0@fe-emea-10.sun.com>; Thu, 23 Oct 2008 15:59:12 +0100 (BST) Date: Thu, 23 Oct 2008 15:59:12 +0100 From: Darren J Moffat Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008] In-reply-to: <49008E4F.60703@sun.com> Sender: Darren.Moffat@Sun.COM To: Margot Miller Cc: Brian Ruthven - Sun UK , Gerald Jelinek , PSARC-ext@Sun.COM, Jordan.Vaughan@Sun.COM, Gerald.Jelinek@Sun.COM, Ken Erickson Message-id: <49009140.2020109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> <49004B3A.7010700@sun.com> <49008E4F.60703@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 653 Margot Miller wrote: > We (PSARC/2007/078) have talked to this team about the hostid > scheme and the angst it caused with those in MDE. My understanding > is that this current team has talked to MDE to figure out the > impact of this project on their ISV's. Then I find the inconsistency distrubing and it is making me want to pull the derail lever. Why is it acceptable to have a zone's hostid in the clear in the global zone /etc/zone/.xml for SPARC and x86 file yet it isn't acceptable to have the hostid in the clear in /etc/hostid for x86 - even when the source code for the silly obfuscation is open source. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Thu Oct 23 08:09:58 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NF9w8E002625 for ; Thu, 23 Oct 2008 08:09:58 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9NF9q8o011632; Thu, 23 Oct 2008 08:09:56 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9700A2J64IXO00@brm-avmta-1.central.sun.com>; Thu, 23 Oct 2008 09:09:54 -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 <0K97005R464G5960@brm-avmta-1.central.sun.com>; Thu, 23 Oct 2008 09:09:52 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9NF9pad005390; Thu, 23 Oct 2008 11:09:51 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9NF9p5L005387; Thu, 23 Oct 2008 11:09:51 -0400 (EDT) Date: Thu, 23 Oct 2008 11:09:51 -0400 From: James Carlson Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008] In-reply-to: <49009140.2020109@Sun.COM> To: Darren J Moffat Cc: Margot Miller , Brian Ruthven - Sun UK , Gerald Jelinek , PSARC-ext@sun.com, Jordan.Vaughan@sun.com, Gerald.Jelinek@sun.com, Ken Erickson Message-id: <18688.37823.528109.414406@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.4.1.325704 References: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> <49004B3A.7010700@sun.com> <49008E4F.60703@sun.com> <49009140.2020109@Sun.COM> Status: RO Content-Length: 1047 Darren J Moffat writes: > Then I find the inconsistency distrubing and it is making me want to > pull the derail lever. > > Why is it acceptable to have a zone's hostid in the clear in the global > zone /etc/zone/.xml for SPARC and x86 file yet it isn't > acceptable to have the hostid in the clear in /etc/hostid for x86 - even > when the source code for the silly obfuscation is open source. I think a key distinction would be that non-global zones cannot read or write anything in the global zone's /etc/zone/ directory, but they can read and write their own /etc/hostid file just fine. Putting the data outside of the zone itself adds a measure of intentional security, which (given all the trivial ways one can circumvent hostid even without this project) is all that the hostid users have asked for. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Jordan.Vaughan@sun.com Thu Oct 23 14:40:23 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NLeNJw019984 for ; Thu, 23 Oct 2008 14:40:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9NLeLxv025542; Thu, 23 Oct 2008 14:40:21 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9700G09O78B900@brm-avmta-1.central.sun.com>; Thu, 23 Oct 2008 15:40:20 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9700K55O772QE0@brm-avmta-1.central.sun.com>; Thu, 23 Oct 2008 15:40:19 -0600 (MDT) Received: from [129.146.228.104] (quidestveritas.SFBay.Sun.COM [129.146.228.104]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9NLe3Co593077; Thu, 23 Oct 2008 14:40:07 -0700 (PDT) Date: Thu, 23 Oct 2008 14:37:56 -0700 From: Jordan Vaughan Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008] In-reply-to: <49003883.5080408@Sun.COM> To: Darren J Moffat Cc: Gerald.Jelinek@sun.com, PSARC-ext@sun.com Message-id: <4900EEB4.5030401@Sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> <49003883.5080408@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 5823 Darren J Moffat wrote: > Given that 2007/078 stores the hostid in /etc/hostid (for x86 only) was > any consideration given to just using the same mechanism for zones > rather than having a different one ? > Yes, I considered it for a time but settled on the solution presented in the case because storing a non-global zone's hostid in its configuration file is consistent with the current way the zones subsystem works. Pertinent zone configuration information is stored in the zone's configuration file, so it seems natural to store hostid information there as well. Furthermore, splitting a zone's configuration across many files (say, the zone's XML configuration file in /etc/zones and the zone's /etc/hostid file) unnecessarily complicates zone configuration and booting. For example, suppose we want to configure a new zone with some hostid. If the zone does not already exist (i.e., if it is not installed), then where would we store the hostid? In the zone's configuration file. But if it will be stored in the zone's configuration file, then why create a separate /etc/hostid file for the zone later when the hostid is already accessible in the zone's configuration file? Storing a zone's hostid in an /etc/hostid file is superfluous. Additionally, James Carlson made a good point about the security provided by storing non-global zone hostids in their /etc/zone configuration files. Darren J Moffat wrote: > Why is it acceptable to have a zone's hostid in the clear in the global zone /etc/zone/.xml for SPARC and x86 file yet it isn't acceptable to have the hostid in the clear in /etc/hostid for x86 - even when the source code for the silly obfuscation is open source. > What exactly is your concern? If it is the inconsistency between my case and PSARC/2007/078 in that /etc/hostid is obfuscated and non-global zone hostids (as stored in their configuration files) are not, then I agree that obfuscating the system's hostid is pointless given that anyone can examine the source and discover how to circumvent it. I am in favor of removing the obfuscation in /etc/hostid, but I hesitate to agree that this falls within the scope of my case. Brian Ruthven wrote: > Just to make sure this has been covered: > > PSARC/2007/078 (hostids for x86) mentions the legal implications of software licensing against hostids. This case proposes that the hostids are user-supplied, thus may need a Sun Legal check too. > > Brian > If I remember correctly (please correct me if I am misunderstanding your reference), the concern in the PSARC/2007/078 mail was that placing the system's hostid in an /etc/hostid ASCII file would not only invite more license circumvention, but also make it appear as though we (Sun) are encouraging license circumvention and thus betraying our ISVs that use hostids for licensing. Are you concerned that non-global zone hostid emulation might have similar consequences? If so, then I would argue that the concern is unwarranted in this case. We must remember that zones are configurable virtualized execution environments, like virtual operating systems. (I say this not because I think you do not already know it, but to focus our attention on the purpose of zones in order to make a more salient point.) They are *meant* to look and feel like machines distinct from their physical host. Emulating hostids is simply another way to customize the virtualized environments that zones provide so that system consolidation can be more easily facilitated with zones and zone migration across physical nodes can be more flexible when legacy licensed software is in jeopardy (as my case states). We are providing non-global zone hostid emulation for these reasons alone and should clearly state this in our documentation (as I made an effort to do in my proposed man page changes). It is possible that license circumvention might increase slightly with the introduction of non-global zone hostid emulation, but I doubt that it would be a significant increase. For one thing, faking hostids is already possible and easily accomplished (for example, see http://www.software.com/downloads/purchase/Solaris-Hostid-Controller-buy833075.html). If a user wants to circumvent hostid-based licensing, then he can do so today in a variety of ways at little or no cost (except perhaps two minutes of his time) with Sun-developed technologies. Adding non-global zone hostid emulation will not open any new doors to unscrupulous users. Additionally, using non-global zones for the sole purpose of circumventing licensing for a handful of programs is a relatively expensive solution to an easily-solved problem. Zones take disk space, cpu time, and memory, whereas a five- or six-line DTrace script that intercepts sysinfo(2) system calls is much cheaper. Non-global zone hostid emulation will not enlarge the hostid-based licensing circumvention problem that our ISVs already face. Furthermore, I claim that if users were to abuse hostid emulation to circumvent software licensing, a use which would not fall within our stated (documented) intentions for the technology, then we would not be responsible for their actions. If arguing that the potential for such abuse justifies rejecting non-global zone hostid emulation, then destructive DTrace scripting should be eliminated because of the ability it grants users to (easily) circumvent hostid-based software licensing. However, I imagine that we would not eliminate destructive DTrace scripting or consider providing it a betrayal of our ISVs because such abuses fall outside of the stated purposes for the technology. If that is the case, then non-global zone hostid emulation should be permitted as well. My two cents, Jordan From Brian.Ruthven@sun.com Fri Oct 24 04:10:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OBAf8P008305 for ; Fri, 24 Oct 2008 04:10:41 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OBAdQu016215 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 12:10:40 +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 <0K9800B07PPRZJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 05:10:39 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K98000Q7PPQ6D50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 05:10:39 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OBAc7O021362 for ; Fri, 24 Oct 2008 11:10:38 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9800A01PHRBW00@fe-emea-09.sun.com> (original mail from Brian.Ruthven@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 12:10:38 +0100 (BST) Received: from [129.156.173.239] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K98006XPPPJPLE0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 12:10:31 +0100 (BST) Date: Fri, 24 Oct 2008 12:10:31 +0100 From: Brian Ruthven - Sun UK Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008] In-reply-to: <4900EEB4.5030401@Sun.com> Sender: Brian.Ruthven@sun.com To: Jordan Vaughan Cc: Darren J Moffat , Gerald.Jelinek@sun.com, PSARC-ext@sun.com Message-id: <4901AD27.5000900@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> <49003883.5080408@Sun.COM> <4900EEB4.5030401@Sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071119) Status: RO Content-Length: 4772 Hi Jordan, Personally, I'm fine with this, but wanted to make sure all bases were covered. I too would prefer the hostid to be a zone configuration parameter rather then a /etc file within the zone itself, leaving it to those who configure the zone to set it, rather than the super-user within the zone. > My solution for NGZ hostid emulation is to add a 32-bit integral field to the > zone structure zone_t that will contain the zone's hostid or HW_INVALID_HOSTID > (-1) if the zone does not emulate a hostid. The GZ's hostid will be the host > machine's hostid, which will be stored in hw_serial. NGZs will not emulate > hostids by default. Just to clarify: What value is returned by sysinfo(SI_HW_SERIAL) within an NGZ if /bin/hostid is run in the case where emulation is disabled? Thanks, Brian Jordan Vaughan wrote: > Brian Ruthven wrote: > > Just to make sure this has been covered: > > > > PSARC/2007/078 (hostids for x86) mentions the legal implications of > software licensing against hostids. This case proposes that the > hostids are user-supplied, thus may need a Sun Legal check too. > > > > Brian > > > > > If I remember correctly (please correct me if I am misunderstanding > your reference), the concern in the PSARC/2007/078 mail was that > placing the system's hostid in an /etc/hostid ASCII file would not > only invite more license circumvention, but also make it appear as > though we (Sun) are encouraging license circumvention and thus > betraying our ISVs that use hostids for licensing. Are you concerned > that non-global zone hostid emulation might have similar > consequences? If so, then I would argue that the concern is > unwarranted in this case. > > We must remember that zones are configurable virtualized execution > environments, like virtual operating systems. (I say this not because > I think you do not already know it, but to focus our attention on the > purpose of zones in order to make a more salient point.) They are > *meant* to look and feel like machines distinct from their physical > host. Emulating hostids is simply another way to customize the > virtualized environments that zones provide so that system > consolidation can be more easily facilitated with zones and zone > migration across physical nodes can be more flexible when legacy > licensed software is in jeopardy (as my case states). We are > providing non-global zone hostid emulation for these reasons alone and > should clearly state this in our documentation (as I made an effort to > do in my proposed man page changes). > > It is possible that license circumvention might increase slightly with > the introduction of non-global zone hostid emulation, but I doubt that > it would be a significant increase. For one thing, faking hostids is > already possible and easily accomplished (for example, see > http://www.software.com/downloads/purchase/Solaris-Hostid-Controller-buy833075.html). > If a user wants to circumvent hostid-based licensing, then he can do > so today in a variety of ways at little or no cost (except perhaps two > minutes of his time) with Sun-developed technologies. Adding > non-global zone hostid emulation will not open any new doors to > unscrupulous users. Additionally, using non-global zones for the sole > purpose of circumventing licensing for a handful of programs is a > relatively expensive solution to an easily-solved problem. Zones take > disk space, cpu time, and memory, whereas a five- or six-line DTrace > script that intercepts sysinfo(2) system calls is much cheaper. > Non-global zone hostid emulation will not enlarge the hostid-based > licensing circumvention problem that our ISVs already face. > > Furthermore, I claim that if users were to abuse hostid emulation to > circumvent software licensing, a use which would not fall within our > stated (documented) intentions for the technology, then we would not > be responsible for their actions. If arguing that the potential for > such abuse justifies rejecting non-global zone hostid emulation, then > destructive DTrace scripting should be eliminated because of the > ability it grants users to (easily) circumvent hostid-based software > licensing. However, I imagine that we would not eliminate destructive > DTrace scripting or consider providing it a betrayal of our ISVs > because such abuses fall outside of the stated purposes for the > technology. If that is the case, then non-global zone hostid > emulation should be permitted as well. > > My two cents, > Jordan -- Brian Ruthven Sun Microsystems UK Solaris Revenue Product Engineering Tel: +44 (0)1252 422 312 Sparc House, Guillemont Park, Camberley, GU17 9QG From Jordan.Vaughan@sun.com Fri Oct 24 10:34:32 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OHYV2H017618 for ; Fri, 24 Oct 2008 10:34:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OHYItc024453; Fri, 24 Oct 2008 18:34:29 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900F0D7HGA900@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 10:34:28 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9900BE17HF4M90@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 10:34:27 -0700 (PDT) Received: from [129.146.228.104] (quidestveritas.SFBay.Sun.COM [129.146.228.104]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OHYRSa766364; Fri, 24 Oct 2008 10:34:27 -0700 (PDT) Date: Fri, 24 Oct 2008 10:32:21 -0700 From: Jordan Vaughan Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008] In-reply-to: <4901AD27.5000900@sun.com> To: Brian Ruthven - Sun UK Cc: Darren J Moffat , Gerald.Jelinek@sun.com, PSARC-ext@sun.com Message-id: <490206A5.8050400@Sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> <49003883.5080408@Sun.COM> <4900EEB4.5030401@Sun.com> <4901AD27.5000900@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 523 Hi Brian, Brian Ruthven - Sun UK wrote: > > Just to clarify: What value is returned by sysinfo(SI_HW_SERIAL) within > an NGZ if /bin/hostid is run in the case where emulation is disabled? > > Thanks, > Brian > If sysinfo(SI_HW_SERIAL) is called within an NGZ that does not emulate a hostid, then it will return the system's hostid. /bin/hostid uses gethostid(3C), which uses sysinfo(SI_HW_SERIAL), so it will display the system's hostid if executed within an NGZ that does not emulate a hostid. Regards, Jordan From Gerald.Jelinek@Sun.COM Mon Nov 3 06:36:09 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA3Ea903006034 for ; Mon, 3 Nov 2008 06:36:09 -0800 (PST) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA3Ea3Tg029929 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 Nov 2008 14:36:08 GMT 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 <0K9R00A0PHW7R000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.com); Mon, 03 Nov 2008 07:36:07 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9R00AGMHW78V00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.com); Mon, 03 Nov 2008 07:36:07 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA3Ea79G022148 for ; Mon, 03 Nov 2008 14:36:07 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9R00D01HQFAF00@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM) for PSARC-ext@Sun.com (ORCPT PSARC-ext@Sun.com); Mon, 03 Nov 2008 07:36:07 -0700 (MST) Received: from [192.168.0.11] ([206.53.29.107]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9R00CAFHW3F870@mail-amer.sun.com> for PSARC-ext@Sun.com (ORCPT PSARC-ext@Sun.com); Mon, 03 Nov 2008 07:36:05 -0700 (MST) Date: Mon, 03 Nov 2008 07:36:02 -0700 From: Jerry Jelinek Subject: Re: Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008] In-reply-to: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> Sender: Gerald.Jelinek@Sun.COM To: PSARC-ext@Sun.COM, Jordan.Vaughan@Sun.COM Message-id: <490F0C52.3070100@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810221916.m9MJGcVq000222@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080825) Status: RO Content-Length: 159 This fast-track timed out last week. Jordan addressed everyone's questions and there were no objections, so I am marking this closed approved. Thanks, Jerry