Re: Some compatibility issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 6/22/07, Robert Relyea <rrelyea@xxxxxxxxxx> wrote:
This is not allowed by the spec. C_Initialize() fork() semantic is
specifically specified as unpredictable. You need to finalize before the

Please read the documentation before you so quickly response.


6.5.1  Applications and processes

In general, on most platforms, the previous paragraph means that an
application consists of a single process.

Consider a UNIX process P which becomes a Cryptoki application by
calling C_Initialize,
and then uses the fork() system call to create a child process C.
Since P and C have
separate address spaces (or will when one of them performs a write
operation, if the operating
system follows the copy-on-write paradigm), they are not part of the
same application.
Therefore, if C needs to use Cryptoki, it needs to perform its own
C_Initialize call.
Furthermore, if C needs to be logged into the token(s) that it will
access via Cryptoki, it needs
to log into them even if P already logged in, since P and C are
completely separate
In this particular case (when C is the child of a process which is a
Cryptoki application), the
behavior of Cryptoki is undefined if C tries to use it without its own
C_Initialize call. Ideally,
such an attempt would return the value CKR_CRYPTOKI_NOT_INITIALIZED; however,
because of the way fork() works, insisting on this return value might
have a bad impact on


Please fix your code to match the required behavior.

Best Regards,
Alon Bar-Lev.

Coolkey-devel mailing list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Women]

  Powered by Linux