|
|
|
|
|
|
| Author |
Message |
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
 Posted: Sat Mar 30, 2002 4:16 am Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
On Fri, 29 Mar 2002, Robert Watson wrote:
| Quote: | For VFS, which is a special case, I'd actually like to see both
credentials passed down the stack explicitly, meaning that worker
threads and processes in kernel don't have to tweak their active
credential in order to make a request on behalf of another thread or
process (think async io, async nfs rpc activities, etc). This actually
suggests a model something like...
|
BTW, this would also address races and problems associated with files kept
open by the kernel for kernel-sponsored activies. Right now, when the
kernel "saves" a credential for use with a saved vnode, it can't guarantee
that all access control uses the saved credential. Some may use the
active thread credential from curthread. For example, UFS will frequently
use curthread->td_ucred for authorization when writing out account or
quota data, which is arguably wrong. The quota and accounting code should
cache two credentials for different parts of the access control decision,
and both of those should be explicitly different from curthread's. This
would also fix MAC and these functions, FYI  .
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
| Posted: Sat Mar 30, 2002 4:12 am Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
On Fri, 29 Mar 2002, John Baldwin wrote:
| Quote: | During a discussion on the smp@ list about changes to the suser() API
to make use of td_ucred, it was brought up that the new suser() would
be assuming that the passed in thread pointer was curthread so why not
just use curthread in suser() and not pass in a pointer at all. There
are several places in the kernel where the same assumption is made.
Thus, my question is: which general approach should we follow, and
should we perhaps switch to using explicit curthread's everywhere and
stop passing thread pointers around on the stack?
|
There are a number of situations which are rather sticky involving
credentials and VFS. Basically, the set of relevant credentials is often
two or three different credentials (especially for filesystems like
procfs). Typically there's a cached credential associated with a
persistent data naming abstraction (sich as the struct file pointing at a
socket or vnode), as well as the active requesting credential. This means
that low-level access control primitives almost always need to accept an
explicit credential reference, although higher level primitives might make
assumptions about the source of the credential. In the file system and
specfs code, I've seen both the explicit VFS credential (usually sourced
from a struct file, although not always), and the active requesting
credential used. Frequently, incorrectly, actually. For example, there
are a number of places where the cached credential is used and really
should not be; likewise, there are a number of places where incorrect
assumptions may be made about credentials belonging to curproc/thread.
For VFS, which is a special case, I'd actually like to see both
credentials passed down the stack explicitly, meaning that worker threads
and processes in kernel don't have to tweak their active credential in
order to make a request on behalf of another thread or process (think
async io, async nfs rpc activities, etc). This actually suggests a model
something like...
vop_foo(vp, ..., cachedcred, activecred);
for almost all VOP's.
For many other simpler non-VFS/socket/... cases, moving to implicit
curthread-derived credentials is probably the right choice, as it limits
the exposure of specific structures in code that doesn't care about the
structures. Even if we don't move to using curthread (for performance or
other reasons), we should be making *extremely* heavy use of KASSERT().
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Fri Mar 29, 2002 11:02 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
On Fri, 29 Mar 2002, Kirk McKusick wrote:
| Quote: | So, while removing proc/thread parameters from existing functions
is reasonable, we should consider whether they should be replaced
with pointers to credentials.
|
For that we have suser_cred(cred,...) elready.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Fri Mar 29, 2002 10:57 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
Poul-Henning Kamp wrote:
| Quote: | In message <20020329202504.GZ93885@elvis.mu.org>, Alfred Perlstein writes:
What about people (ab)?using the device driver interface for proc
related stuff?
The main purpose of the excercise is stop such abuse: People think
they can track per instance using that argument, and _that_ just ain't
going to happen until we hang devices directly under struct file
and doing that will screw filesystems which use VOP's to access
their device big time.
|
Poul's right.
If you were guaranteed the ability to do this, then people would
be able to use multiple sessions of VMWare on FreeBSD, only a few
*YEARS* after VMWare was first ported.
Then where would we be?
Oh wait.
That's a good thing.
Poul's wrong.
Never mind.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Fri Mar 29, 2002 10:52 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
Alfred Perlstein wrote:
| Quote: | For instance, some APIs are broken such that they allow the passing
of a proc/thread in, but if it isn't curproc then we die a painful
death. Those functions need to stop taking a proc/thread pointer
and be documented that they use the current process for cred/misc
processing.
|
Heh.
My reaction was that they should be fixed to not die a painful death
because of an implied equality dependency that shouldn't be there in
the first place... not have the passed value ripped out so that the
assumption can be enshrined for all time.
Tomato/tomato.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
John Baldwin
*nix forums Guru Wannabe
Joined: 27 Mar 2002
Posts: 278
|
| Posted: Fri Mar 29, 2002 9:38 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
On 29-Mar-2002 Kirk McKusick wrote:
| Quote: | Date: Fri, 29 Mar 2002 14:32:22 -0500 (EST)
From: John Baldwin <jhb@FreeBSD.ORG
To: arch@FreeBSD.ORG
Subject: curthread vs. passing thread pointers around
Sender: owner-freebsd-arch@FreeBSD.ORG
List-ID: <freebsd-arch.FreeBSD.ORG
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
During a discussion on the smp@ list about changes to the suser()
API to make use of td_ucred, it was brought up that the new suser()
would be assuming that the passed in thread pointer was curthread
so why not just use curthread in suser() and not pass in a pointer
at all. There are several places in the kernel where the same
assumption is made. Thus, my question is: which general approach
should we follow, and should we perhaps switch to using explicit
curthread's everywhere and stop passing thread pointers around on
the stack?
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
The whole business of passing proc pointers got started in the late
1980's when we went on a big kernel cleanup campaign to get rid of
all references to u.u_variable. Most of that efforts worked out
well. For example, having most kernel functions return an error
rather than stuffing it in u.u_error. That also explains the
numerous /* XXX */ comments scattered through the kernel whenever
curproc (or now curthread) gets used; the idea was that the proc
(or thread) pointer should have been a parameter. A few years ago
I set out to try to clean up all those global references, and found
that I had to add a proc pointer parameter to nearly every function
in the top half of the kernel. I concluded that the extra overhead
was simply not worth it, and that we should just continue using the
global pointer as we do now. There are still instances where
credentials should be passed as parameters since it is not the case
that using the current threads credential is the right thing to do.
For example, the NFS server wants to use the credential of the
incoming request, not its own in deciding filesystem access. I
can also believe that suser() might have places where it would
want to use a different credential than that of the current thread.
So, while removing proc/thread parameters from existing functions
is reasonable, we should consider whether they should be replaced
with pointers to credentials.
|
Yes, in the suser() discussion on smp@ we will have at least two
versions of suser(), one which uses the credential of curthread, and
another which accepts a credential directly to perform the test against.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Fri Mar 29, 2002 8:45 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
On Fri, 29 Mar 2002, Alfred Perlstein wrote:
| Quote: | * Poul-Henning Kamp <phk@critter.freebsd.dk> [020329 11:55] wrote:
In message <20020329194158.GX93885@elvis.mu.org>, Alfred Perlstein writes:
* John Baldwin <jhb@FreeBSD.org> [020329 11:32] wrote:
During a discussion on the smp@ list about changes to the suser()
API to make use of td_ucred, [...]
On a related note: I intend to change the open/close/ioctl interface
to device drivers from a "struct thread *" to a "struct ucred *".
What about people (ab)?using the device driver interface for proc
related stuff?
|
then they can (AB)use curthread..
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Fri Mar 29, 2002 8:41 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
On Fri, 29 Mar 2002, Poul-Henning Kamp wrote:
| Quote: | In message <20020329194158.GX93885@elvis.mu.org>, Alfred Perlstein writes:
* John Baldwin <jhb@FreeBSD.org> [020329 11:32] wrote:
During a discussion on the smp@ list about changes to the suser()
API to make use of td_ucred, [...]
On a related note: I intend to change the open/close/ioctl interface
to device drivers from a "struct thread *" to a "struct ucred
|
That's probably ok, though I have an uneasy feeling about it..
I'd go further and say that you should not even pass that.
anyone needing it can do curthread->td_ucred. Hardly any drivers use it.
Since AIO doesn't include open/close I am not sure I can think of a case
when the curthread is not the thread that should be charged/authorised
with the open/ioctl/close.
In many cases td is only used to fead to suser*() in which
case it wouldn't be needed at all.
I think we could make a case for CURRENT code that we need not
pass anything at all, but what are we cutting out in th epossible future?
| Quote: |
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
|
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Kirk McKusick
*nix forums beginner
Joined: 19 Mar 2002
Posts: 40
|
| Posted: Fri Mar 29, 2002 8:30 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
Date: Fri, 29 Mar 2002 14:32:22 -0500 (EST)
From: John Baldwin <jhb@FreeBSD.ORG>
To: arch@FreeBSD.ORG
Subject: curthread vs. passing thread pointers around
Sender: owner-freebsd-arch@FreeBSD.ORG
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
During a discussion on the smp@ list about changes to the suser()
API to make use of td_ucred, it was brought up that the new suser()
would be assuming that the passed in thread pointer was curthread
so why not just use curthread in suser() and not pass in a pointer
at all. There are several places in the kernel where the same
assumption is made. Thus, my question is: which general approach
should we follow, and should we perhaps switch to using explicit
curthread's everywhere and stop passing thread pointers around on
the stack?
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
The whole business of passing proc pointers got started in the late
1980's when we went on a big kernel cleanup campaign to get rid of
all references to u.u_variable. Most of that efforts worked out
well. For example, having most kernel functions return an error
rather than stuffing it in u.u_error. That also explains the
numerous /* XXX */ comments scattered through the kernel whenever
curproc (or now curthread) gets used; the idea was that the proc
(or thread) pointer should have been a parameter. A few years ago
I set out to try to clean up all those global references, and found
that I had to add a proc pointer parameter to nearly every function
in the top half of the kernel. I concluded that the extra overhead
was simply not worth it, and that we should just continue using the
global pointer as we do now. There are still instances where
credentials should be passed as parameters since it is not the case
that using the current threads credential is the right thing to do.
For example, the NFS server wants to use the credential of the
incoming request, not its own in deciding filesystem access. I
can also believe that suser() might have places where it would
want to use a different credential than that of the current thread.
So, while removing proc/thread parameters from existing functions
is reasonable, we should consider whether they should be replaced
with pointers to credentials.
Kirk McKusick
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Fri Mar 29, 2002 8:29 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
In message <Pine.BSF.4.21.0203291234080.726-100000@InterJet.elischer.org>, Juli
an Elischer writes:
| Quote: | On a related note: I intend to change the open/close/ioctl interface
to device drivers from a "struct thread *" to a "struct ucred
That's probably ok, though I have an uneasy feeling about it..
I'd go further and say that you should not even pass that.
anyone needing it can do curthread->td_ucred.
|
Yeah, well, unless you run GEOM where the request may have been
queued and you're running in context of a worker thread. (The
infinite stacking issue again).
| Quote: | I think we could make a case for CURRENT code that we need not
pass anything at all, but what are we cutting out in th epossible future?
|
That's what I'm afraid off too.
There are several things in this, one of which is locking, the other
the scale of changes needed to fix up the tree.
The simple solution is probably to add three new members to cdevsw{}:
sopen, sclose, sioctl (s for simple or something) which doesn't have
that final argument at all.
Drivers can be converted gradually.
Specfs can figure out which version of the method to call, and do
locking as/if needed.
I really wish we had a compile-time optimized version of KOBJ we
could use for devsw...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Fri Mar 29, 2002 7:32 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
In message <20020329202504.GZ93885@elvis.mu.org>, Alfred Perlstein writes:
| Quote: | * Poul-Henning Kamp <phk@critter.freebsd.dk> [020329 11:55] wrote:
In message <20020329194158.GX93885@elvis.mu.org>, Alfred Perlstein writes:
* John Baldwin <jhb@FreeBSD.org> [020329 11:32] wrote:
During a discussion on the smp@ list about changes to the suser()
API to make use of td_ucred, [...]
On a related note: I intend to change the open/close/ioctl interface
to device drivers from a "struct thread *" to a "struct ucred *".
What about people (ab)?using the device driver interface for proc
related stuff?
|
The main purpose of the excercise is stop such abuse: People think
they can track per instance using that argument, and _that_ just ain't
going to happen until we hang devices directly under struct file
and doing that will screw filesystems which use VOP's to access
their device big time.
There are two cases of non-abuse which I know off: streams and
/dev/fd*
streams I'm not sure about yet (is it even in use any more ?)
/dev/fd could be solved by embedding fdescfs into devfs.
Either way, it's a major patch, which can only partially be
machine generated so it is probably not iminent.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Alfred Perlstein
*nix forums addict
Joined: 19 Mar 2002
Posts: 67
|
| Posted: Fri Mar 29, 2002 7:32 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
* Poul-Henning Kamp <phk@critter.freebsd.dk> [020329 11:55] wrote:
| Quote: | In message <20020329194158.GX93885@elvis.mu.org>, Alfred Perlstein writes:
* John Baldwin <jhb@FreeBSD.org> [020329 11:32] wrote:
During a discussion on the smp@ list about changes to the suser()
API to make use of td_ucred, [...]
On a related note: I intend to change the open/close/ioctl interface
to device drivers from a "struct thread *" to a "struct ucred *".
|
What about people (ab)?using the device driver interface for proc
related stuff?
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Fri Mar 29, 2002 7:32 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
In message <20020329194158.GX93885@elvis.mu.org>, Alfred Perlstein writes:
| Quote: | * John Baldwin <jhb@FreeBSD.org> [020329 11:32] wrote:
During a discussion on the smp@ list about changes to the suser()
API to make use of td_ucred, [...]
|
On a related note: I intend to change the open/close/ioctl interface
to device drivers from a "struct thread *" to a "struct ucred *".
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Alfred Perlstein
*nix forums addict
Joined: 19 Mar 2002
Posts: 67
|
| Posted: Fri Mar 29, 2002 7:32 pm Post subject:
Re: curthread vs. passing thread pointers around
|
|
|
* John Baldwin <jhb@FreeBSD.org> [020329 11:32] wrote:
| Quote: | During a discussion on the smp@ list about changes to the suser()
API to make use of td_ucred, it was brought up that the new suser()
would be assuming that the passed in thread pointer was curthread
so why not just use curthread in suser() and not pass in a pointer
at all. There are several places in the kernel where the same
assumption is made. Thus, my question is: which general approach
should we follow, and should we perhaps switch to using explicit
curthread's everywhere and stop passing thread pointers around on
the stack?
|
Yes and no. :)
For instance, some APIs are broken such that they allow the passing
of a proc/thread in, but if it isn't curproc then we die a painful
death. Those functions need to stop taking a proc/thread pointer
and be documented that they use the current process for cred/misc
processing.
It also depends on how painful/good it is to use globals, if accesses
to per-cpu data are expensive then we don't want curproc/curthread
if they are not then we obviously want to remove register and stack
space usage by using global data.
So it's a judgement call isn't it? :)
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
John Baldwin
*nix forums Guru Wannabe
Joined: 27 Mar 2002
Posts: 278
|
| Posted: Fri Mar 29, 2002 7:32 pm Post subject:
curthread vs. passing thread pointers around
|
|
|
During a discussion on the smp@ list about changes to the suser()
API to make use of td_ucred, it was brought up that the new suser()
would be assuming that the passed in thread pointer was curthread
so why not just use curthread in suser() and not pass in a pointer
at all. There are several places in the kernel where the same
assumption is made. Thus, my question is: which general approach
should we follow, and should we perhaps switch to using explicit
curthread's everywhere and stop passing thread pointers around on
the stack?
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 5:22 am | All times are GMT
|
|
Debt Consolidation | Loans | Mortgage | Debt Consolidation | Debt Consolidation
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
