Date: Sun, 23 Jul 2000 18:56:25 -0400 (EDT) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Marcel Moolenaar <marcel@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/linux linux_misc.c linux_util.c linux_util.h Message-ID: <Pine.BSF.4.21.0007231839370.539-100000@green.dyndns.org> In-Reply-To: <200007231654.JAA35253@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Jul 2000, Marcel Moolenaar wrote: > marcel 2000/07/23 09:54:19 PDT > > Modified files: > sys/i386/linux linux_misc.c linux_util.c linux_util.h > Log: > Add bounds checking to stackgap_alloc. Previously it was possible > to construct a path that was long enough (ie longer than > SPARE_USRSPACE bytes) and trash the stack. > > Note that SPARE_USRSPACE is much smaller than MAXPATHLEN so that > the Linuxulator will now return ENAMETOOLONG even if the path > is smaller than MAXPATHLEN. Have you thought about simply doing a simple allocation (vm_mmap() will do) of a block of data, creating a linux_emuldata to point the proc.p_emuldata to, sticking a reference to the vm_object there, mapping that page into kmem_map (and keeping an easy-to-use reference address to the userland address, of course) and using it instead of the stackgap? You'd have to do it per-process, even for LinuxThreads, and an idiot user could unmap it (but that would just cause namei() to EFAULT) and shoot themselves in the foot... You lose a page of memory (wired :-/) per Linux process, but you gain better code and the ability to properly use the entire size of a path for the Linux code. Another possibility is to use the upages, which makes it pretty simple, too :) In any case, let's find a better solution than using stackgap at all. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007231839370.539-100000>