OSDev.org

I'd been planning (and writing) an "object model" for run-time linking of multiple execution contexts to use a single program, and after some browsing I came upon the attached research paper: "Protected Shared Libraries".

I have to say when reading this, it is a brilliant idea. The caller and callee contexts could be made into seperate protection domains, such that neither can access the other's data segment. Other than that there's a lot of stuff about where things are mapped, whether local copies are made or a single global copy kept... etc.

According to what I read, though, a trampoline function is used to perform the protection switches and jump/call to the actual protected shared function. The entry point to this trampoline is passed to the client code on linking, and this client code calls the function transparently, as though the trampoline didn't exist. I didn't see in the paper (direct me back if I wasn't reading thoroughly enough), but how does the trampoline know exactly which call was made and what protection domain it belongs to (so the switching can be done). You could invalidate the appropriate memory page and have the trampoline search as part of a page-fault handler through the list of protection domains and imported symbols to check for a valid reference, but the paper was claiming the protection switching was as efficient as a system call, and I don't see how an O(O(n)) search, where n is the number of protection domains and O(n) is the number of imported symbols from that domain, could do that.

I also just wanted to share a cool paper.

Crazed123 wrote: I didn't see in the paper (direct me back if I wasn't reading thoroughly enough), but how does the trampoline know exactly which call was made and what protection domain it belongs to (so the switching can be done).

I haven't yet read the paper either, but I think the only clean solution for this is to dynamically create a seperate trampoline function for each imported function at link time. As you mentioned, when multiple imported functions are linked to the same trampoline, it can not figure out which function was actually called, so we need at least a seperate link address for every imported function that can be called then.

We don't need to duplicate the whole trampoline function however - we could also use a hunk where the calling functions get linked to, which then just pushes a function id and does a 'jmp' to the real trampoline - just some thoughts.

I like this idea however - with this technique the same library could either be linked directly into the callers process (for speed), or in a seperate protection domain for more security/stability, without rewriting a piece of software. Great for dynamic deployments of applications.

cheers Joe

Actually, the way it works is that the library is ALWAYS loaded into the callers address space, and the purpose of the trampoline is to perform protection switches so that the library and calling program can't overwrite each other's data segments.

If the trampolines need to be individual... meh. This means that a system call will be needed to do the protection work for the trampoline, as there's no way for a userspace (or non-kernelspace OS service) to do that stuff for itself. I can see why they wrote the trampolines in assembler!

Why? This is actually only an issue between application and a specialized dynamic linker, AFAICS. When the caller calls a function out of the protected library which is not yet linked in, the dynamic linker will be called (still all in user space), detect which function is needed, create the hunk and finally link the calling application against it. This is also the way dynamic linking is carried out nowadays.

Of course, for switching protection domains however, it depends on the implementation of these, but this would likely cause a system call then, since it should be protected .

cheers Joe

JoeKayzA wrote: Why? This is actually only an issue between application and a specialized dynamic linker, AFAICS. When the caller calls a function out of the protected library which is not yet linked in, the dynamic linker will be called (still all in user space), detect which function is needed, create the hunk and finally link the calling application against it. This is also the way dynamic linking is carried out nowadays.

Of course, for switching protection domains however, it depends on the implementation of these, but this would likely cause a system call then, since it should be protected .

cheers Joe

The hunk calls the trampoline, which in turn must switch protection domains, or at least that's the way the paper describes it. Therefore, the protected system call is needed.

What do you mean about the linker "creating" the hunk? I can see the possibility of keeping the hunk's machine code in memory with a call number (or possibly the entry point of the real function) stored as a constant in some location that is then passed to the real trampoline to be called and simply copying that template hunk and inserting the correct entry point (and amount of parameters, etc) at known locations in said machine code. However, self-modifying code - or even anything that directly touches machine code - tends to be kludgeish and is considered horrible form.