packages feed

crypton 2.0.0 → 2.0.1

raw patch · 3 files changed

+34/−1 lines, 3 filesPVP ok

version bump matches the API change (PVP)

API changes (from Hackage documentation)

Files

CHANGELOG.md view
@@ -1,5 +1,24 @@ # CHANGELOG for crypton +## 2.0.1++* fix(cpu): stop reading Intel's SDBG bit as AMD's XOP, which crashed SHA-512+  and ChaCha20 on Broadwell and later.  The vendored assembly dispatches on a+  capability word this library fills, and reads bit 11 of its second dword as+  XOP -- which is CPUID leaf 0x80000001 ECX bit 11, an AMD extended leaf.+  crypton put the raw leaf 1 ECX there, whose bit 11 is SDBG, the silicon+  debug interface, which Intel has reported since Broadwell.  On such a+  processor `sha512-x86_64.S` took `.Lxop_shortcut` and+  `chacha-x86_64.S` took `.Lcrypton_chacha20_asm_4xop`, and the first+  `vprotq` is an invalid opcode: SIGILL, for SHA-512 and SHA-384, and for+  ChaCha20 and so ChaCha20-Poly1305.  OpenSSL clears leaf 1's bit 11 before+  merging the real flag in; crypton now clears it and leaves it clear, so the+  XOP paths are never taken.  Nothing is lost -- XOP ran from AMD's Bulldozer+  to Excavator and Zen dropped it -- and it is the reason the AVX-512 bits+  beside it are cleared as well.  Reported by @lucasdicioccio, who+  disassembled the trap+  [#202](https://github.com/kazu-yamamoto/crypton/issues/202)+ ## 2.0.0  * fix(docs): export the names the documentation already referred to.
cbits/crypton_cpu.c view
@@ -147,6 +147,20 @@ 		leaf1_ecx = ecx; 		if (!(f & CRYPTON_X86_AVX)) 			leaf1_ecx &= ~(1u << 28);+		/*+		 * Bit 11 is not leaf 1's to give.  The assembly reads it as+		 * AMD's XOP, which lives in leaf 0x80000001, and OpenSSL+		 * clears whatever leaf 1 put there before merging the real+		 * flag into the place -- on Intel that is SDBG, the silicon+		 * debug interface, reported since Broadwell, and reading it+		 * as XOP sends SHA-512 and ChaCha20 into a vprotq and a+		 * SIGILL.  It is cleared and left clear: nothing here can run+		 * XOP to test it, and no processor still in service has it,+		 * AMD having carried it from Bulldozer to Excavator and Zen+		 * having dropped it.  That is the reason the AVX-512 bits+		 * above are cleared too.+		 */+		leaf1_ecx &= ~(1u << 11); 		crypton_ia32cap_P[1] = leaf1_ecx;  		if (maxleaf >= 7) {
crypton.cabal view
@@ -1,6 +1,6 @@ cabal-version:      3.0 name:               crypton-version:            2.0.0+version:            2.0.1 license:            BSD-3-Clause license-file:       LICENSE copyright:          Vincent Hanquez <vincent@snarc.org>