Hi.
On Thu, Oct 04, 2007 at 06:04:14PM +0800, Herbert Xu (herbert@xxxxxxxxxxxxxxxxxxx) wrote:
> But we still need to fix the partial block case.
Just a note: blkcipher_walk_* was not designed for async hardware, since
there is no way to know in advance how many pages will be required for
single request. For example DES second multipage test says it has three
pages, but actually it will have 4 requests and thus 4 DMA
descriptors in HIFN, but when new interrupt says about completed
descriptor, it can not know if it is the last descriptor or not, so that
callback for request should or should not be called. I've fixed that
with additional atomic ops...
Given that, new driver passes all except one DES tcrypt tests, it fails
on cbc multipage encryption (decryption works ok), which provides 13
bytes of misaligned data.
Here is a code snippet for current driver (error handling was ommitted):
blkcipher_walk_init(&walk, req->dst, req->src, nbytes);
err = blkcipher_walk_phys(&desc, &walk);
while ((nbytes = walk.nbytes)) {
spage = walk.src.phys.page;
soff = walk.src.phys.offset;
dpage = walk.dst.phys.page;
doff = walk.dst.phys.offset;
ctx->iv = walk.iv;
++i;
spin_lock_irqsave(&dev->lock, flags);
err = hifn_setup_dma(dev, spage, soff, dpage, doff, nbytes,
req, ctx);
spin_unlock_irqrestore(&dev->lock, flags);
nbytes &= blocksize - 1;
err = blkcipher_walk_done(&desc, &walk, nbytes);
}
And debug output:
Testing cbc(des) encryption across pages (chunking)
test 1 (64 bit key):
hifn0: spage: ffff81003fe8f1e8, soffset: 0, dpage: ffff81003fe8f1e8, doffset: 0, nbytes: 13, priv: ffff81003dc74138, ctx: ffff81003a9d7210.
hifn0: spage: ffff81003fe8f1e8, soffset: 8, dpage: ffff81003fe8f1e8, doffset: 0, nbytes: 8, priv: ffff81003dc74138, ctx: ffff81003a9d7210.
hifn0: spage: ffff81003fe8f1e8, soffset: 0, dpage: ffff81003fe8f1e8, doffset: 0, nbytes: 8, priv: ffff81003dc74138, ctx: ffff81003a9d7210.
page 0
ccd173ffab2039f47f81654121
fail
page 1
dbd4cf266da007deeadb88
fail
And actually there is a huge problem with blkcipher_walk* interface - it
always provides the same destination buffer, so it is possible to
overwrite it if second crypto block was encrypted before the first one.
It just can not be used in asynchronous hardware, so I will create
soemthing new for HIFN driver specially.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
