necessary keyring operations for efficiently performing
zero-copy cryptoapi calls using those key types.
Cheers,
Kyle Moffett
--
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
On Mon, Sep 6, 2010 at 15:13, Nikos Mavrogiannopoulos
n.mavrogiannopou...@gmail.com wrote:
On 09/06/2010 08:00 PM, Kyle Moffett wrote:
The kernel keyring service is basically a system-wide data storage
service. /dev/crypto needs a quick way to refer to short-lived,
usually process-local
-provided input and output buffers. Again,
you'd need new LSM hooks, etc. These are very obviously extensible to
other applications.
It's getting a bit late here, so I apologize if anything I've written
above makes particularly little sense, but hopefully I've gotten the
gist across.
Cheers,
Kyle
used for crypto keys for
NFSv4, AFS, etc. Can't you just add a bunch of cryptoapi key types to
that API instead?
David Howells added to CC, since I believe he wrote most of that code initially.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body
like it if there were more
intensive in-kernel POST tests that could be enabled by a kernel
parameter or something for high-reliability embedded devices.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
obfuscation. On
the other hand if it *is* performance-significant, it should be
redesigned to be able to guarantee that the space is available when it
is needed.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord
