Re: disabling sha1dc unaligned access, was Re: One failed self test on Fedora 29
- Date: Mon, 11 Mar 2019 06:40:21 -0400
- From: Jeffrey Walton <noloader@xxxxxxxxx>
- Subject: Re: disabling sha1dc unaligned access, was Re: One failed self test on Fedora 29
On Sun, Mar 10, 2019 at 11:37 PM Jeff King <peff@xxxxxxxx> wrote:
> On Mon, Mar 11, 2019 at 11:00:25AM +0900, Junio C Hamano wrote:
> > Jeffrey Walton <noloader@xxxxxxxxx> writes:
> > > I think this is the patch for sha1dc/sha1.c . It stops using unaligned
> > > accesses by default, but still honors SHA1DC_FORCE_UNALIGNED_ACCESS
> > > for those who want it. Folks who want the undefined behavior have to
> > > do something special.
> > Hmph, I somehow thought that folks who want to stick to the
> > standard printed on paper penalizing what practicaly works well in
> > the real world would be the one doing extra things.
> Unfortunately, I don't think sha1dc currently supports #defines in that
> direction. The only logic is "if we are on intel, do unaligned loads"
> and "even if we are not on intel, do it anyway". There is no "even if we
> are on intel, do not do unaligned loads".
> I think you'd need something like this:
> diff --git a/Makefile b/Makefile
> index 148668368b..705c54dcd8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1194,6 +1194,7 @@ BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE)
> BASIC_CFLAGS += -fno-omit-frame-pointer
> ifneq ($(filter undefined,$(SANITIZERS)),)
> BASIC_CFLAGS += -DNO_UNALIGNED_LOADS
> +BASIC_CFLAGS += -DSHA1DC_DISALLOW_UNALIGNED_ACCESS
> ifneq ($(filter leak,$(SANITIZERS)),)
> BASIC_CFLAGS += -DSUPPRESS_ANNOTATED_LEAKS
> diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c
> index df0630bc6d..0bdf80d778 100644
> --- a/sha1dc/sha1.c
> +++ b/sha1dc/sha1.c
> @@ -124,9 +124,11 @@
> /*ENDIANNESS SELECTION*/
> +#ifndef SHA1DC_DISALLOW_UNALIGNED_ACCESS
> #if defined(SHA1DC_FORCE_UNALIGNED_ACCESS) || defined(SHA1DC_ON_INTEL_LIKE_PROCESSOR)
> #define SHA1DC_ALLOW_UNALIGNED_ACCESS
> #endif /*UNALIGNMENT DETECTION*/
> #define rotate_right(x,n) (((x)>>(n))|((x)<<(32-(n))))
> but of course we cannot touch sha1dc/*, because we might actually be
> using the submodule copy instead. And AFAIK there is no good way to
> modify the submodule-provided content as part of the build. Why do we
> even have the submodule again? ;P
> I guess the same would be true for DC_SHA1_EXTERNAL, too, though.
> So anyway, I think this needs a patch to the upstream sha1dc project.