Date: Mon, 06 Dec 1999 15:31:35 -0800 From: Mike Smith <msmith@freebsd.org> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: freebsd-hackers@FreeBSD.ORG, gallatin@cs.duke.edu Subject: Re: Is part of user stack always mapped? Message-ID: <199912062331.PAA02867@mass.cdrom.com> In-Reply-To: Your message of "Mon, 06 Dec 1999 17:16:31 EST." <199912062216.RAA09858@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I was under the impression that this was a no-no & one should use > > copyin/copout & friends to access memory on users's stacks. Although > > this appears to work on the i386, if I try this on the alpha I take a > > fatal trap when accessing *set. > > > > So -- how does this work on the i386? Is the user's stack always > > mappeped into the kernel's address space? Should it also work on the > > alpha? > > > On i386, under the current implementation, the kernel can directly access > curproc's address space (not just the stack, stack is used because we're > sure the spare space won't/shouldn't be used by the user application). > I don't know if the same is true for alpha, but this should definitely > be considered an implementation dependent feature. I wish there were some > other ways to bypass copyin/out in ioctls. The problem wouldn't be a problem if the implementation portion of system call code didn't make assumptions about whether data is in user- or kernel-space. This has been an off and on topic of discussion for some time now. The ABI emulators use the stackgap because there are system call implementations that expect to be moving their data structures to/from user space. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912062331.PAA02867>