aboutgitcodebugslistschat
path: root/siphash.c
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2023-02-27 01:57:36 +0100
committerStefano Brivio <sbrivio@redhat.com>2023-02-27 18:54:13 +0100
commita48c5c2abf8aba39c32cf6845d51b5ca05d33361 (patch)
treec364fb948bc6ae447862755ad590e518c1b58157 /siphash.c
parentda46fdac36058e97e5a3131e2c51d162f4c619e9 (diff)
downloadpasst-a48c5c2abf8aba39c32cf6845d51b5ca05d33361.tar
passt-a48c5c2abf8aba39c32cf6845d51b5ca05d33361.tar.gz
passt-a48c5c2abf8aba39c32cf6845d51b5ca05d33361.tar.bz2
passt-a48c5c2abf8aba39c32cf6845d51b5ca05d33361.tar.lz
passt-a48c5c2abf8aba39c32cf6845d51b5ca05d33361.tar.xz
passt-a48c5c2abf8aba39c32cf6845d51b5ca05d33361.tar.zst
passt-a48c5c2abf8aba39c32cf6845d51b5ca05d33361.zip
treewide: Disable gcc strict aliasing rules as needed, drop workarounds
Recently, commit 4ddbcb9c0c55 ("tcp: Disable optimisations for tcp_hash()") worked around yet another issue we hit with gcc 12 and '-flto -O2': some stores affecting the input data to siphash_20b() were omitted altogether, and tcp_hash() wouldn't get the correct hash for incoming connections. Digging further into this revealed that, at least according to gcc's interpretation of C99 aliasing rules, passing pointers to functions with different types compared to the effective type of the object (for example, a uint8_t pointer to an anonymous struct, as it happens in tcp_hash()), doesn't guarantee that stores are not reordered across the function call. This means that, in general, our checksum and hash functions might not see parts of input data that was intended to be provided by callers. Not even switching from uint8_t to character types, which should be appropriate here, according to C99 (ISO/IEC 9899, TC3, draft N1256), section 6.5, "Expressions", paragraph 7: An object shall have its stored value accessed only by an lvalue expression that has one of the following types: [...] — a character type. does the trick. I guess this is also subject to interpretation: casting passed pointers to character types, and then using those as different types, might still violate (dubious) aliasing rules. Disable gcc strict aliasing rules for potentially affected functions, which, in turn, disables gcc's Type-Based Alias Analysis (TBAA) optimisations based on those function arguments. Drop the existing workarounds. Also the (seemingly?) bogus 'maybe-uninitialized' warning on the tcp_tap_handler() > tcp_hash() > siphash_20b() path goes away with -fno-strict-aliasing on siphash_20b(). Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'siphash.c')
-rw-r--r--siphash.c22
1 files changed, 19 insertions, 3 deletions
diff --git a/siphash.c b/siphash.c
index 811918b..e8b144d 100644
--- a/siphash.c
+++ b/siphash.c
@@ -104,6 +104,17 @@
*
* Return: the 64-bit hash output
*/
+/* Type-Based Alias Analysis (TBAA) optimisation in gcc 11 and 12 (-flto -O2)
+ * makes these functions essentially useless by allowing reordering of stores of
+ * input data across function calls. Not even declaring @in as char pointer is
+ * enough: disable gcc's interpretation of strict aliasing altogether. See also:
+ *
+ * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106706
+ * https://stackoverflow.com/questions/2958633/gcc-strict-aliasing-and-horror-stories
+ * https://lore.kernel.org/all/alpine.LFD.2.00.0901121128080.6528__33422.5328093909$1232291247$gmane$org@localhost.localdomain/
+ */
+/* NOLINTNEXTLINE(clang-diagnostic-unknown-attributes) */
+__attribute__((optimize("-fno-strict-aliasing")))
/* cppcheck-suppress unusedFunction */
uint64_t siphash_8b(const uint8_t *in, const uint64_t *k)
{
@@ -123,6 +134,8 @@ uint64_t siphash_8b(const uint8_t *in, const uint64_t *k)
*
* Return: 32 bits obtained by XORing the two halves of the 64-bit hash output
*/
+/* NOLINTNEXTLINE(clang-diagnostic-unknown-attributes) */
+__attribute__((optimize("-fno-strict-aliasing"))) /* See siphash_8b() */
/* cppcheck-suppress unusedFunction */
uint32_t siphash_12b(const uint8_t *in, const uint64_t *k)
{
@@ -148,9 +161,8 @@ uint32_t siphash_12b(const uint8_t *in, const uint64_t *k)
*
* Return: the 64-bit hash output
*/
-#if SIPHASH_20B_NOINLINE
-__attribute__((__noinline__)) /* See comment in Makefile */
-#endif
+/* NOLINTNEXTLINE(clang-diagnostic-unknown-attributes) */
+__attribute__((optimize("-fno-strict-aliasing"))) /* See siphash_8b() */
uint64_t siphash_20b(const uint8_t *in, const uint64_t *k)
{
uint32_t *in32 = (uint32_t *)in;
@@ -179,6 +191,8 @@ uint64_t siphash_20b(const uint8_t *in, const uint64_t *k)
*
* Return: the 64-bit hash output
*/
+/* NOLINTNEXTLINE(clang-diagnostic-unknown-attributes) */
+__attribute__((optimize("-fno-strict-aliasing"))) /* See siphash_8b() */
/* cppcheck-suppress unusedFunction */
uint32_t siphash_32b(const uint8_t *in, const uint64_t *k)
{
@@ -205,6 +219,8 @@ uint32_t siphash_32b(const uint8_t *in, const uint64_t *k)
*
* Return: 32 bits obtained by XORing the two halves of the 64-bit hash output
*/
+/* NOLINTNEXTLINE(clang-diagnostic-unknown-attributes) */
+__attribute__((optimize("-fno-strict-aliasing"))) /* See siphash_8b() */
uint32_t siphash_36b(const uint8_t *in, const uint64_t *k)
{
uint32_t *in32 = (uint32_t *)in;