----- "Herbert Xu" <herb...@gondor.hengli.com.au> wrote:
> On Tue, Sep 07, 2010 at 07:27:47AM -0400, Miloslav Trmac wrote:
> > Hello,
> > ----- "Herbert Xu" <herb...@gondor.hengli.com.au> wrote:
> > > First of all let's have a quick look at what the user-space side
> > > looks like for AEAD:
> > >
> > > /* Each listen call generates one or more fds for input/output
> > > * that behave like pipes.
> > > */
> > > listen(tfmfd, 0);
> > > /* fd for encryption/decryption */
> > > opfd = accept(tfmfd, NULL, 0);
> > > /* fd for associated data */
> > > adfd = accept(tfmfd, NULL, 0);
> > If nothing else, two consecutive accept() calls with different
> semantics go rather strongly against the spirit of the socket API
> IMHO.
>
> If you have a better suggestion of obtaining multiple fds for
> multiple input streams please let us know.
- Don't use a FD for associated data that is limited to 16? bytes
- Don't use file descriptors for input data at all, if it makes the interface
so complex.
> > > /* These may also be set through sendmsg(2) cmsgs. */
> > > op = ALG_AEAD_OP_ENCRYPT;
> > > setsockopt(opfd, SOL_ALG, ALG_AEAD_OP, op, sizeof(op));
> > > setsockopt(opfd, SOL_ALG, ALG_AEAD_SET_IV, iv, ivlen);
> > So that is 8 syscalls to initialize a single AEAD operation.
>
> If this interface is fast enough for TCP, it ought to be fast
> enough for crypto.
Crypto has much smaller granularity than TCP. A single TLS handshake involves
something on the order of 20 separate crypto operations in addition to setting
up the four transforms used throughout the life of the session.
A single SHA-256 password verification is more than 5000 hash operations by
default.
> > Why use splice() at all? Simple write() gives the driver the __user
> pointers that can be used to access the underlying pages directly.
> Yanking user-space pages out from the process address space to make
> them "owned" by the crypto driver, causing more page faults when the
> process wants to reuse the buffer, does not seem like a performance
> improvement.
>
> For someone working on security I thought you would've considered
> the pitfalls of inventing yet another interface for moving data
> between the kernel/user-space.
The data will in the usual case be in user-space memory, not in file
descriptors. Existing low-level crypto libraries have no access to the file
descriptors that are used to work with the data. And even in the case of TLS
where the data does come through a file descriptor, a MAC is then computed on
it - so at most half of the (steady-state) crypto is coming through a file
descriptor.
Finally, when the application uses file descriptors, it uses them to transfer
the _encrypted_ form of the data; it keeps plaintext in memory in order to use
it. So avoiding the trip to userspace protects primarily the kind of data that
does not need protecting.
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
