Nelson Bolyard wrote, On 06/22/2010 07:49 AM:
On 2010-06-21 17:57 PDT, Brian Smith wrote:
From arcfour.c:
http://mxr.mozilla.org/mozilla/source/security/nss/lib/freebl/arcfour.c#390
My guess is that valgrind is considering malloc(5) to allocate 5 bytes, when
really it allocates 8 bytes at least (because of alignment).
I assume that the "correct" behaviour I see for RC4 up to 8 bytes is the
"if (inputLen < 2*WORDSIZE)" case. I wonder why small sizes is such a
special case - they could also be considered cases of the general case
of leading unaligned bytes + (zero) aligned words + trailing unaligned
bytes. Wouldn't the bulk word processing (sic!) that really matters
perform even better if it didn't have to consider masks because leading
and trailing bytes had been handled byte by byte? Perhaps we can get
both "correct" behaviour and better performance?
Never mind - you are the experts. I just want to use NSS and valgrind
correctly.
Thanks for the answers. For some reason googling for "nss valgrind rc4"
and other relevant keywords did not give me these hints.
I presume that there must be some incantation that one can give to valgrind
that will force it to shut up about arcfour. Maybe there's something I
could put right into the source code to silence valgrind about it?
Valgrind can be run with "--suppressions=nss.sup" where nss.sup contains:
{
nss-rc4
Memcheck:Addr4
fun:rc4_wordconv
fun:RC4_Encrypt
fun:NSC_EncryptUpdate
fun:PK11_CipherOp
}
AFAIK applications _can_ be compiled with instructions for valgrind, but
I don't think that is an option.
If someone would be so kind as to supply it here, I would add it to the
comment cited above (which I wrote 7 years ago, without much affect, sadly.)
See also
https://bugzilla.mozilla.org/show_bug.cgi?id=341127
https://bugzilla.mozilla.org/show_bug.cgi?id=387577
https://bugzilla.mozilla.org/show_bug.cgi?id=451754
I think the comment in the source code is fine. Perhaps it could be made
more explicit that the "problem" is that it accesses memory outside the
specified buffer - and that _that_ memory might be uninitialized.
As user (not developer) of NSS I would however like to see it mentioned
in the header file - that would have helped me. Please consider
something like the attached patch.
By the way: I can imagine that the current approach can cause real
problems if the memory next to the buffers concurrently is modified from
other threads. Perhaps that should be mentioned too.
/Mads
--- /usr/include/nss3/pk11pub.h 2009-09-19 02:02:59.000000000 +0200
+++ pk11pub.h 2010-06-23 00:14:00.000000000 +0200
@@ -681,6 +681,10 @@
/*
* The output buffer 'out' must be big enough to hold the output of
* the hash algorithm 'hashAlg'.
+ * Note that some algorithms access the buffers as words and thus might read
+ * and write (but not alter) memore before or after the specified buffers. That
+ * might cause warnings from memory access debuggers unless memory allocation
+ * for buffers is rounded up and down to word boundaries.
*/
SECStatus PK11_HashBuf(SECOidTag hashAlg, unsigned char *out, unsigned char
*in,
PRInt32 len);
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
