Hi Michal:
On Wed, Jul 12, 2006 at 12:34:35PM +1200, Michal Ludvig wrote:
>
> the updated patch addresses almost all your comments.
Thanks a lot!
> I prefer to keep uintX_t - quick grep reveals these are not uncommon in
> the kernel. After all - linux people always rant about standards and
> uint32_t *is* a standard while u32 is not (Plus I get a nice green syntax
> highlighting for the *standard* types ;-)
Well I'd like all crypto code to be consistent in how they use these
types. Right now drivers/crypto sticks out like a sore thumb. I'll
make an exception for it this time if only because padlock-aes is already
using them.
> >> +void padlock_do_sha1(const char *in, char *out, int count)
> >> +{
> >> + /* We can't store directly to *out as it
> >> + * doesn't have to be aligned. But who cares,
> >> + * it's only a few bytes... */
> >> + char buf[128+16];
> >
> > Does it really need 128 bytes?
>
> Yes, CPU temporarily stores some data in there (IIRC in case the input
> buffer is not 16 Bytes-aligned it realigns it there for the SSE input
> microcode).
Hmm, does this mean that the input to the padlock crypto_tfm does not
need to be 16-byte aligned? If so you might as well get rid of the
alignment mask altogether since you can handle arbitrary input/output
and your ctx has no alignment requirement.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
