summaryrefslogtreecommitdiff
path: root/pipermail/pycrypto/2013q4/000711.html
diff options
context:
space:
mode:
Diffstat (limited to 'pipermail/pycrypto/2013q4/000711.html')
-rw-r--r--pipermail/pycrypto/2013q4/000711.html159
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:
+&gt;<i> Hi,
+</I>&gt;<i>
+</I>&gt;<i> On 2013-10-24 09:59:12, Dwayne Litzenberger wrote:
+</I>&gt;&gt;<i> Hi Greg!
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> What version/build of GCC is this? Does &quot;setup.py test&quot; crash for you as well?
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> I'd rather figure out how to fix the problem than to start making copies of the key.
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> Greg Price &lt;<A HREF="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto">gnprice at gmail.com</A>&gt; wrote:
+</I>&gt;&gt;&gt;<i> I get the following crash in a PyCrypto built from the current master,
+</I>&gt;&gt;&gt;<i> af058ee (aka v2.6.1-136-gaf058ee):
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;&gt;&gt;&gt;<i> import Crypto.Random
+</I>&gt;&gt;&gt;&gt;&gt;&gt;<i> Crypto.Random.new().read(1)
+</I>&gt;&gt;&gt;<i> Segmentation fault (core dumped)
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> This is on i686. I compiled with GCC 4.6.3 (or &quot;Ubuntu/Linaro
+</I>&gt;&gt;&gt;<i> 4.6.3-1ubuntu5&quot;.)
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> GDB shows the crash is here:
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> Program received signal SIGSEGV, Segmentation fault.
+</I>&gt;&gt;&gt;<i> aes_key_setup_enc (keylen=32, cipherKey=
+</I>&gt;&gt;&gt;<i> 0x841b1bc
+</I>&gt;&gt;&gt;<i> &quot;L\fB2\244\225\235\206^\242\305\305b\201\200\335&#326;{d\240\343\262;m\361\243\276u~\337&amp;&quot;,
+</I>&gt;&gt;&gt;<i> rk=
+</I>&gt;&gt;&gt;<i> 0x84900a8) at src/AESNI.c:122
+</I>&gt;&gt;&gt;<i> 122 rk[0] = _mm_loadu_si128((const __m128i*) cipherKey);
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> at which the instruction is
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> (gdb) x/i $pc
+</I>&gt;&gt;&gt;<i> =&gt; 0xb78f2600 &lt;ALGnew+2160&gt;: movdqa %xmm0,0x40(%esi)
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> This is an aligned store. The documentation of MOVDQA says it should
+</I>&gt;&gt;&gt;<i> be 16-byte aligned. The value of rk (aka %esi + 0x40) is only 8-byte
+</I>&gt;&gt;&gt;<i> aligned:
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> (gdb) p rk
+</I>&gt;&gt;&gt;<i> $5 = (__m128i *) 0x84900a8
+</I>&gt;&gt;&gt;<i> (gdb) p/x $esi
+</I>&gt;&gt;&gt;<i> $9 = 0x8490068
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> It's not clear to me why GCC generated an aligned instruction here --
+</I>&gt;&gt;&gt;<i> in fact, the definition of _mm_loadu_si128 in my emmintrin.h appears
+</I>&gt;&gt;&gt;<i> to be
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> extern __inline __m128i __attribute__((__gnu_inline__,
+</I>&gt;&gt;&gt;<i> __always_inline__, __artificial__))
+</I>&gt;&gt;&gt;<i> _mm_loadu_si128 (__m128i const *__P)
+</I>&gt;&gt;&gt;<i> {
+</I>&gt;&gt;&gt;<i> return (__m128i) __builtin_ia32_loaddqu ((char const *)__P);
+</I>&gt;&gt;&gt;<i> }
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> and the name of that builtin sure sounds more like MOVDQU than MOVDQA.
+</I>&gt;&gt;&gt;<i> Perhaps GCC somehow decides that it can prove the pointer is aligned
+</I>&gt;&gt;&gt;<i> here.
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> I don't know why GCC makes this mistake, or (since it's never the
+</I>&gt;&gt;&gt;<i> compiler's fault) which code is lying to it about something being
+</I>&gt;&gt;&gt;<i> aligned. Anyone know how to investigate this kind of question?
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> A workaround would be to make sure that the cipherKey argument to
+</I>&gt;&gt;&gt;<i> aes_key_setup_enc() in src/AESNI.c is always 16-byte aligned. At
+</I>&gt;&gt;&gt;<i> present, that argument comes straight from the first Python-level
+</I>&gt;&gt;&gt;<i> argument to _AESNI.new(); see the PyArg_ParseTupleAndKeywords() call
+</I>&gt;&gt;&gt;<i> in src/block_template.c. I guess to implement this workaround we'd
+</I>&gt;&gt;&gt;<i> copy the key to a new, aligned buffer if it's not aligned.
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> I can send a patch for that workaround if it seems like the best
+</I>&gt;&gt;&gt;<i> approach. Happy to hear alternatives, and of course it'd be most
+</I>&gt;&gt;&gt;<i> satisfying if we can understand why the compiler is emitting this
+</I>&gt;&gt;&gt;<i> output in the first place.
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> Greg
+</I>&gt;<i> I debugged this for a while and the problem is not _mm_loadu_si128.
+</I>&gt;<i> That's fine. It generates the correct movdqu instruction for that. The
+</I>&gt;<i> problem is the rk[0] = ... part. On amd64, ek and dk from block_state
+</I>&gt;<i> get aligned at 16 byte boundaries and everything works out properly.
+</I>&gt;<i> However, on i386 this does not appear to be true.
+</I>&gt;<i>
+</I>&gt;<i> I have some ideas how to fix it and will hopefully come up with a patch
+</I>&gt;<i> next week.
+</I>&gt;<i>
+</I>&gt;<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>