Date: Tue, 6 Jul 1999 12:56:56 +0200 From: Ladavac Marino <mladavac@metropolitan.at> To: 'Dan Seguin' <dseg@texar.com>, Ladavac Marino <mladavac@metropolitan.at> Cc: FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG> Subject: RE: Connect and so on.. Message-ID: <55586E7391ACD211B9730000C11002761796D2@r-lmh-wi-100.corpnet.at>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Dan Seguin [SMTP:dseg@texar.com] > Sent: Monday, July 05, 1999 11:22 PM > To: Ladavac Marino > Cc: FreeBSD Hackers > Subject: RE: Connect and so on.. > > > > On Mon, 28 Jun 1999, Ladavac Marino wrote: > > > [ML] If I understand this correctly, only the syscall which is > > being authenticated must block during the authentication. This > makes > > the authentication atomic from the viewpoint of the syscall. The > other > > processes/kernel supported threads may proceed. Sounds like > > RAGF(spelling?) scheme you're doing there. > What you describe above is correctly expresses what I was trying to > say. > > Could you point me to more about this (RAGF) scheme? [ML] I don't know if I have spelled it out correctly, but this is the authentication scheme used on mainframes (IBM at least) where all syscalls are routed through the authentication subsystem before proceeding. However, the subsystem seems to reside in kernel, and is (possibly precompiled) table driven so that it does not cause gross inefficiency. You should ask a local mainframe guru about that. > > > > NFS daemon approach may be feasible for you, because this is > > exactly what it does. You have one central authentication daemon > which > > is blocked in kernel syscall all the time, unless some other process > > (syscall) requests the authentication. The daemon then returns to > user > > space, performs the neccessary authentication, and goes back into > kernel > > with results. This is the way I would implement it, because it > makes > > adding authentication schemes rather simple. > > > > [ML] /Marino > > > > Excellent, thank you. Although, looking through NFS code doesn't sound > like fun. Oh well, time to pay my dues. [ML] Stevens book, or Daemon book may be of some utility. > Something else I need to look into is how to effeciently pass info > back > and forth from kernel space to user space and vice-versa. (See above > for > brief background of what I'm attempting to do). For every syscall > being tracked/authenticated, a record is constructed and needs to be > sent > to the (userland) comms daemon that will send it to another server and > await a response. In the mean time, the process making the syscall is > blocked. > > Understandably this will really cut off process performance at the > knees, > but then again this a proof of concept project. [ML] Regardless of userland/kernel daemon implementation, the real bottleneck is going to be the network latency. Do not expect anything under a millisecond (compared to that, the daemon rescheduling latency of a couple of microseconds is really negligible). > One can easily imagine the processes being blocked starting to backup, > since the comm daemon is competing for processor time, even if every > entry > into the kernel by (arbitrary) tracked syscalls resets the priority of > the > comms daemon to a higher level. (I'm trying to let the daemon get as > much > of the processor as possible to complete what it is doing. It releases > it's quanta whenever it needs to wait for something). [ML] They will backup, since all of them will be waiting on I/O. But it will not be because the authentication daemon is starving them of CPU. In effect, you will have a machine with *really*really* slow syscalls. A more feasible proof of concept would be a table driven authenticator which lives in kernel and provides a syscall for table update. Then, you could call this authentication from a syscall gate glue. One could even imagine a KLD which replaces the syscall table with the authentication table and then calls the original entries. The mainframe practice shows that the auth entries remain pretty static. > The comms daemon would keep a table of records received from the > kernel to > be authenticated, and only mark it as read when it has received a > response > (while being preempted many times), so that at the next arbitrary > tracked > syscall, the kernel would look at this table, look at all the status > word > fields (one per record) and read in the (response) records, if any, > and > mark these slots as unused for later use. > > This table would have to be in userland, with a single byte status > field > for every record. The table would have fixed size records, say 1k per > entry. The seond field holds the PID and the third is free form. The > status field would act as a signal to the kernel that a response was > received. The kernel would read the status and PID and unblock the > process, and either let the syscall proceed or not. Can't use a > restart > here, because, as I understand it, this would create another syscall, > and > hence a loop. > > > Now, what I need to know is what is the best way to move this info > over > the fence, back and forth. Seems copyin() and copyout() are used > throughout kernel code. With a table with fixed size records, I would > simply need to loop through every status byte with copy*(addr + > size(record)) to find out the responses, without (*ahem*) being > interrupted. [ML] memmapping? AFAIK, the kernel has access to the mmaped areas. > Is there an easier/better/more effecient subsystem to use that I don't > know about? > > There are a lot of timing issues here, and I'm sure I've missed some. > The > comms daemon becomes a huge bottleneck for the processes that happen > to > make syscalls that are being tracked, but I don't see a better way. [ML] Don't use one. The RPC and the network latency will kill you. > One of the things that the comm daemon would do is cache a lot of > these > recurring requests so that it wouldn't have to go "outside" to respond > to > the auth request. [ML] Do you have to go outside at all is the relevant question. > Also, if someone can point me to some books/papers/soliloquies of how > to > effeciently manage a shared table, I'd be grateful. [ML] IBM probably has loads of documentation on the topic of kernel enforced syscall authentication. /Marino > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message 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?55586E7391ACD211B9730000C11002761796D2>