From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 16:06:34 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73988106566B for ; Wed, 9 Apr 2008 16:06:34 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (ns2.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9288FC15 for ; Wed, 9 Apr 2008 16:06:34 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id m39G6VW9071369; Wed, 9 Apr 2008 10:06:31 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.2/8.14.2) with ESMTP id m39G6U6W058521; Wed, 9 Apr 2008 10:06:30 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.2/8.14.2/Submit) id m39G6Usv058518; Wed, 9 Apr 2008 10:06:30 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18428.59782.318085.53492@gromit.timing.com> Date: Wed, 9 Apr 2008 10:06:30 -0600 From: John E Hein To: "M. Warner Losh" In-Reply-To: <20080409.044228.-201314267.imp@bsdimp.com> References: <18427.44466.423562.510257@gromit.timing.com> <40914.1207681578@critter.freebsd.dk> <20080409.044228.-201314267.imp@bsdimp.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: arch@freebsd.org, phk@phk.freebsd.dk Subject: Re: tt_ioctl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2008 16:06:34 -0000 M. Warner Losh wrote at 04:42 -0600 on Apr 9, 2008: > I think I may have originally added the code that John proposed to the > tsc tree (or maybe just my private tree when I was investigating the > problem for others at TSC). It wasn't checked in the local tree - I guess we came up with it independently (assume you're talking about hooking up t_ioctl?). > I think it is the right way to go, and that the ioctl vs security > argument is a bit specious. Well, I could go either way on this issue - 'specious' might be a bit too strong. I could see issues with pass-through device-specific ioctls on tty devs - especially due to the fact that it's a tty device is somewhat obscured in the case of ucom children. On the other hand, tty-based devices are generally protected by other mechanisms (notably unix file permissions). And driver writers should be aware of security implications of ioctls they expose. That requires a bit of thought and more comprehensive system knowledge, however, and maybe it's better to just keep it simple and only allow tty ioctls on tty devices. That said... if we do decide to _not_ hook up t_ioctl, then we should just remove it entirely since it's misleading that it's there but not hooked up. The only thing that remains then (if we remove it) would be what to do with the drivers that have been broken for 3+ years since the ioctl pass-through was removed (digi and the usb driver or two I mentioned in the previous email). Does anyone need to use the unhooked ioctls? How do we find out if they are or are not needed any longer (other than just leaving them unhooked and wait for PRs to appear or not)? I guess that just a more public call might be in order (-stable, -current?). Thanks for the responses so far, by the way.