PSARC Questions Version 1.17 ------------------------------------------------------------------------ 1. What specifically is the proposal that we are reviewing? - What is the technical content of the project? iSCSI boot project enables Solaris to boot-off iSCSI disk both on x86 and sparc. It modifies Solaris' Kernel stage to load the information of iSCSI boot disk, enumerate it and finally mount the rootfs from there. The information of iSCSI boot disk is passed to the Solaris kernel in very different ways on x86 and sparc (iBFT/OBP respectively). Please refer to section 4 for technical details. - Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", or "micro" change? See the Release Taxonomy in: This is a micro change. - If your project is an evolution of a previous project, what changed from one version to another? N/A - What is the motivation for it, in general as well as specific terms? There are strong requirements from the market. iSCSI boot required on Solaris both x86 and SPARC platforms, because: 1) Sun customers are requesting iSCSI boot options on our Ethernet cards and Storages 2) Intel has iSCSI boot option on their standard NIC for Windows and Linux OS, and Sun can offer this today if we have iSCSI boot on Solaris 3) iSCSI boot is supported on Linux and Windows; therefore we need to reach parity on Solaris 4) iSCSI boot will be the replacement for PXE boot 5) The plan allows iSCSI boot on the standard Network cards without using expensive TOE HBAs. - What are the expected benefits for Sun? Solaris is significantly behind its competitors in this area, and this is the effeort to pace with them. This effort can make Solaris has equivelant power in iSCSI SAN area, diskless workstations, and so forth. - By what criteria will you judge its success? Solaris is able to boot off iSCSI disk both on x86 and sparc. Solaris is able to be installed on iSCSI disk in a gracefuly way. 2. Describe how your project changes the user experience, upon installation and during normal operation. The user should be able to configure/add iSCSI disk during the installation and have Solaris installed on it. The user should be able to select a root device on an iscsi disk and boot from it. - What does the user perceive when the system is upgraded from a previous release? User should see an extra section during the upgrade/installation to configure/add iSCSI disk. 3. What is its plan? Phase I: iscsi boot on X86 07/10/08 One Pager Submitted 07/30/08 PSARC Inception 08/01/08 Phase 2 Exit Review 08/20/08 ARC Commitment Review 09/01/08 Open Source Code Drop 09/05/08 Code Complete 09/15/08 Unit Test Complete 09/15/08 Test Plan Complete 09/15/08 QE Test Started Complete 10/15/08 QE Test Complete 10/20/08 C-Team Review 10/25/08 Integrate Build 102 Phase II: iscsi boot on SPARC and installer changes 01/01/09 OBP Code Complete 02/01/09 Installer Code Complete 02/15/09 Test Plan Complete 03/01/09 QE Test Complete 03/15/09 C-Team Review 03/25/09 Integrate Build 112 - What is its current status? Has a design review been done? Are there multiple delivery phases? The project team has completed a prototype on x86 with iBFT. No design review done yet. There are 2 phases as described above. 4. Are there related projects in Sun? Yes. - If so, what is the proposal's relationship to their work? Which not-yet- delivered Sun (or non-Sun) projects (libraries, hardware, etc.) does this project depend upon? What other projects, if any, depend on this one? Phase II relies on OBP team to support iSCSI and provide target info in eeprom. Installer team relies on this project to improve the NEW installer to configure iSCSI disk during installation. - Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose? If not, please explain the areas of disagreement. No. 5. How is the project delivered into the system? This project will be delivered to ONNV gate for the kernel part and NWSNV gate for the iSCSI software driver part, both in B102. - Identify packages, directories, libraries, databases, etc. SUNWcakr.i platform/i86pc/kernel/unix platform/i86pc/kernel/amd64/unix SUNWcakrx.i platform/i86xpv/kernel/unix platform/i86xpv/kernel/amd64/unix SUNWcakr.u platform/sun4u/kernel/sparcv9/unix SUNWckr kernel/fs/sparcv9/sockfs kernel/fs/sockfs kernel/fs/amd64/sockfs kernel/misc/sparcv9/strplumb kernel/misc/strplumb kernel/misc/amd64/strplumb SUNWiscsir kernel/drv/sparcv9/iscsi kernel/drv/iscsi kernel/drv/amd64/iscsi SUNWcsu usr/sbin/stmsboot 6. Describe the project's hardware platform dependencies. On x86, iSCSI boot needs the iBF support either on SYS ROM, adapter ROM on the NBP. So it depends on NICs/mainbroad supporting iBFT. Currently a number of Intel's and Broadcom's NICs support it. On sparc, iSCSI boot needs the OBP to support iSCSI stack. - Explain any reasons why it would not work on both SPARC and Intel? N/A 7. System administration - How will the project's deliverables be installed and (re)configured? Deliverables should be integrated into WOS and then install media (CD/ DVD/NFS). Uesr needs to confiure iBFT/OBP to boot Solaris from iSCSI disk. For iBFT, the configuration depends on vendor's iBF implementation and probably users need to refer to their manual. Appendix has a documentation , iBFT setup,to describe how to configure iBFT with Intel's NIC. For OBP, the user needs to configure the same set of parameters in OBP, refer to functional spec for details. For installation, currently Solairs is able to be installed on iSCSI disk with legacy installer if the user, Exit the installer to shell before selecting disks Configure iSCSI disk with 'iscsiadm' Restart the installer from shell For upgrade, it is similar with normal installation. User needs to configure iSCSI disk before checking existing OSes. - How will the project's deliverables be uninstalled? N/A - Does it use inetd to start itself? No. - Does it need installation within any global system tables? No. - Does it use a naming service such as NIS, NIS+ or LDAP? No. - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? No special requirement. - How does this project's administrative mechanisms fit into Sun's system administration strategies? E.g., how does it fit under the Solaris Management Console (SMC) and Web-Based Enterprise Management (WBEM), how does it make use of roles, authorizations and rights profiles? Additionally, how does it provide for administrative audit in support of the Solaris BSM configuration? N/A - What tunable parameters are exported? Can they be changed without rebooting the system? Examples include, but are not limited to, entries in /etc/system and ndd(8) parameters. What ranges are appropriate for each tunable? What are the commitment levels associated with each tunable (these are interfaces)? N/A 8. Reliability, Availability, Serviceability (RAS) - Does the project make any material improvement to RAS? N/A - How can users/administrators diagnose failures or determine operational state? (For example, how could a user tell the difference between a failure and very slow performance?) N/A - What are the project's effects on boot time requirements? This project changes the Kernel Stage in Solaris booting, pleae refer the section 2,4 and 5 in the functional spec for details. The OS may fail to boot up if the iSCSI target is inaccessible. - How does the project handle dynamic reconfiguration (DR) events? N/A - What mechanisms are provided for continuous availability of service? iSCSI software initiator provides MST (multiple session per target) to enable the failover of iSCSI boot target. Intel' iBF implementation support redundant NICs to cover network failures. - Does the project call panic()? Explain why these panics cannot be avoided. No. - How are significant administrative or error conditions transmitted? SNMP traps? Email notification? N/A - How does the project deal with failure and recovery? iSCSI software initiator support MST and MPxIO to deal with failure and recovery. - Does it ever require reboot? If so, explain why this situation cannot be avoided. If there are second path available the the root disk no reboot is needed. - How does your project deal with network failures (including partition and re- integration)? How do you handle the failure of hardware that your project depends on? iSCSI software will try to reestabllish the connection to the boot target if failures occurr on the network. - Can it save/restore or checkpoint and recover? Yes. - Can its files be corrupted by failures? Does it clean up any locks/files after crashes? No. 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? N/A - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? The system should be able to boot and the access to root disk is stable if no hard failures in network. - What statistics does the subsystem export, and by what mechanism? N/A - What state information is logged? N/A - In principle, would it be possible for a program to tune the activity of your project? No, unless to boot from somewhere else. 10. What are the security implications of this project? - What security issues do you address in your project? CHAP is used to authenticate the iSCSI boot target. - The Solaris BSM configuration carries a Common Criteria (CC) Controlled Access Protection Profile (CAPP) -- Orange Book C2 -- and a Role Based Access Control Protection Profile (RBAC) -- rating, does the addition of your project effect this rating? E.g., does it introduce interfaces that make access or privilege decisions that are not audited, does it introduce removable media support that is not managed by the allocate subsystem, does it provide administration mechanisms that are not audited? No - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? If CHAP is not configured it is possible to boot from an unauthencicated target. - Please justify the introduction of any (all) new setuid executables. N/A - Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. A separate Security Questionnaire http://sac.sfbay/cgi-bin/bp.cgi?NAME=Security.bp is provided for more detailed guidance on the necessary information. Cases are encouraged to fill out and include the Security questionnaire (leveraging references to existing documentation) in the case materials. Projects must highlight information for the following important areas: - What features are newly visible on the network and how are they protected from exploitation (e.g. unauthorized access, eavesdropping) N/A - If the project makes decisions about which users, hosts, services, ... are allowed to access resources it manages, how is the requestor's identity determined and what data is used to determine if the access granted. Also how this data is protected from tampering. N/A - What privileges beyond what a common user (e.g. 'noaccess') can perform does this project require and why those are necessary. N/A - What parts of the project are active upon default install and how it can be turned off. The connection to iSCSI boot targe tis established during boot while IPSec is not available yet. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? Nevada. - Environment variables? Exit status? Signals issued? Signals caught? (See signal(3HEAD).) No. - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? No. - Does it use any "hidden" (filename begins with ".") or temp files? No. - Does it use any locking files? No. - Command line or calling syntax: What options are supported? (please include man pages if available) Does it conform to getopt() parsing requirements? No command line changed/imported. - Is there support for standard forms, e.g. "-display" for X programs? Are these propagated to sub-environments? No. - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? No. - Identify and justify the requirement for any static libraries. No. - Does it depend on kernel features not provided in your packages and not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional kernel loadable modules)? No. - Is your project 64-bit clean/ready? If not, are there any architectural reasons why it would not work in a 64-bit environment? Does it interoperate with 64-bit versions? Yes. - Does the project depend on particular versions of supporting software (especially Java virtual machines)? If so, do you deliver a private copy? What happens if a conflicting or incompatible version is already or subsequently installed on the system? No. - Is the project internationalized and localized? No, and no need. - Is the project compatible with IPV6 interfaces and addresses? Yes, both iBFT and OBF will support IPv6 as the address of boot target. 12. What is its window/desktop operational environment? - Is it ICCCM compliant (ICCCM is the standard protocol for interacting with window managers)? N/A - X properties: Which ones does it depend on? Which ones does it export, and what are their types? N/A - Describe your project's support for User Interface facilities including Help, Undo, Cut/Paste, Drag and Drop, Props, Find, Stop? N/A - How do you respond to property change notification and ICCCM client messages (e.g. Do you respond to "save workspace")? N/A - Which window-system toolkit/desktop does your project depend on? N/A - Can it execute remotely? Is the user aware that the tool is executing remotely? Does it matter? N/A - Which X extensions does it use (e.g. SHM, DGA, Multi-Buffering? (Hint: use "xdpyinfo") N/A - How does it use colormap entries? Can you share them? N/A - Does it handle 24-bit operation? N/A 13. What interfaces does your project import and export? - Please provide a table of imported and exported interfaces, including stability levels. Pay close attention to the classification of these interfaces in the Interface Taxonomy -- e.g., "Committed," "Uncommitted," and "*Private;" see: http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp Interfaces Imported Interface Classification Comments psm_map_new Consolidation Private PSARC/1995/422 psm_unmap Consolidation Private PSARC/1995/422 ddi_prop_lookup_string Public iBFT ACPI 3.0b specification Microsoft License OBP properties for iSCSI Boot TBD - Exported public library APIs and ABIs No. - Other interfaces No. - What other applications should it interoperate with? How will it do so? N/A - Is it "pipeable"? How does it use stdin, stdout, stderr? N/A - Explain the significant file formats, names, syntax, and semantics. N/A - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? N/A - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? N/A 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? - Protocols (public or private) iSCSI RFC 3720 - Internet Small Computer Systems Interface (iSCSI), public CHAP RFC 1994 PPP Challenge Handshake Authentication Protocol, public iBFT Defined in ACPI 3.0b Specification, subject to Miscosoft's license - Private ToolTalk usage No. - Files No. - Other No. - Are the interfaces re-entrant? No. 15. Is the interface extensible? How will the interface evolve? N/A 16. How do the interfaces adapt to a changing world? N/A 17. Interoperability - If applicable, explain your project's interoperability with the other major implementations in the industry. In particular, does it interoperate with Microsoft's implementation, if one exists? iSCSI boot in Solaris should be able to work with the iSCSI target if the latter complies with iSCSI protocol. - What would be different about installing your project in a heterogeneous site instead of a homogeneous one (such as Sun)? N/A - Does your project assume that a Solaris-based system must be in control of the primary administrative node? No. 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? N/A - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? N/A - Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? N/A - What is your project's MT model? How does it use threads internally? How does it expect its client to use threads? If it uses callbacks, can the called entity create a thread and recursively call back? iSCSI software is a MT based kernel module and uses different kernel threads to send/recv packets and some other stuffs. - What is the impact on overall system performance? What is the average working set of this component? How much of this is shared/sharable by other apps? N/A. - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? N/A - Will it require large files/databases (for example, new fonts)? No. - Do files, databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? No. 19. Please identify any issues that you would like the ARC to address. N/A 20. Appendices to include -One-pager is sent together with this doc. -new-boot sparc http://sac.sfbay/PSARC/2006/525 -Solaris Boot Architecture http://sac.sfbay/PSARC/2004/454 -scsi-self-identifying http://sac.eng.sun.com/PSARC/2008/337 -iSCSI Software boot http://sac.sfbay/PSARC/2007/450 -Intel iSCSI Boot Support http://www.intel.com/network/connectivity/products/iscsiboot.htm -IBFT Specification http://www.microsoft.com/whdc/system/platform/firmware/ibft.mspx -Challenge Handshake Authentication Protocol http://www.ietf.org/rfc/rfc1994.txt