Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Oct 1997 17:57:04 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        njs3@doc.ic.ac.uk (Niall Smart)
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Loading code from userland
Message-ID:  <199710281757.KAA28850@usr06.primenet.com>
In-Reply-To: <E0xQ8rs-00007f-00@oak67.doc.ic.ac.uk> from "Niall Smart" at Oct 28, 97 10:27:23 am

next in thread | previous in thread | raw e-mail | index | archive | help
> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710281757.KAA28850>