Hi Folks, I think I may have figured out part of the problem with using pkcs11-spy with static linking. It appears that when statically linking against pkcs11-spy.so (as is described in the original message below), the ldsym command returns a pointer to the C_GetFunctionList function within pkcs11-spy.so itself instead of the function with the same name in the library that pkcs11-spy is loading. This is probably because there is a name collision and the linker just picks the symbol that's already loaded.
I was able to work around this issue by using the dlmopen command instead of lt_dlopen to load the library. Here's roughly the change to C_LoadModule (at src/pkcs11/libpkcs11.c): line 43: mod->handle = lt_dlopen(mspec); change to: mod->handle = dlmopen(LM_ID_NEWLM, mspec, RTLD_LAZY); (and change the rest of the function to use dlsym instead of lt_dlsym, etc) By using dlmopen with the LM_ID_NEWLM, it tells the linker to start a new link map for the newly loaded library. This seems to solve the problem. Unfortunately, ldmopen is not a libtool command, so using ldmopen may not be particularly portable. Does anyone know of an equivalent command or approach using libtool? Thanks! -Matt On 11/05/09 11:23, Martin Paljak wrote: > Hi Matt, > > You're supposed to dlopen() the PKCS#11 library and then use the > C_Initialize symbol, not link against the module itself. pkcs11-spy.so > is a special module, that it passes all calls through to another > module and logs the communication. It is not useful by itself. > > Once you have built your application, you can use pkcs11-spy the way > described here: http://www.opensc-project.org/opensc/wiki/UsingOpensc > To get some glues on how to work with PKCS#11, you can check out > pkcs11-helper source: http://www.opensc-project.org/pkcs11-helper/ > > Martin > > On 05.11.2009, at 19:46, Matthew Ball wrote: > >> Hi OpenSC developers, >> >> I'm new to OpenSC, and am trying to get pkcs11-spy working as an >> interface to the Solaris Cryptographic Framework (SCF), but haven't had >> any luck so far. I'd appreciate any pointers! >> >> As background, I'm running on Solaris 10 sparc with OpenSC 0.11.11, and >> am simply trying to call the C_Initialize function, which I'm hoping >> will then connect to the SCF C_Initialize function and give me some >> basic feedback. Here's my program (called pktest.c): >> >> #include <security/cryptoki.h> >> int main() { >> CK_C_INITIALIZE_ARGS stInitializeArgs; >> stInitializeArgs.CreateMutex = NULL_PTR; >> stInitializeArgs.DestroyMutex = NULL_PTR; >> stInitializeArgs.LockMutex = NULL_PTR; >> stInitializeArgs.UnlockMutex = NULL_PTR; >> stInitializeArgs.pReserved = NULL_PTR; >> stInitializeArgs.flags = CKF_OS_LOCKING_OK; >> C_Initialize( &stInitializeArgs ); >> return 0; >> } >> >> I attempted to link this against pkcs11-spy.so. The first problem I ran >> into was that gcc (version 3.4.5) couldn't even find the library until I >> changed the name to libpkcs11-spy.so. After that, I was able to compile >> like this: >> >> # cd [to the directory with libpkcs11-spy.so] >> # cp pkcs11-spy.so libpkcs11-spy.so >> # gcc -Wall pktest.c -o pktest -L. -lpkcs11-spy >> >> That produced the executable pktest. Here's how I ran it (with BASH): >> >> # export PKCS11SPY="/usr/lib/libpkcs11.so" >> # export LD_LIBRARY_PATH=. >> # ./pktest >> >> After running this, I got an infinite recursive loop that eventually >> caused a core dump. In looking at pkcs11-spy.c, this behavior seems >> like what you'd expect: In init_spy, you get "pkcs11_spy->C_Initialize >> = C_Initialize", and in C_Initialize, you get "rv = >> po->C_Initialize(pInitArgs)", which seems to just call itself again (and >> is exactly what happened). >> >> Clearly, I'm missing a very big-picture thing with pkcs11-spy, but >> unfortunately I haven't been able to find any documentation to give an >> example of correct usage. Can anyone help? How is pkcs11-spy supposed >> to be included? >> >> -- >> Thanks! >> Matt Ball, Staff Engineer, Sun Microsystems, Inc. >> 500 Eldorado Blvd, Bldg 5, Broomfield, CO 80021 >> Office: 303-272-7580 Cell: 303-717-2717 Fax: 303-272-3023 >> >> _______________________________________________ >> opensc-devel mailing list >> [email protected] >> http://www.opensc-project.org/mailman/listinfo/opensc-devel > -- Thanks! Matt Ball, Staff Engineer, Sun Microsystems, Inc. 500 Eldorado Blvd, Bldg 5, Broomfield, CO 80021 Office: 303-272-7580 Cell: 303-717-2717 Fax: 303-272-3023 _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
