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 <[email protected]> wrote: > ---------- Forwarded message ---------- > From: Zooko Wilcox-OHearn <[email protected]> > 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>
