On Fri, Oct 06, 2000 at 01:03:41PM +0000, Marc Mutz wrote: > Hi! > > We should clarify the issues: > > Must cipher implementations > > 1) expect that *in and *out may be the same buffer? Yes I think they should. I can think of some ciphers where being able to use the output buffer as temporary space might be practical. For example a bitslice implementation of 3des which wants to transpose a 64x32 bit matrix needs a temporary storage area. Creating a 256 byte array on the stack might be questionable, but the memory could also be put at the end of the key_schedule, so this could be worked around. > 2) use no additional memory for operation after set_key() is called? > I think they should not. > Point (1) is not that terribly importatnt. It's just that such things > should be defined somewhere. > Agreed. > ad (2): I'm particularly thinking of encrypting swap here. There was a > thread[1] about this about a year ago or so on lkml where it was said > that it was necessary that encrypt() and decrypt() don't use additional > memory for their run. If the kernel is low on memory and wants to swap something out, the subsystem responsible for that (including the crypto API used in the loopback system) can not allocate memory. I do not know of any cipher that does, so this should not be an issue. I think the issue of using loopback for swap lies outside of the crypto API. > However, whether this includes local variables placed on the stack I > don't know. Maybe there is a limitation on the overall size of local > variables so that it is not neccessay to claim a new page for the stack. > It does not include local variables. There is an upper bound on the stack space that can be used in the kernel for a process, and that is sizeof(PAGE)-sizeof(task_struct) on most architectures AFAIK. This memory is allocated during fork(). Exceeding that stack-space is considered a bug in the kernel, so you have to be careful about recursion and having large objects on the stack. astor -- Alexander Kjeldaas Mail: astor@xxxxxxx finger astor@xxxxxxxxxxxxxxxxx for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
