> > It seems trivial to keep the last key you were given and do a quick
> > memcmp in your setkey method to see if it's different from the last
> > key you pushed to hardware, and set a flag if it is. Then only do
> > your set_key() if you have a new key to pass to hardware.
> >
> > I'm assuming the expense is in the aes_write() calls, and you could
> > avoid them if you know you're not writing something new.
> that's a wrong assumption. aes_write()/aes_read() are both used to
> access to the controller and are slow (no cache involved).
Sorry, I wasn't clear. I meant that the hardware access is what is
slow, and that anything you do on the CPU is relatively cheap compared
to that.
So my suggestion is just to keep a cache (in CPU memory) of what you
have already loaded into the HW, and before reloading the HW just
check the cache and don't do the actual HW access if you're not going
to change the HW contents. So you avoid any extra aes_write and
aes_read calls in the cache hit case.
This would have the advantage of making anything that does lots of
bulk encryption fast without special casing ecryptfs.
- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
