From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 1 10:55:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2240F106564A; Tue, 1 Nov 2011 10:55:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B0F728FC0A; Tue, 1 Nov 2011 10:55:39 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA1AtYEk063355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2011 12:55:34 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA1AtYWZ028340; Tue, 1 Nov 2011 12:55:34 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA1AtYWt028339; Tue, 1 Nov 2011 12:55:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 1 Nov 2011 12:55:34 +0200 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20111101105534.GT50300@deviant.kiev.zoral.com.ua> References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net> <20111025082451.GO50300@deviant.kiev.zoral.com.ua> <86aa8k2im0.fsf@kopusha.home.net> <20111031094948.GB50300@deviant.kiev.zoral.com.ua> <86boswjp7k.fsf@in138.ua3> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a0dfbevZYcQh5kCn" Content-Disposition: inline In-Reply-To: <86boswjp7k.fsf@in138.ua3> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, Robert Watson Subject: Re: "ps -e" without procfs(5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 10:55:40 -0000 --a0dfbevZYcQh5kCn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 01, 2011 at 09:07:11AM +0200, Mikolaj Golub wrote: >=20 > On Mon, 31 Oct 2011 11:49:48 +0200 Kostik Belousov wrote: >=20 > KB> For PROC_ARG and PROC_ENV, you blindly trust the read values of the = arg and > KB> env vector sizes. This can easily cause kernel panics due to unabili= ty to > KB> malloc the requested memory. I recommend to put some clump, and twice > KB> of (PATH_MAX + ARG_MAX) is probably enough (see kern_exec.c, in part= icular, > KB> exec_alloc_args). Also, you might use the swappable memory for the s= trings > KB> as well, in the style of exec_alloc_args(). >=20 > After looking at it more closely, I am not sure if I need to use > exec_alloc_args. I malloc explicitly only for array vector (proc_vector).= And > actually it should be much smaller than 2 * (PATH_MAX + ARG_MAX). Current= ly in > linprocfs the limit is 512 entries: >=20 > #define MAX_ARGV_STR 512 /* Max number of argv-like string= s */ >=20 > The same limit is in libkvm: >=20 > /* > * Check that there aren't an unreasonable number of arguments, > * and that the address is in user space. Special test for > * VM_MIN_ADDRESS as it evaluates to zero, but is not a simple ze= ro > * constant for some archs. We cannot use the pre-processor here= and > * for some archs the compiler would trigger a signedness warning. > */ > if (narg > 512 || addr + 1 < VM_MIN_ADDRESS + 1 || addr >=3D VM_M= AXUSER_ADDRESS) > return (0); >=20 > (BTW, may be the VM_MIN_ADDRESS - VM_MAXUSER_ADDRESS is worth adding in my > code too?) >=20 > So it looks like I should use the same limit (512 * sizeof(char *)) for t= he > allocated array. I could use exec_alloc_args() for the allocation but it = would > reqire some changes: I would have to free using kmem_free_wakeup(), which > requires size of the region, while I return the number of entries. So I'd > rather not use exec_alloc_args() for vector allocation because the benefi= t is > not significant here. >=20 > For strings I use sbuf and set it up using sbuf_new_for_sysctl. I could s= et it > up manually as SBUF_FIXEDLEN allocating buf (up to 2 * (PATH_MAX + ARG_MA= X)) > with exec_alloc_args() but this would complicate things a little. Do you = think > it is worth doing? I mean using the swappable memory for strings, i.e. for the data you are currently store in sbuf. It indeed may be tricky, it was only an idea. --a0dfbevZYcQh5kCn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6v0CYACgkQC3+MBN1Mb4jNzgCghfAuh6dws+2TLXLFotDUIAXb z2IAnA9ZieBI7GugXFeqZcXz7olsr1G1 =fEmU -----END PGP SIGNATURE----- --a0dfbevZYcQh5kCn--