----- "Miloslav Trmac" <m...@redhat.com> wrote:
> ----- "Neil Horman" <nhor...@tuxdriver.com> wrote:
> > Likewise, matching requests and responses in a multi-threaded program is
> > also an
> > already solved issue in multiple ways. The use of multiple sockets, in a 1
> > per
> > thread fashion is the most obvious.
> That would give each thread a separate namespace of keys/sessions,
> rather strange and a problem to fit into existing applications.
Hm, that's actually not necessarily true, depending on the specifics, but it
does bring up the more general problem of "crypto contexts" and their lifetimes.
The proposed patch treats each open("/dev/crypto") as a new context within
which keys and sessions are allocated. Only processes having this FD can
access the keys and namespaces, and transferring the FD also transfers access
to the crypto data. On last close() the data is automatically freed.
With netlink we could associate the data with the caller's netlink address, but
we don't get any notification that the caller has exited. The other option is
to have only one, per-process, context, which again runs into the problem that
netlink message handling is, at least semantically, separate from the calling
process.
Mirek
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
