Hi,
On 4/13/07, Helge Hafting <[email protected]> wrote:
Francis Moreau wrote:
> So is this interpretation right ? If so wouldn't it be appropriate to
> introduce a mechanism to reserve this AES hardware for a special
> purpose (filesystem encryptions) and thus make it as fast as possible
> ?
>
Would this really help?
When reading/writing files, most of the time is i/o-wait, isn't it?
Well some systems, specially embedded ones, don't use hard drives for
mass storage purposes but rather MTD like flashes...
Reserving the device exclusively seems excessive. How about
a quick test to see if someone else have been using it since
the last time your crypto-fs used it? If nobody else used it, then
you don't need to reset they key and so on.
You would spend the same time to make the test as loading the key...
If nobody else is using the AES controller, you get the same speed
as with a reservation.
I don't think this is right. AES hardware can do a block encryption in
a very few cycles. If you copy the key or test the key to see if it
has changed as you proposed, then you basically increase the execution
time by a factor 2 or 3...
If something else is using AES then it won't be
as fast, but then the AES controller have been used for other useful
work as well. Other parts of the kernel surely won't use it just for
fun. :-)
You said it: others parts of the kernel are unlikely to use it. So why
not optimizing the common case ?
Crypto core already seems to implement a priority mechanism. But I
don't think I'm able to say "I'd like to use this algo for encrypting
filesystems. If another part of the kernel wants to use this algo then
give it the generic one". This choice seems really to depend on the
system the kernel is running.
--
Francis
-
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]
