From sacadmin Thu Feb 12 15:33:38 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 12 Feb 2004 18:28:43 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Peter.Memishian@Sun.COM Subject: 2004/131 I_LIST Without Corruption Content-Length: 5012 I'm sponsoring this fast-track request for Peter Memishian. The timer is set to 02/19/2004. Note that the interfaces described are Standard; they're part of the Single UNIX Specification. Overview ======== As discussed in: 4923054 I_LIST streams ioctl sometimes copies too much data ... if a process issues an I_LIST on a stream that contains a driver with an mi_idname longer than 8 characters, the kernel corrupts its address space. In order to fix this, this case proposes to: 1. Rename the two known drivers with an mi_idname longer than 8 chracters. 2. Enhance the STREAMS framework to check the mi_idname of each driver when it is loaded into the system, and print a warning when a driver with an mi_idname longer than 8 characters is loaded. 3. Harden I_LIST and I_LOOK to only copy out the first 8 characters of a driver's mi_idname field, regardless of the actual length of the field. 4. Update module_info(9S) to clearly state the maximum mi_idname length and the implications of exceeding it. The rationale for this approach is given below. The requested release binding is "minor". Details ======= The mi_idname field of the module_info structure specifies the name of a given STREAMS module or driver. As indicated in module_info(9S), this name is limited to FMNAMESZ (8) characters: The constant FMNAMESZ, limiting the length of a module's name, is set to eight in this release. Unfortunately, the above wording is poor, since this limit affects both STREAMS modules *and* drivers. This limit affects both because interfaces such as I_LIST and I_LOOK make no distinction between modules and drivers -- for instance, I_LIST returns an array of `struct str_mlist' structures, each element being `FMNAMESZ + 1' bytes in size and containing the name of a STREAMS processing element, which could be either a module or a driver. Predominantly because of these interfaces, the existing FMNAMESZ limit is hardcoded into many applications, so it is not feasible to raise it. Thankfully, the STREAMS framework already prohibits loading STREAMS modules with names longer than FMNAMESZ characters, and although no such enforcement is made on driver names, only two Sun drivers are known to have names longer than FMNAMESZ characters: logindmux and mouse8042. These will be changed to be "logdmux" and "ms8042", respectively. Note that this change should have no impact on existing applications, because their filesystem nodes (/dev/logindmux and /dev/kdmouse, respectively) will not change. Further, /dev/logindmux is not documented or available for public use, and any application attempting to issue an I_LIST or I_LOOK against /dev/kdmouse previously had its address space corrupted due to 4923054. However, given that driver names longer than 8 characters: * Were never explicitly forbidden by module_info(9S) or by are existing STREAMS framework. * May be used by existing third party or unbundled device drivers. * Only impact I_LIST, I_LOOK and I_FIND. ... this case proposes to still permit them to be loaded, but with the following warning: STREAMS driver name 'monkeybutlers' is too long; see module_info(9S) for impact. The suggested changes to module_info(9S) are listed below. Finally, given our decision to continue to allow drivers with long names to be loaded, I_LIST and I_LOOK must be enhanced such that applications cannot be corrupted by them. Thus, this cases proposes to have I_LIST and I_LOOK truncate the name returned for any driver longer than FMNAMESZ characters to exactly FMNAMESZ characters. Note that I_FIND has always returned EINVAL when passed a name longer than FMNAMESZ; given that we wish to discourage driver writers from using names longer than FMNAMESZ bytes, this case proposes to leave that behavior as-is. 1,4d0 < For a driver, mi_idname must match the name of the driver < binary file. For a module, mi_idname must match the fname < field of the fmodsw structure. See fmodsw(9S) for details. < 6,7c2,3 < ushort_t mi_idnum; /* module ID number */ < char *mi_idname; /* module name */ --- > ushort_t mi_idnum; /* module or driver ID number */ > char *mi_idname; /* module or driver name */ 13,14c9,17 < The constant FMNAMESZ, limiting the length of a module's < name, is set to eight in this release. --- > For STREAMS modules, the mi_idname must match the fname field of the > fmodsw(9S) structure, which itself is restricted to FMNAMESZ bytes > (excluding the NUL byte). > > For STREAMS drivers, the mi_idname must match the name of the driver > binary file. Because names longer than FMNAMESZ bytes will be > truncated to FMNAMESZ bytes by I_LIST and I_LOOK, and cannot be > found by I_FIND (see streamio(7I)), they are strongly discouraged. > From sacadmin Fri Feb 20 14:20:46 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Feb 2004 17:15:44 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Peter.Memishian@Sun.COM Subject: 2004/131 I_LIST Without Corruption Content-Length: 332 The timer for this fast-track request has expired with nary a comment. I've changed it to closed approved. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Feb 20 15:11:38 2004 From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Feb 2004 18:06:38 -0500 To: James Carlson Cc: psarc@sac.sfbay.sun.com, Peter.Memishian@Sun.COM Subject: re: 2004/131 I_LIST Without Corruption Content-Length: 380 > The timer for this fast-track request has expired with nary a > comment. I've changed it to closed approved. just for the record: in the process of testing my changes, i found one more driver with too long a name: usbser_edge. i'm working with the usb team to rename it appropriately (probably to "usbsedge"). again, this will have no impact on the filesystem. -- meem