diff options
Diffstat (limited to 'pipermail/pycrypto/2013q4/000711.html')
-rw-r--r-- | pipermail/pycrypto/2013q4/000711.html | 159 |
1 files changed, 159 insertions, 0 deletions
diff --git a/pipermail/pycrypto/2013q4/000711.html b/pipermail/pycrypto/2013q4/000711.html new file mode 100644 index 0000000..c05f3cf --- /dev/null +++ b/pipermail/pycrypto/2013q4/000711.html @@ -0,0 +1,159 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<HTML> + <HEAD> + <TITLE> [pycrypto] Crypto.Random crashes due to unaligned access + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:pycrypto%40lists.dlitz.net?Subject=Re%3A%20%5Bpycrypto%5D%20Crypto.Random%20crashes%20due%20to%20unaligned%20access&In-Reply-To=%3C526D98C1.6090707%40gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <style type="text/css"> + pre { + white-space: pre-wrap; /* css-2.1, curent FF, Opera, Safari */ + } + </style> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="000710.html"> + <LINK REL="Next" HREF="000714.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[pycrypto] Crypto.Random crashes due to unaligned access</H1> + <B>Andrew Cooper</B> + <A HREF="mailto:pycrypto%40lists.dlitz.net?Subject=Re%3A%20%5Bpycrypto%5D%20Crypto.Random%20crashes%20due%20to%20unaligned%20access&In-Reply-To=%3C526D98C1.6090707%40gmail.com%3E" + TITLE="[pycrypto] Crypto.Random crashes due to unaligned access">andyhhp at gmail.com + </A><BR> + <I>Sun Oct 27 15:50:41 PDT 2013</I> + <P><UL> + <LI>Previous message: <A HREF="000710.html">[pycrypto] Crypto.Random crashes due to unaligned access +</A></li> + <LI>Next message: <A HREF="000714.html">[pycrypto] Crypto.Random crashes due to unaligned access +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#711">[ date ]</a> + <a href="thread.html#711">[ thread ]</a> + <a href="subject.html#711">[ subject ]</a> + <a href="author.html#711">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On 27/10/2013 22:07, Sebastian Ramacher wrote: +><i> Hi, +</I>><i> +</I>><i> On 2013-10-24 09:59:12, Dwayne Litzenberger wrote: +</I>>><i> Hi Greg! +</I>>><i> +</I>>><i> What version/build of GCC is this? Does "setup.py test" crash for you as well? +</I>>><i> +</I>>><i> I'd rather figure out how to fix the problem than to start making copies of the key. +</I>>><i> +</I>>><i> Greg Price <<A HREF="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto">gnprice at gmail.com</A>> wrote: +</I>>>><i> I get the following crash in a PyCrypto built from the current master, +</I>>>><i> af058ee (aka v2.6.1-136-gaf058ee): +</I>>>><i> +</I>>>>>>><i> import Crypto.Random +</I>>>>>>><i> Crypto.Random.new().read(1) +</I>>>><i> Segmentation fault (core dumped) +</I>>>><i> +</I>>>><i> This is on i686. I compiled with GCC 4.6.3 (or "Ubuntu/Linaro +</I>>>><i> 4.6.3-1ubuntu5".) +</I>>>><i> +</I>>>><i> GDB shows the crash is here: +</I>>>><i> +</I>>>><i> Program received signal SIGSEGV, Segmentation fault. +</I>>>><i> aes_key_setup_enc (keylen=32, cipherKey= +</I>>>><i> 0x841b1bc +</I>>>><i> "L\fB2\244\225\235\206^\242\305\305b\201\200\335ņ{d\240\343\262;m\361\243\276u~\337&", +</I>>>><i> rk= +</I>>>><i> 0x84900a8) at src/AESNI.c:122 +</I>>>><i> 122 rk[0] = _mm_loadu_si128((const __m128i*) cipherKey); +</I>>>><i> +</I>>>><i> at which the instruction is +</I>>>><i> +</I>>>><i> (gdb) x/i $pc +</I>>>><i> => 0xb78f2600 <ALGnew+2160>: movdqa %xmm0,0x40(%esi) +</I>>>><i> +</I>>>><i> This is an aligned store. The documentation of MOVDQA says it should +</I>>>><i> be 16-byte aligned. The value of rk (aka %esi + 0x40) is only 8-byte +</I>>>><i> aligned: +</I>>>><i> +</I>>>><i> (gdb) p rk +</I>>>><i> $5 = (__m128i *) 0x84900a8 +</I>>>><i> (gdb) p/x $esi +</I>>>><i> $9 = 0x8490068 +</I>>>><i> +</I>>>><i> It's not clear to me why GCC generated an aligned instruction here -- +</I>>>><i> in fact, the definition of _mm_loadu_si128 in my emmintrin.h appears +</I>>>><i> to be +</I>>>><i> +</I>>>><i> extern __inline __m128i __attribute__((__gnu_inline__, +</I>>>><i> __always_inline__, __artificial__)) +</I>>>><i> _mm_loadu_si128 (__m128i const *__P) +</I>>>><i> { +</I>>>><i> return (__m128i) __builtin_ia32_loaddqu ((char const *)__P); +</I>>>><i> } +</I>>>><i> +</I>>>><i> and the name of that builtin sure sounds more like MOVDQU than MOVDQA. +</I>>>><i> Perhaps GCC somehow decides that it can prove the pointer is aligned +</I>>>><i> here. +</I>>>><i> +</I>>>><i> I don't know why GCC makes this mistake, or (since it's never the +</I>>>><i> compiler's fault) which code is lying to it about something being +</I>>>><i> aligned. Anyone know how to investigate this kind of question? +</I>>>><i> +</I>>>><i> A workaround would be to make sure that the cipherKey argument to +</I>>>><i> aes_key_setup_enc() in src/AESNI.c is always 16-byte aligned. At +</I>>>><i> present, that argument comes straight from the first Python-level +</I>>>><i> argument to _AESNI.new(); see the PyArg_ParseTupleAndKeywords() call +</I>>>><i> in src/block_template.c. I guess to implement this workaround we'd +</I>>>><i> copy the key to a new, aligned buffer if it's not aligned. +</I>>>><i> +</I>>>><i> I can send a patch for that workaround if it seems like the best +</I>>>><i> approach. Happy to hear alternatives, and of course it'd be most +</I>>>><i> satisfying if we can understand why the compiler is emitting this +</I>>>><i> output in the first place. +</I>>>><i> +</I>>>><i> Greg +</I>><i> I debugged this for a while and the problem is not _mm_loadu_si128. +</I>><i> That's fine. It generates the correct movdqu instruction for that. The +</I>><i> problem is the rk[0] = ... part. On amd64, ek and dk from block_state +</I>><i> get aligned at 16 byte boundaries and everything works out properly. +</I>><i> However, on i386 this does not appear to be true. +</I>><i> +</I>><i> I have some ideas how to fix it and will hopefully come up with a patch +</I>><i> next week. +</I>><i> +</I>><i> Regards +</I> +The alignment might quite easily be chance, or because of the Red Zone +mandated for 64bit, which causes stack frame alignment on 128byte +boundaries. + +I accept your argument about the assignment being the problem, but +still, it is invalid for gcc to be emitting a movdqa instruction in this +case; the target address is demonstrably not 16 byte aligned. + +~Andrew +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000710.html">[pycrypto] Crypto.Random crashes due to unaligned access +</A></li> + <LI>Next message: <A HREF="000714.html">[pycrypto] Crypto.Random crashes due to unaligned access +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#711">[ date ]</a> + <a href="thread.html#711">[ thread ]</a> + <a href="subject.html#711">[ subject ]</a> + <a href="author.html#711">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto">More information about the pycrypto +mailing list</a><br> +</body></html> |