From owner-freebsd-arch@FreeBSD.ORG Tue Apr 13 00:27:02 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E128106566C; Tue, 13 Apr 2010 00:27:02 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4A18FC08; Tue, 13 Apr 2010 00:27:01 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 9DAD8A563BB; Tue, 13 Apr 2010 08:27:00 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id cTHSnfUMPDeC; Tue, 13 Apr 2010 08:26:54 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id D5467A56357; Tue, 13 Apr 2010 08:26:52 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=NGXXAfTZQKyEqnbzykefQAORUbaecgn1wTUsNWWXvoNTgpqHO0nm0eBbaH5hzz+cJ KcpLEkuDDEU7MdJ4DhXGA== Message-ID: <4BC3BA48.9010009@delphij.net> Date: Mon, 12 Apr 2010 17:26:48 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100408 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Alfred Perlstein References: <4BC39E93.7060906@delphij.net> <20100412233330.GC19003@elvis.mu.org> In-Reply-To: <20100412233330.GC19003@elvis.mu.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: d@delphij.net, freebsd-arch@freebsd.org Subject: Re: _IOWR when errno != 0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 00:27:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/04/12 16:33, Alfred Perlstein wrote: > * Xin LI [100412 15:28] wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> Is there a sane way to copyout ioctl request when the returning errno != >> 0? Looking at the code, currently, in sys/kern/sys_generic.c, we have: >> >> =========== >> error = kern_ioctl(td, uap->fd, com, data); >> >> if (error == 0 && (com & IOC_OUT)) >> error = copyout(data, uap->data, (u_int)size); >> =========== >> >> Is there any objection if I change it to something like: >> >> =========== >> saved_error = kern_ioctl(td, uap->fd, com, data); >> >> if (com & IOC_OUT) >> error = copyout(data, uap->data, (u_int)size); >> if (saved_error) >> error = saved_error; >> =========== > > Is this for linux compat? Do they do this way? I'm not quite sure :-/ I got a bug report and am thinking about how to fix it, it seems that we do not have a generic way of returning an error number while giving some "hints" about the error at the same time, for the ioctl() call. Adding an extra pointer to the request structure seems to be a last-resort way and sounds to be ugly. > I'm not sure this would work, it might seriously break userland > compat. Have you looked around/queiried what the expected outcome > is from a bad ioctl? By default the buffer will be zero'd this > might be unexpected by apps. (all or nothing) Yes that's exactly why I'm asking, my understanding is that for normal usages would be something like: if (ioctl(fd, SIOCSOMETHING, &req) < 0) { // do something to handle the error } else { // use data fed back from req } In this case, I think the result would not be affected. Is there many (if any) programs that don't bother to check return value of ioctl()? Speaking for the userland buffer, for _IOR ioctls, the side effect would be that userland would see a zeroed out 'req' structure (kernel buffer gets zeroed out before calling kern_ioctl), or "half-baked" one (the kernel code may have only written partial data). For _IOWR ioctls, the side effect would be that the userland may get half-baked data. The in-kernel request buffer is always initialized, as it is either overwritten by copyin(), or by bzero() so I don't think sensitive data could be leaked, unless the kernel code intentionally copy some sensitive data to the req buffer, detect if there is error, and then scrub sensitive data away. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLw7pIAAoJEATO+BI/yjfBXjwH/RaheqNyhY0eECcqC5Gz0ycm 2VOpHoe+oRpwHNDYrlNqILKl815HTjpvyi145IpMPIKvEct2O0i6wGJ3FH7VFQwP ucZh6Tj3K3yF+OsFw3iAk69aqFhslb/SuZtuAbJAA4DB+H1rUPtEfWs9y8XjmAaS ZvFTmmP1w1V50I843UJEbY86LqwJGOgGH0mJ6n1mEsLOFyrASrjGajAOb/mEvju4 pLVoaKI9sWGk4QfE9QKol083DuSC/WVbJBFHmzN0K0sNmRfyZofcSIYpWDMkwS4n Mt2M3b6irwul83EkK+cw1gclmV7lUTslfMGtyLbLahZek3HFDh4oZ5xnctfI1xA= =1Hn6 -----END PGP SIGNATURE-----