Altivec code in `crypto/ocb_internal.cc` fails to compile, needs to use `__vector` instead of `vector` about mosh HOT 15 OPEN

Please provide details about your system. This works in our CI and in all distribution packages.

from mosh.

@achernya Thank you for responding!
macOS 10.6, gcc-13.2 (in fact gcc-4.2 is not picked at all due to C++ standard requirement, I just did not notice that initially).

It could be that either code is correct but uses VSX and not Altivec, in which case fixing a macro will work (i.e., use __VSX__). Or if the code is supposed to by ISA 2.03-compliant, then something is wrong in it (maybe includes).

If it is supposed to be ISA 2.03-compliant, then a macro for ppc64 has to be fixed as well, since the current one will lead to Darwin on ppc64 trying to use 32-bit chunk (it should also check for __ppc64__ to have an intended effect).

from mosh.

With includes by the way configure does not check for machine/endian.h, which is the path on Darwin, but it is likely unrelated to the issue here and possibly inconsequential, since libkern macros are checked for.

from mosh.

A lazy fix will be

--- src/crypto/ocb_internal.cc
+++ src/crypto/ocb_internal.cc
@@ -220,7 +220,7 @@
 		bl = _mm_slli_epi32(bl, 1);
 		return _mm_xor_si128(bl,tmp);
 	}
-#elif __ALTIVEC__ && _CALL_ELF != 2
+#elif __VSX__ && _CALL_ELF != 2
     #include <altivec.h>
     typedef vector unsigned block;
     #define xor_block(x,y)         vec_xor(x,y)

or if it is known that it works on G4/G5 but not on MacOS, then

--- src/crypto/ocb_internal.cc
+++ src/crypto/ocb_internal.cc
@@ -220,7 +220,7 @@
 		bl = _mm_slli_epi32(bl, 1);
 		return _mm_xor_si128(bl,tmp);
 	}
-#elif __ALTIVEC__ && _CALL_ELF != 2
+#elif (__ALTIVEC__ && _CALL_ELF != 2) && !defined(__APPLE__)
     #include <altivec.h>
     typedef vector unsigned block;
     #define xor_block(x,y)         vec_xor(x,y)

However it may be just some error, and the code could work. In which case we would not want to simply disable vectorization.

from mosh.

macOS 10.6 is no longer in support and ocb_internal is vendered code from https://www.cs.ucdavis.edu/~rogaway/ocb/news/code/ocb.c so I'm hesitant to touch it in a meaningful way other than deletions. I suggest you try enabling the openssl-based ocb implementation instead. (That would have been our default for mosh-1.4.0 if it hasn't been for CVE-2022-2097)

from mosh.

@achernya Well, if no one knows how to fix it to work on macOS (I do not know Altivec syntax), then just disabling is fine. It will not affect anything else, obviously, since __APPLE__ is defined only for macOS.
That will at least unbreak the build and allow it to function.

from mosh.

@barracuda156 please demonstrate that the build is broken on a modern, supported macOS -- otherwise we are not interested in this patchset.

from mosh.

@achernya The patch specifically disables it where it is broken. It does not affect other systems where the code is presumed to work. I also fix the failing case here.

from mosh.

@barracuda156 as I mentioned in my comment above: I am not willing to take any changes to this file other than deletions. If you would like to get mosh to work, please enable the openssl-based ocb build instead. If you would like to submit a PR to delete all the altivec code instead, I would be willing to merge that.

from mosh.

ocb_internal is vendered code

This is why you don't bundle vendored libraries.

from mosh.

@achernya I guess I did not understand correctly your reasoning. If you do not want to modify the code because it is vendored, I am not a legal expert, but I can accept that.

I am not sure if it is a right thing to remove the code, since while it will fix the bug for one platform, it may result in suboptimal performance on another platform, and I have no way to verify if the code builds on BSD and Linux or not.

from mosh.

@barracuda156 there's nothing about legality or not of modifying it. It's our inability to have CI for this configuration, therefore a desire to not support it.

from mosh.

@achernya What you do with your project is up to you, of course, but to be honest I cannot see how my fix could have any conceivable adverse effect on any platform whatsoever. The only effect of it was to disable usage of that Altivec code on macOS. It was as non-invasive as possible. I am not asking you to support PowerPC proactively nor expect anyone to do it. But no one is better off if the broken code is left unfixed, when the cost of the fix is a single line change with no effect on other systems.

from mosh.

Your fix creates an ongoing expectation of support by the maintainers of this project. I've already expressed my desires here that we reduce that support burden since we cannot easily test for altivec on ppc. As a result, I can't take your contribution as is.

Continuing to discuss won't cause us to accept the single-line fix since it doesn't change our ability to test it in an ongoing basis.

from mosh.

Just for the record if anyone ever bumps into the issue: the correct fix is to change vector to __vector (and obviously fix a macro for ppc64). Like this: macports/macports-ports@a910a13

My initial suggestion to disable it was suboptimal. The code is fine, but type used is inaccurate.

Related chunk in altivec.h is here: https://github.com/gcc-mirror/gcc/blob/58ecd2eb507ab216861408cf10ec05efc4e8344e/gcc/config/rs6000/altivec.h#L37-L49

from mosh.