)]}' { "commit": "104306f587751f34852838915fb61ce5551c2332", "tree": "ca0d856f90098c1eb79027d45d06a53b13883760", "parents": [ "d8598ce03fe9294a03f90db9a47ca367564bc47f" ], "author": { "name": "David Benjamin", "email": "davidben@google.com", "time": "Sat Feb 09 22:14:30 2019 +0000" }, "committer": { "name": "Adam Langley", "email": "agl@google.com", "time": "Thu Feb 14 17:39:36 2019 +0000" }, "message": "Remove STRICT_ALIGNMENT code from modes.\n\nSTRICT_ALIGNMENT is a remnant of OpenSSL code would cast pointers to\nsize_t* and load more than one byte at a time. Not all architectures\nsupport unaligned access, so it did an alignment check and only enterred\nthis path if aligned or the underlying architecture didn\u0027t care.\n\nThis is UB. Unaligned casts in C are undefined on all architectures, so\nwe switch these to memcpy some time ago. Compilers can optimize memcpy\nto the unaligned accesses we wanted. That left our modes logic as:\n\n- If STRICT_ALIGNMENT is 1 and things are unaligned, work byte-by-byte.\n\n- Otherwise, use the memcpy-based word-by-word code, which now works\n independent of STRICT_ALIGNMENT.\n\nRemove the first check to simplify things. On x86, x86_64, and aarch64,\nSTRICT_ALIGNMENT is zero and this is a no-op. ARM is more complex. Per\n[0], ARMv7 and up support unaligned access. ARMv5 do not. ARMv6 does,\nbut can run in a mode where it looks more like ARMv5.\n\nFor ARMv7 and up, STRICT_ALIGNMENT should have been zero, but was one.\nThus this change should be an improvement for ARMv7 (right now unaligned\ninputs lose bsaes-armv7). The Android NDK does not even support the\npre-ARMv7 ABI anymore[1]. Nonetheless, Cronet still supports ARMv6 as a\nlibrary. It builds with -march\u003darmv6 which GCC interprets as supporting\nunaligned access, so it too did not want this code.\n\nFor completeness, should anyone still care about ARMv5 or be building\nwith an overly permissive -march flag, GCC does appear unable to inline\nthe memcpy calls. However, GCC also does not interpret\n(uintptr_t)ptr % sizeof(size_t) as an alignment assertion, so such\nconsumers have already been paying for the memcpy here and throughout\nthe library.\n\nIn general, C\u0027s arcane pointer rules mean we must resort to memcpy\noften, so, realistically, we must require that the compiler optimize\nmemcpy well.\n\n[0] https://medium.com/@iLevex/the-curious-case-of-unaligned-access-on-arm-5dd0ebe24965\n[1] https://developer.android.com/ndk/guides/abis#armeabi\n\nChange-Id: I3c7dea562adaeb663032e395499e69530dd8e145\nReviewed-on: https://boringssl-review.googlesource.com/c/34873\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n", "tree_diff": [ { "type": "modify", "old_id": "64ea505635043ec64b183cff412a26bb5dc01e7e", "old_mode": 33188, "old_path": "crypto/fipsmodule/modes/cbc.c", "new_id": "3f1d77766b9fb12e51371bfb55d95baa610a46ed", "new_mode": 33188, "new_path": "crypto/fipsmodule/modes/cbc.c" }, { "type": "modify", "old_id": "0a81f3b2f74f3d1ce81fd1c5098bdb62fe6e9375", "old_mode": 33188, "old_path": "crypto/fipsmodule/modes/cfb.c", "new_id": "8ca900416636c79fb8bd7c9450f9b42b6aa1bc3a", "new_mode": 33188, "new_path": "crypto/fipsmodule/modes/cfb.c" }, { "type": "modify", "old_id": "b806b9a3e6ed71c9ad618658704be2f8d323e7e7", "old_mode": 33188, "old_path": "crypto/fipsmodule/modes/ctr.c", "new_id": "8b0e0594741f993a24394d2091dbe6fa200f2183", "new_mode": 33188, "new_path": "crypto/fipsmodule/modes/ctr.c" }, { "type": "modify", "old_id": "97fde3e47f8cf747ef5755a6807659518b8c0f50", "old_mode": 33188, "old_path": "crypto/fipsmodule/modes/gcm.c", "new_id": "f92f6750eaa7273be4469ad2d15c2cfeaf7995e0", "new_mode": 33188, "new_path": "crypto/fipsmodule/modes/gcm.c" }, { "type": "modify", "old_id": "18ec60caae9dc62939cc07e91607b60597901d3d", "old_mode": 33188, "old_path": "crypto/fipsmodule/modes/internal.h", "new_id": "ed1160b88f96126406af384a85a26619f4e42db1", "new_mode": 33188, "new_path": "crypto/fipsmodule/modes/internal.h" } ] }