From owner-cvs-all@FreeBSD.ORG Thu Sep 28 14:56:42 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19F3616A494; Thu, 28 Sep 2006 14:56:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89F6343D53; Thu, 28 Sep 2006 14:56:33 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8SEuUpx005561; Thu, 28 Sep 2006 10:56:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Ruslan Ermilov Date: Thu, 28 Sep 2006 10:56:27 -0400 User-Agent: KMail/1.9.1 References: <200609271957.k8RJv25Z028902@repoman.freebsd.org> <200609271752.57082.jhb@freebsd.org> <20060927221251.GA35467@rambler-co.ru> In-Reply-To: <20060927221251.GA35467@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609281056.28105.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 28 Sep 2006 10:56:31 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1949/Thu Sep 28 09:03:14 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/atkbdc atkbd.c src/sys/dev/digi digi.c src/sys/dev/kbdmux kbdmux.c src/sys/dev/syscons scvidctl.c syscons.c src/sys/dev/uart uart_kbd_sun.c src/sys/dev/usb ukbd.c src/sys/dev/vkbd vkbd.c src/sys/fs/procfs procfs_ioctl.c ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2006 14:56:42 -0000 On Wednesday 27 September 2006 18:12, Ruslan Ermilov wrote: > On Wed, Sep 27, 2006 at 05:52:56PM -0400, John Baldwin wrote: > > Could you avoid IOWINT by just assuming that any _IO() ioctl is getting an int > > as the arg? > > > There are some _IO() ioctls that pass a pointer to variable sized data, > and their ioctl handlers to uiocopy'ing rather than ioctl(). See > sys/cam/scsi/scsi_ses.c, SESIOC_* ioctls for one such example. I think these are just broken and should be fixed. :) SESIOC_ENCSTAT should be IOW(..., ses_encstat) for example. The two troublesome ones GETNOBJ and GETOBJMAP are broken by design. Somehow they need to tell userland how much they copied out, and they also need to let userland specify the buffer length to avoid buffer overflows. Thus, they need to be using a IOWR with a structure containing a pointer and length (modify the length on return if needed) to avoid problems anyway. I'd be all for just fixing the few that abuse _IO to treat the arg as anything other than an int and assume _IO means an int arg for 7.x and future. The solution for 6.x might be uglier, but for the future we should fix the abusers and avoid adding the _IOWINT hack. > > If an ioctl doesn't use the arg, then you don't lose anything.. > > do we have any ioctl's that use the arg directly but not as an int? > > > Unfortunately yes. Are there any others outside of SES? How many? If it's a small list, then let's fix them. The SES ones are broken as an API anyway as mentioned above, and if other ioctl's are copying out a variable amount of data w/o allowing for buffer lengths or telling userland how much it copied, they are also fundamentally broken as well. > > The > > ioctl(2) manpage implies that 'data' is either a pointer or an int. If you > > go this route, you avoid changing all the ioctl values, basically just assume > > that IOC_VOID means the argument is an int. > > > That has been considered and found impossible due to the above. > We also don't have any spare bits left in the ioctl type field, > so IOC_VOID with size == sizeof(int) have been used to implement > _IOWINT(). IOC_VOID is incorrect name, the argument should either > be a pointer or an "int", even when not used by ioctl(). Some > ioctl() calls to "void" ioctls in userland don't pass a third > argument. I think on architectures that pass arguments on the > stack (such as i386) this causes return address to be accessed > instead of the argument value. Ioctls that are "void" should > either pass "0" or "NULL". It will be stack (or register) garbage yes, but unread stack (or register) garbage. :) -- John Baldwin