From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 29 12:11:25 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE62716A4B3 for ; Mon, 29 Sep 2003 12:11:25 -0700 (PDT) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7052043FFD for ; Mon, 29 Sep 2003 12:11:24 -0700 (PDT) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 820683ABB5A; Mon, 29 Sep 2003 21:12:58 +0200 (CEST) Date: Mon, 29 Sep 2003 21:12:58 +0200 From: Pawel Jakub Dawidek To: earthman , freebsd-hackers@freebsd.org Message-ID: <20030929191258.GC520@garage.freebsd.pl> References: <16244.53594.942762.784390@canoe.dclg.ca> <20030927115306.R34638@woozle.rinet.ru> <3F759589.9070700@mindspring.com> <811112091.20030929172247@inbox.ru> <20030929154741.GB520@garage.freebsd.pl> <20030929155613.GB551@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline In-Reply-To: <20030929155613.GB551@straylight.oblivion.bg> X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p9 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i Subject: Re: user malloc from kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2003 19:11:25 -0000 --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2003 at 06:56:13PM +0300, Peter Pentchev wrote: +> I mean, won't the application's memory manager attempt to allocate the +> next chunk of memory right over the region that you have stolen with +> this brk(2) invocation? Thus, when the application tries to write into +> its newly-allocated memory, it will overwrite the data that the kernel +> has placed there, and any attempt to access the kernel's data later will +> fail in wonderfully unpredictable ways :) I'm not sure if newly allocated memory will overwrite memory allocated in kernel, but for sure process is able to write to this memory. Sometime ago I proposed model which will allow to remove all copyin(9) calls and many copyout(9), but I'm not so skilled in VM to implement it. --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBP3iEOj/PhmMH/Mf1AQFkAgQAp5ZMnup/3Wi/eg/4IucKCGFDCniCuVdT YmncfReoV+Maofp5PqSk050QXNQxgfHn1I2mZQ03fcp2Y8u8CuJnB1wW1o6AOeYv JPtS6wwC3u4iOxclm2FHwVoyrL0B1lpoVDfDtxJZhPhj3aEs3zqgm/9JKWP6BiWh cb2DG8Zor9Q= =WNzp -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ--