From owner-cvs-all@FreeBSD.ORG Thu Sep 28 16:21:45 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 79BD516A403; Thu, 28 Sep 2006 16:21:45 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91CAB43D45; Thu, 28 Sep 2006 16:21:44 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 6E08061DF; Thu, 28 Sep 2006 20:21:43 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 444EC6146; Thu, 28 Sep 2006 20:21:43 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8SGLhKm059707; Thu, 28 Sep 2006 20:21:43 +0400 (MSD) (envelope-from ru) Date: Thu, 28 Sep 2006 20:21:43 +0400 From: Ruslan Ermilov To: John Baldwin Message-ID: <20060928162143.GA59634@rambler-co.ru> References: <200609271957.k8RJv25Z028902@repoman.freebsd.org> <200609271752.57082.jhb@freebsd.org> <20060927221251.GA35467@rambler-co.ru> <200609281056.28105.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <200609281056.28105.jhb@freebsd.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found 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 16:21:45 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 28, 2006 at 10:56:27AM -0400, John Baldwin wrote: > On Wednesday 27 September 2006 18:12, Ruslan Ermilov wrote: > > 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. >=20 > I think these are just broken and should be fixed. :) SESIOC_ENCSTAT sho= uld=20 > be IOW(..., ses_encstat) for example. The two troublesome ones GETNOBJ a= nd=20 > GETOBJMAP are broken by design. Somehow they need to tell userland how m= uch=20 > they copied out, and they also need to let userland specify the buffer le= ngth=20 > to avoid buffer overflows. Thus, they need to be using a IOWR with a=20 > structure containing a pointer and length (modify the length on return if= =20 > needed) to avoid problems anyway. I'd be all for just fixing the few tha= t=20 > abuse _IO to treat the arg as anything other than an int and assume _IO m= eans=20 > an int arg for 7.x and future. The solution for 6.x might be uglier, bu= t=20 > for the future we should fix the abusers and avoid adding the _IOWINT hac= k. >=20 > > > If an ioctl doesn't use the arg, then you don't lose anything..=20 > > > do we have any ioctl's that use the arg directly but not as an int? > > >=20 > > Unfortunately yes. >=20 > Are there any others outside of SES? How many? If it's a small list, th= en=20 > let's fix them. The SES ones are broken as an API anyway as mentioned ab= ove,=20 > and if other ioctl's are copying out a variable amount of data w/o allowi= ng=20 > for buffer lengths or telling userland how much it copied, they are also= =20 > fundamentally broken as well. >=20 Some only read from userland, so they aren't broken. I'll compile and send you the list of such ioctls (don't have it saved)... Ah, here's one from memory that isn't broken: SPKRTUNE from sys/dev/speaker/. > > 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". >=20 > It will be stack (or register) garbage yes, but unread stack (or register= )=20 > garbage. :) >=20 Yes, you're right. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFG/aXqRfpzJluFF4RAlooAJ43kHIc7FGIuKmwxZWwDuzbccvlGgCaAj4H u7kXSouLJbXqhnasN5/+vyY= =Qsoa -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z--