summaryrefslogtreecommitdiff
path: root/pipermail/pycrypto/2013q4/000709.html
diff options
context:
space:
mode:
Diffstat (limited to 'pipermail/pycrypto/2013q4/000709.html')
-rw-r--r--pipermail/pycrypto/2013q4/000709.html157
1 files changed, 157 insertions, 0 deletions
diff --git a/pipermail/pycrypto/2013q4/000709.html b/pipermail/pycrypto/2013q4/000709.html
new file mode 100644
index 0000000..6857ba3
--- /dev/null
+++ b/pipermail/pycrypto/2013q4/000709.html
@@ -0,0 +1,157 @@
+<!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=%3C20131027220710.GB11300%40ramacher.at%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="000708.html">
+ <LINK REL="Next" HREF="000710.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[pycrypto] Crypto.Random crashes due to unaligned access</H1>
+ <B>Sebastian Ramacher</B>
+ <A HREF="mailto:pycrypto%40lists.dlitz.net?Subject=Re%3A%20%5Bpycrypto%5D%20Crypto.Random%20crashes%20due%20to%20unaligned%20access&In-Reply-To=%3C20131027220710.GB11300%40ramacher.at%3E"
+ TITLE="[pycrypto] Crypto.Random crashes due to unaligned access">sebastian+lists at ramacher.at
+ </A><BR>
+ <I>Sun Oct 27 15:07:10 PDT 2013</I>
+ <P><UL>
+ <LI>Previous message: <A HREF="000708.html">[pycrypto] Crypto.Random crashes due to unaligned access
+</A></li>
+ <LI>Next message: <A HREF="000710.html">[pycrypto] Crypto.Random crashes due to unaligned access
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#709">[ date ]</a>
+ <a href="thread.html#709">[ thread ]</a>
+ <a href="subject.html#709">[ subject ]</a>
+ <a href="author.html#709">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>Hi,
+
+On 2013-10-24 09:59:12, Dwayne Litzenberger wrote:
+&gt;<i> Hi Greg!
+</I>&gt;<i>
+</I>&gt;<i> What version/build of GCC is this? Does &quot;setup.py test&quot; crash for you as well?
+</I>&gt;<i>
+</I>&gt;<i> I'd rather figure out how to fix the problem than to start making copies of the key.
+</I>&gt;<i>
+</I>&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;<i> &gt;I get the following crash in a PyCrypto built from the current master,
+</I>&gt;<i> &gt;af058ee (aka v2.6.1-136-gaf058ee):
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;&gt;&gt;&gt; import Crypto.Random
+</I>&gt;<i> &gt;&gt;&gt;&gt; Crypto.Random.new().read(1)
+</I>&gt;<i> &gt;Segmentation fault (core dumped)
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;This is on i686. I compiled with GCC 4.6.3 (or &quot;Ubuntu/Linaro
+</I>&gt;<i> &gt;4.6.3-1ubuntu5&quot;.)
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;GDB shows the crash is here:
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;Program received signal SIGSEGV, Segmentation fault.
+</I>&gt;<i> &gt;aes_key_setup_enc (keylen=32, cipherKey=
+</I>&gt;<i> &gt;0x841b1bc
+</I>&gt;<i> &gt;&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;<i> &gt;rk=
+</I>&gt;<i> &gt; 0x84900a8) at src/AESNI.c:122
+</I>&gt;<i> &gt;122 rk[0] = _mm_loadu_si128((const __m128i*) cipherKey);
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;at which the instruction is
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;(gdb) x/i $pc
+</I>&gt;<i> &gt;=&gt; 0xb78f2600 &lt;ALGnew+2160&gt;: movdqa %xmm0,0x40(%esi)
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;This is an aligned store. The documentation of MOVDQA says it should
+</I>&gt;<i> &gt;be 16-byte aligned. The value of rk (aka %esi + 0x40) is only 8-byte
+</I>&gt;<i> &gt;aligned:
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;(gdb) p rk
+</I>&gt;<i> &gt;$5 = (__m128i *) 0x84900a8
+</I>&gt;<i> &gt;(gdb) p/x $esi
+</I>&gt;<i> &gt;$9 = 0x8490068
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;It's not clear to me why GCC generated an aligned instruction here --
+</I>&gt;<i> &gt;in fact, the definition of _mm_loadu_si128 in my emmintrin.h appears
+</I>&gt;<i> &gt;to be
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;extern __inline __m128i __attribute__((__gnu_inline__,
+</I>&gt;<i> &gt;__always_inline__, __artificial__))
+</I>&gt;<i> &gt;_mm_loadu_si128 (__m128i const *__P)
+</I>&gt;<i> &gt;{
+</I>&gt;<i> &gt; return (__m128i) __builtin_ia32_loaddqu ((char const *)__P);
+</I>&gt;<i> &gt;}
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;and the name of that builtin sure sounds more like MOVDQU than MOVDQA.
+</I>&gt;<i> &gt; Perhaps GCC somehow decides that it can prove the pointer is aligned
+</I>&gt;<i> &gt;here.
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;I don't know why GCC makes this mistake, or (since it's never the
+</I>&gt;<i> &gt;compiler's fault) which code is lying to it about something being
+</I>&gt;<i> &gt;aligned. Anyone know how to investigate this kind of question?
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;A workaround would be to make sure that the cipherKey argument to
+</I>&gt;<i> &gt;aes_key_setup_enc() in src/AESNI.c is always 16-byte aligned. At
+</I>&gt;<i> &gt;present, that argument comes straight from the first Python-level
+</I>&gt;<i> &gt;argument to _AESNI.new(); see the PyArg_ParseTupleAndKeywords() call
+</I>&gt;<i> &gt;in src/block_template.c. I guess to implement this workaround we'd
+</I>&gt;<i> &gt;copy the key to a new, aligned buffer if it's not aligned.
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;I can send a patch for that workaround if it seems like the best
+</I>&gt;<i> &gt;approach. Happy to hear alternatives, and of course it'd be most
+</I>&gt;<i> &gt;satisfying if we can understand why the compiler is emitting this
+</I>&gt;<i> &gt;output in the first place.
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt;Greg
+</I>
+I debugged this for a while and the problem is not _mm_loadu_si128.
+That's fine. It generates the correct movdqu instruction for that. The
+problem is the rk[0] = ... part. On amd64, ek and dk from block_state
+get aligned at 16 byte boundaries and everything works out properly.
+However, on i386 this does not appear to be true.
+
+I have some ideas how to fix it and will hopefully come up with a patch
+next week.
+
+Regards
+--
+Sebastian Ramacher
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: signature.asc
+Type: application/pgp-signature
+Size: 836 bytes
+Desc: Digital signature
+URL: &lt;<A HREF="http://lists.dlitz.net/pipermail/pycrypto/attachments/20131027/2bb05078/attachment.sig">http://lists.dlitz.net/pipermail/pycrypto/attachments/20131027/2bb05078/attachment.sig</A>&gt;
+</PRE>
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI>Previous message: <A HREF="000708.html">[pycrypto] Crypto.Random crashes due to unaligned access
+</A></li>
+ <LI>Next message: <A HREF="000710.html">[pycrypto] Crypto.Random crashes due to unaligned access
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#709">[ date ]</a>
+ <a href="thread.html#709">[ thread ]</a>
+ <a href="subject.html#709">[ subject ]</a>
+ <a href="author.html#709">[ 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>