1. What is the proposal being presented for review? * Give an overview of the project and its phase(s). This project is to enable Solaris to support disks with variable sector size in powers of 2 starting at 512 bytes, i.e: 1 KByte, 2KB or 4KB. The project team would like to deliver Solaris multiple sector size support in 2 phases: Phase I > Correctly label on large sector size disk. > Can do I/O (raw & block). > ZFS support as non root disk. Phase II > Support UFS > Can install and boot on large sector size disk. * Describe the exposure (OpenSolaris), scope and type of review desired (overview, full case, etc.) OpenSolaris. * Indicate the release binding requested by the project team. See: http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ This project constitutes a "micro" change to Solaris. * What are the project's deliverables? Phase I Modify deliverables in SUNWcsu usr/bin/dd usr/sbin/format usr/sbin/prtvtoc usr/sbin/fdisk usr/sbin/fmthard usr/sbin/newfs usr/sbin/mkfs Modify deliverables in SUNWckr kernel/drv/sd kernel/drv/amd64/sd kernel/drv/sparcv9/sd kernel/drv/sparcv9/ssd kernel/misc/adm64/cmlb kernel/misc/sparcv9/cmlb Modify deliverables in SUNWcsl usr/lib/libefi.so.1 usr/lib/amd64/libefi.so.1 usr/lib/sparcv9/libefi.so.1 Modify deliverables in SUNWstmfu usr/sbin/sbdadm Modify deliverables in SUNWstmf kernel/drv/stmf_sbd kernel/drv/amd64/stmf_sbd kernel/drv/sparcv9/stmf_sbd Modify deliverables in SUNWcakrx platform/i86xpv/kernel/drv/xdf platform/i86xpv/kernel/drv/amd64/xdf platform/i86xpv/kernel/drv/xdb platform/i86xpv/kernel/drv/amd64/xdb Modify deliverables in SUNWldomr platform/sun4v/kernel/drv/sparcv9/vds platform/sun4v/kernel/drv/sparcv9/vdc Phase II Modify deliverables in SUNWckr kernel/fs/sparcv9/ufs kernel/fs/ufs kernel/fs/amd64/ufs boot, install and lvm are TBD * How does this project align with existing or proposed ARC cases? None. 2. Describe user interactions. * Are new user interfaces being proposed, or existing interfaces being changed? No * Explain the similarities in proposed interfaces with existing OS user interfaces (Solaris, Linux, Windows, etc.). To act appropriately with large sector drives, some applications and other components may query for physicial sector size. Windows export IOCTL_STORAGE_QUERY_PROPERTY request to include sector information. Solaris export dkio(7I) DKIOCGMEDIAINFO to include sector information. * Are there any install time changes? In phase I, there is no change to installation. In phase II, there will be changes to install if installing on a large sector disk. 3. What are the exported (defined by your project) and imported (defined by another project that your project then references) interfaces or protocols and their respective stability levels? See: http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ Exported Interface Classification Comments ==================== ===================== ========================== sdstrategy Committed To keep the stability of (b_lblkno in buf_t) buf(9S) structure and to keep backward compatibility sd(7D) exports a logical block size as 512 bytes and sd(7D) is responsible for translating the logical start block address in the I/O request carried by buf(9S) to physical disk block address. -------------------- --------------------- --------------------------- LU provider Committed Add -b option to sdbadm(1M) create-lu subcommand to create a lun with specified sector size. -------------------- --------------------- --------------------------- DKIOCGMEDIAINFO Committed Add a new member to this dkio(7I) to report the physical blocksize of media. -------------------- --------------------- --------------------------- B_RMW Committed A new b_flag to indicate (new b_flags in to do Read Modify Write buf_t) when the I/O request is misaligned. -------------------- --------------------- --------------------------- [s]sd_rmw_enable Committed A global variable can be configured in sd.conf to control sd(7d) to do Read Modify Write if I/O request is misaligned. -------------------- --------------------- --------------------------- physical-bloci-size Committed A new [s]sd tunable in [s]sd-config-list. Imported Interface Classification Comments ==================== ===================== ========================== [s]sd-config-list Committed PSARC 2008/465 -------------------- --------------------- -------------------------- device-blksize(9P) Committed PSARC 2007/339 blksize(9P) * Is there a versioning scheme in place? There is versioning scheme in libefi.so.1 * Has the team secured interface contracts where necessary? No. * Use an ARC prescribed interface table format. See above. 4. Describe any dependencies on hardware (e.g. SPARC exclusive), and on other projects within Solaris. There is agreement within the industry on increasing the physical sector size. However vendors may have different implementations, emulation mode, for example, in which disks with native sector size of 4096 will present to its attached OS a logical sector size of traditional 512 bytes. Emulation requires alignment of 512 byte sectors with in a 4096 sector drive and possibility of a read-modify-write occurrence exists in the drives' firmware. In this case, there is no need to change Solaris. It is assumed that some of the implementations of large sector disk is to use the native sector size but not the emulation mode. Thus Solaris is needed to be changed to support it. 5. Projects need to be aware of the overall security of the system and how their components affect it. Which parts of this project are critical to the security of the system to avoid such unintended consequences such as unauthorized system entry, unauthorized access to or modification of data, elevation of privilege, denial of service, ...? Does this project require elevated privilege? A number of specific policies and practices address various aspects of the security of the system. They are found in appendix 1. Which of these are applicable to this project, and how are they addressed? There is no security issue introduced by this project. 6. Describe means of observing project functionality and performance, by an end user or by a system administrator. Phase I: The end user or a sysadmin can label the large sector disks and add the disks to zpoll and use as data disks. Phase II: The end user or a sysadmin can mount root ZFS, UFS, install and boot on large sector disks. Compared with the traditional 512 byte sector size, disk I/O performance will be improved. 7. How does the project deal with faults and interruptions? Initialization and restarting? The project will follow existing faults and interruptions handling mechanism in the affected modules. 8. How does the project interact with Solaris virtualization technologies (xVM, LDOMs, zones, SunCluster, etc.)? This project will make sure xVM, LDOMs and zones can run on the multiple sector disk drives. Also the project team will make sure multiple sector disk drives can be used as shared cluster disks. 9. Does this project require administration (i.e., configuration or management)? If so, Except adding -d options to 'sbdadm create-lu', which is to create a COMSTAR lun with specific sector size, there is no administration requirement to this project. * How is the project administered, and what sort of review process has this user interface undergone? * Is there a means of aggregating management and/or configuration with other related projects? * Does this project deliver its own administration along with the other components, or is this project an administration interface for other projects? * Are there any external (to Solaris) management interfaces to consider, or being consumed? Projects that require or deliver administrative interfaces are often by their nature security components of the system and should likely address the security question (#5 above, with attention to RBAC and Audit). (See also appendix 2). 10. Have you reviewed the Policies and Best Practices? Are there any exceptions this project needs? See http://www.opensolaris.org/os/community/arc/policies/ http://www.opensolaris.org/os/community/arc/bestpractices/ There are no exceptions. Appendix 1. Security references Plugable Authentication Modules http://opensolaris.org/os/community/arc/policies/PAM/ Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ Service Management Facility (SMF) usage http://opensolaris.org/os/community/arc/policies/SMF-policy/ Install-Time Security http://opensolaris.org/os/community/arc/policies/ITS/ Network Install-Time Security http://opensolaris.org/os/community/arc/policies/NITS-policy/ Secure - by - Default http://opensolaris.org/os/community/arc/policies/secure-by-default/ When to use setuid -vs - RBAC roles and profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ Building RBAC Rights Profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ Adding RBAC Authorizations http://opensolaris.org/os/community/arc/bestpractices/rbac-auths/ Reusable Passwords in Command Line Arguments and Environment Variables http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ Storing Reusable Passwords on a FileSystem http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ Administrative and Security Precedents and Policies http://opensolaris.org/os/community/arc/bestpractices/overview-admin-security/ Security Questions http://opensolaris.org/os/community/arc/bestpractices/security-questions/ Appendix 2. Administrative access and control RBAC (Role Based Access Control): See PSARC/1997/332 Execution Profiles for Restricted Environments http://opensolaris.org/os/community/arc/caselog/1997/332 Privilege: See PSARC/2002/188 Least Privilege for Solaris http://opensolaris.org/os/community/arc/caselog/2002/188 Appendix 3. Policies and Best Practices references http://www.opensolaris.org/os/community/arc/policies/ http://www.opensolaris.org/os/community/arc/bestpractices/