So good. So very good. http://pdos.csail.mit.edu/papers/stack:sosp13.pdf Or - a different reason to compile everything yourself. SlowOS plz. -Travis On Tue, Jul 22, 2014 at 6:58 PM, coderman wrote:

---------- Forwarded message ---------- From: Zooko Wilcox-OHearn Date: Tue, Jul 22, 2014 at 12:23 PM Subject: a catalog of bugs, or "Why to disable assembly optimization"

Folks:

We had already agreed to disable assembly optimizations in pycryptopp, because there seem to have been a lot of bugs in the optimized assembly code in the past, and because the added speed really makes no difference to our uses, as far as I know.

However, in order to explain and justify to other people (e.g. Debian packagers) why we are doing this, and why they should consider doing the same thing themselves, I just read through the entire history of issues in pycryptopp and classified whether they were runtime errors (and therefore potential security bugs) or build-time errors (therefore probably not), and whether they would have been avoided if we had been disabling assembly optimizations all along. Here are the results. They clearly show that we should disable the optimized assembly! About half of all the security-threatening bugs we've had would never have been an issue if we'd avoided assembly from the beginning.

By the way, in my opinion the author of Crypto++, Wei Dai, is an *exceptionally* skilled, careful, and experienced coder, and I would assume that if Crypto++ has had this many security-threatening bugs in its optimized assembly code, then other crypto libraries that also use optimized assembly code also have at least as many.

Here's the ticket to track this issue:

https://tahoe-lafs.org/trac/pycryptopp/ticket/85

bugs that cause run-time failures =================================

(These bugs are potential security issues.)

* would have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/24 - https://tahoe-lafs.org/trac/pycryptopp/ticket/31 - https://tahoe-lafs.org/trac/pycryptopp/ticket/45 (three *different* bugs in the assembly implementation) - https://tahoe-lafs.org/trac/pycryptopp/ticket/67 - https://tahoe-lafs.org/trac/pycryptopp/ticket/84 - https://tahoe-lafs.org/trac/pycryptopp/ticket/86

* unclear if it would have been avoided if we'd used DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/65

* would not have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/17 - https://tahoe-lafs.org/trac/pycryptopp/ticket/44 - https://tahoe-lafs.org/trac/pycryptopp/ticket/83

* would not have been avoided by DISABLE_ASM (but would have been avoided by using cffi instead of CPython API) - https://tahoe-lafs.org/trac/pycryptopp/ticket/19 - https://tahoe-lafs.org/trac/pycryptopp/ticket/70 - https://tahoe-lafs.org/trac/pycryptopp/ticket/80

* would have been avoided if we *didn't* use DISABLE_ASM! (A bug only in the non-ASM version!) - https://tahoe-lafs.org/trac/pycryptopp/ticket/66

bugs that cause deterministic build or compilation failures ===========================================================

(These bugs are *typically* not potential security issues but they can be, and in any case they are engineering/deployment issues.)

* would have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/37 - https://tahoe-lafs.org/trac/pycryptopp/ticket/96

* would not have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/22 - https://tahoe-lafs.org/trac/pycryptopp/ticket/23 - https://tahoe-lafs.org/trac/pycryptopp/ticket/32 - https://tahoe-lafs.org/trac/pycryptopp/ticket/39 - https://tahoe-lafs.org/trac/pycryptopp/ticket/62 - https://tahoe-lafs.org/trac/pycryptopp/ticket/77 - https://tahoe-lafs.org/trac/pycryptopp/ticket/78

-- Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters.

-- Twitter https://twitter.com/tbiehn | LinkedIn http://www.linkedin.com/in/travisbiehn | GitHub http://github.com/tbiehn | TravisBiehn.com http://www.travisbiehn.com | Google Plus https://plus.google.com/+TravisBiehn