From owner-freebsd-hackers Tue Oct 28 09:57:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA07881 for hackers-outgoing; Tue, 28 Oct 1997 09:57:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA07870 for ; Tue, 28 Oct 1997 09:57:19 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id KAA21158; Tue, 28 Oct 1997 10:57:12 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd021151; Tue Oct 28 10:57:09 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id KAA28850; Tue, 28 Oct 1997 10:57:04 -0700 (MST) From: Terry Lambert Message-Id: <199710281757.KAA28850@usr06.primenet.com> Subject: Re: Loading code from userland To: njs3@doc.ic.ac.uk (Niall Smart) Date: Tue, 28 Oct 1997 17:57:04 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Niall Smart" at Oct 28, 97 10:27:23 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I was wondering how I can load code from user-land into the kernel in > a manner similar to dlopen() and dlsym()? For example, if I had an > encrypted file system then I might want to allow the user to load their > own encryption module which defined a set of operations such as > initialise(), encrypt_block(), decrypt_block() etc. You should procedurally abstract the interface so that the user code is run in user space, not kernel space, unless you believe you can trust all your users to not rewrite the "uid" portion of their own proc struct. The BSD way to do this is generally called "portals". The FS layer would open a portal to a user program, and (basically) read and write pipe data according to a protocol. A better idea would be to have the system provide methods. All a user needs is a one-way hash that blows his data, instead of a reversible encryption. The issue is the keys, not the algorithm, in any case, so there is not any real drawback to having a pallete of algorithms to choose from. One issue here is that the encryption keys should be treated as credentials. The problem with that is that there is no session manager to act as a credential holder on the user's behalf, so you would have to figure out a way that the kernel could as the user a question, such as "what's your key?". That means "session manager" or "mount time command line argument". > I think this can be achieved using lkm's - is this correct? I was > thinking that the module would call a function in the main body of the > encrypted file system code to pass it an array of entry points into > the module. It could be achieved this way, but it would be a mistake to do it. FreeBSD does not support the concept of more than two protection domains, mostly because it aspires to run on more hardware than just VAX and Intel processors, and some of that hardware only supports two domain identities. > Finally, can lkm's be compiled completely separately from the kernel or > are they specific to a particular kernel configuration? LKM's are particular to a given set of kernel internals. Which set depends on the kernel interfaces consumed by the LKM. The link is done at load time, so so long as there are no structural changes to whatever the LKM references, the LKM doesn't need to be recompiled. In practice, the LKM will need to be frequently recompiled. A procedurally abstract interface does not depend on structure references, so this is another reason to use one instead of LKM's (at least until there is a formal DDI/DKI specification). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.