Date: Mon, 12 Nov 2001 15:02:11 -0800 (PST)
From: Julian Elischer <julian@elischer.org>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: Robert Watson <rwatson@FreeBSD.org>, freebsd-arch@FreeBSD.org
Subject: Re: cur{thread/proc}, or not.
Message-ID: <Pine.BSF.4.21.0111121457180.94926-100000@InterJet.elischer.org>
In-Reply-To: <3BF05241.74F895EF@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Nov 2001, Terry Lambert wrote: > > I think this is the wrong direction, but if you wanted to do this, > I think that you would need to put the cur* symbols into the per > CPU private pages. This is problematic in the extreme, because it > means that you must set these values each time going down, in order > to be able to substitute a per CPU global for the stack reference. curproc and curthread ARE in the per-cpu private pages. on x86, the %fs segment register points to a small segment that includes the appropriate pages for that cpu. Each cpu is initialised with a different %fs register value. Your private info is accessed as an offset into the 'f' segment which is not used by anything else. 'curthread' is a macro that generates %fs(gd_curthread) (I forget the exact syntax) Similar for other CPUs > I think this is a bad thing, in general, and will lead only to > trouble later. > > I would much rather that the credentials be object referenced off > of non-process, non-thread objects, based on whatever the correct > scoping really is, for the security model you want to enforce. My > "accept" example is only one of a class of changes that could > facilitate this. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" 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.0111121457180.94926-100000>