A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_6_3_BASE 2017-12-11T05:48:01+00:00 2017-12-11T05:48:01+00:00 deraadt 2017-12-11T05:48:01+00:00 urn:sha1:06a79a412573b1755b84374f8fdb1970ca59f1b6 My read of this: Long time ago (Think Conan, not dinasaurs) during the race to make speedier processors, a cpu vendor built a pipeline with a bad stall, and proposed a tremendously hasky workaround. A wizard adopted this into his perl scroll, and failed to reflect later when no compiler adopted the practice. This relic remains at the tail end of some functions in OpenSSL as ".byte 0xf3,0xc3". Banish it straight to hell. ok mlarkin, others also stared blankly 2017-06-28T13:34:50+00:00 deraadt 2017-06-28T13:34:50+00:00 urn:sha1:8dee50e45d344123bec1d8e5197c42f009053fec just fall into the code. The .align created a FILL zone in the .init section, which on i386 was filled with a NOP-sled, something we want to get away from. discussed with kettenis and tom 2016-11-04T17:30:30+00:00 miod 2016-11-04T17:30:30+00:00 urn:sha1:1a12fc8399638223feca8f853e2ac2cc22eeb471 meaningful constants in a private header file, so that reviewers can actually get a chance to figure out what the code is attempting to do without knowing all cpuid bits. While there, turn it from an array of two 32-bit ints into a properly aligned 64-bit int. Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will now always use OPENSSL_cpu_caps() and check for the proper bits in the whole 64-bit word it returns. i386 tests and ok jsing@ 2015-09-11T14:57:29+00:00 miod 2015-09-11T14:57:29+00:00 urn:sha1:1e96b158b233731c4fcc4561d29354dfa0b7799a only define them if not building for the "openbsd" flavour. This way, non-obfuscated output can still be generated for analysis, by using the "openbsd" flavour (which OpenBSD HEAD will do), and obfuscated output, compatible with older as(1), will be generated for other platforms. The portable version of LibreSSL can then use "openbsd-portable" as the flavour for OpenBSD/amd64 so that generated files can be compiled with OpenBSD 5.7 and other older versions stuck with as(1) 2.15. 2015-09-11T12:17:57+00:00 bcook 2015-09-11T12:17:57+00:00 urn:sha1:eafebfdd3adba0417a72d6cc8a75f367fc2fbbdb Fixes builds gcc + Apple's assembler, working on reenabling builds with older OpenBSD releases. based on OpenSSL commit: https://git.openssl.org/?p=openssl.git;a=commitdiff;h=902b30df193afc3417a96ba72a81ed390bd50de3 ok miod@ 2015-07-19T02:26:32+00:00 miod 2015-07-19T02:26:32+00:00 urn:sha1:3a1c21ea05417cdafece6fcfc145ab3f83910695 raw byte sequences. The toolchains have had some time to update and assemble the instructions correctly (except for p{ins,ext}rd which are not supported yet by as(1) under OpenBSD, but will be fixed shortly). Inspired by a discussion between tedu@ and John-Mark Gurney. Verified to still work on Mac OS X and average Linux distros by bcook@ 2014-06-06T20:18:20+00:00 deraadt 2014-06-06T20:18:20+00:00 urn:sha1:7bff3543d8495e130543a4e9d5a67d4ac4941aac hackathon, just saying 'ass ember' was enough to start giggles. Unfortunately far more offensive stuff remains in here... 2014-06-02T15:08:38+00:00 deraadt 2014-06-02T15:08:38+00:00 urn:sha1:63bcac43aa0d6361864d2102a9cbe8ec910b763e of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer. Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone. Send this support straight to the abyss. ok kettenis 2014-04-17T20:17:45+00:00 miod 2014-04-17T20:17:45+00:00 urn:sha1:233ad8c9007aff9089a52327cffb9efe414dc123 2014-04-13T15:25:35+00:00 miod 2014-04-13T15:25:35+00:00 urn:sha1:d2b3c9742a7df4ab87384039c99682d1944f66d7