From: Michael Kebe <michael.kebe@gmail.com>
To: Marc Stevens <marc@marc-stevens.nl>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Jeff King" <peff@peff.net>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: Git 2.13.0 segfaults on Solaris SPARC due to DC_SHA1=YesPlease being on by default
Date: Tue, 16 May 2017 07:43:17 +0200 [thread overview]
Message-ID: <CAKKM46sS_5bVe5a6wNN7SdVoGvwmVxnLAZTxJ+tSftXfZKeGWg@mail.gmail.com> (raw)
In-Reply-To: <007001d2cd88$2b916180$82b42480$@marc-stevens.nl>
Hi Marc,
works like a charm!
Michael
2017-05-15 16:33 GMT+02:00 Marc Stevens <marc@marc-stevens.nl>:
> Hi Michael,
>
>
>
> See the latest commit to the SHA1DC repo:
>
> https://github.com/cr-marcstevens/sha1collisiondetection/commit/33a694a9ee1b79c24be45f9eab5ac0e1aeeaf271
>
> Just apply this same patch to SHA1DC in Git.
>
>
>
> Best regards,
>
> Marc Stevens
>
>
>
> Van: Michael Kebe [mailto:michael.kebe@gmail.com]
> Verzonden: maandag 15 mei 2017 16:22
> Aan: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> CC: Jeff King <peff@peff.net>; Git Mailing List <git@vger.kernel.org>; Marc
> Stevens <marc@marc-stevens.nl>
> Onderwerp: Re: Git 2.13.0 segfaults on Solaris SPARC due to
> DC_SHA1=YesPlease being on by default
>
>
>
> Just give me patch or repo, I will test it tomorrow.
>
>
>
> Michael
>
>
>
>
>
> Am 15.05.2017 4:14 nachm. schrieb "Ævar Arnfjörð Bjarmason"
> <avarab@gmail.com>:
>
> On Mon, May 15, 2017 at 3:58 PM, Marc Stevens <marc@marc-stevens.nl> wrote:
>> Hi Aevar,
>>
>> Thank you for notifying us of this issue.
>> Big endianness is a tricky issue, also since I don't have access or
>> accurate knowledge about all big endian systems.
>> Our github repo does check correct functioning, including an endianness
>> mistake, with 'make test'.
>> But I guess this is not included for SHA1DC in Git.
>>
>> Anyway, we can easily add the _BIG_ENDIAN macrotest to the git repo and
>> will do so soon.
>>
>> I don't think the segfault is caused by buffer overflow, inproper access,
>> or the endianness issue.
>> But I did notice an unexpected issue: the message block pointer m=0x398ad5
>> is odd.
>> Can you confirm whether loading an uint32_t from an odd address triggers a
>> hardware interrupt on your platform?
>> This is not problem for x86, but maybe for your platform it is?
>> If it is then we should always copy buffer contents to the sha1context to
>> avoid this issue.
>
> I don't have access to the box in question, Michael was testing this
> code for me. But unaligned access is probably the cause, although
> according to some info I found online that should give a SIGBUS not a
> SIGSEGV, but that may have changed:
>
> https://bugs.python.org/issue12181
> https://github.com/magnumripper/JohnTheRipper/issues/2187
>
>> Best regards,
>> Marc Stevens
>>
>> -----Oorspronkelijk bericht-----
>> Van: Ævar Arnfjörð Bjarmason [mailto:avarab@gmail.com]
>> Verzonden: maandag 15 mei 2017 14:49
>> Aan: Git Mailing List <git@vger.kernel.org>
>> CC: michael.kebe@gmail.com; Jeff King <peff@peff.net>; Marc Stevens
>> <marc@marc-stevens.nl>
>> Onderwerp: Git 2.13.0 segfaults on Solaris SPARC due to DC_SHA1=YesPlease
>> being on by default
>>
>> Since 2.13.0 just running "git status" on a newly init'd repo on Solaris
>> SPARC[1] segfaults. Michael (CC'd) reported this issue on #git and I helped
>> him debug it.
>>
>> Just compiling with BLK_SHA1=YesPlease solves the issue.
>>
>> There are at least two different issues with DC_SHA1 here:
>>
>> * We don't properly detect that this platform is big endian. The check at
>> the top of sha1dc/sha1.c needs to test for _BIG_ENDIAN. This comes from
>> sys/isa_defs.h which (I'm told by #solaris) is included on Solaris by
>> default, at least by stdio.h.
>>
>> Hacking the endian detection makes t0013-sha1dc.sh pass.
>>
>> * Even with that & the test passing just a plain "git init x && cd x &&
>> touch A && git add A && git commit" will segfault.
>>
>> This is some bug in the sha1dc code, presumably some big endian issue
>> that's not resolved by the change above. Backtrace for that (censored actual
>> author info):
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 1 (LWP 1)]
>> 0x002f8c84 in sha1_compression_states (ihv=0xffbf8268, m=0x398ad5,
>> W=0xffbf82fc, states=0xffbf857c) at sha1dc/sha1.c:291
>> 291 SHA1COMPRESS_FULL_ROUND1_STEP_LOAD(a, b, c, d, e, m,
>> W, 0, temp);
>> (gdb) bt
>> #0 0x002f8c84 in sha1_compression_states (ihv=0xffbf8268, m=0x398ad5,
>> W=0xffbf82fc, states=0xffbf857c) at sha1dc/sha1.c:291
>> #1 0x00300b60 in sha1_process (ctx=0xffbf8260, block=0x398ad5) at
>> sha1dc/sha1.c:1616
>> #2 0x00301188 in SHA1DCUpdate (ctx=0xffbf8260,
>> buf=0x398ad5 "deadbeefdeadbeefdeadbeefdeadbeefdeadbeef\nauthor Au
>> Thor <au.thor@example.com> 123456789 +0000\ncommitter Au Thor
>> <au.thor@example.com> 123456789
>> +0000\n\nBlah Blah"..., len=220)
>> at sha1dc/sha1.c:1731
>> #3 0x0030168c in git_SHA1DCUpdate (ctx=0xffbf8260, vdata=0x398aa0,
>> len=273) at sha1dc/sha1.c:1808
>> #4 0x002a6f7c in write_sha1_file_prepare (buf=0x398aa0, len=273,
>> type=0x959c8 "commit", sha1=0xffbfd630 "",
>> hdr=0xffbf8c28 "commit 273", hdrlen=0xffbf8c24) at sha1_file.c:3207
>> #5 0x002a71ac in hash_sha1_file (buf=0x398aa0, len=273, type=0x959c8
>> "commit", sha1=0xffbfd630 "") at sha1_file.c:3266
>> #6 0x002a25f8 in check_sha1_signature (sha1=0xffbfdbb8
>> "\375\067\356\337\002", map=0x398aa0, size=273, type=0x959c8 "commit")
>> at sha1_file.c:1644
>> #7 0x0022816c in parse_object (sha1=0xffbfdbb8
>> "\375\067\356\337\002") at object.c:269
>> #8 0x0027c258 in get_reference (revs=0xffbfdc88, name=0xa87f0 "HEAD",
>> sha1=0xffbfdbb8 "\375\067\356\337\002", flags=0)
>> at revision.c:196
>> #9 0x00284714 in setup_revisions (argc=0, argv=0x0, revs=0xffbfdc88,
>> opt=0xffbfdc74) at revision.c:2295
>> #10 0x002ee4d8 in wt_status_collect_changes_index (s=0x348ea8
>> <s.24114>) at wt-status.c:585
>> #11 0x002eeae8 in wt_status_collect (s=0x348ea8 <s.24114>) at
>> wt-status.c:701
>> #12 0x000db4fc in cmd_status (argc=0, argv=0xffbfe6fc, prefix=0x0) at
>> builtin/commit.c:1393
>> #13 0x000acc24 in run_builtin (p=0x340ccc <commands+1200>, argc=1,
>> argv=0xffbfe6fc) at git.c:371
>> #14 0x000acf98 in handle_builtin (argc=1, argv=0xffbfe6fc) at git.c:572
>> #15 0x000ad1a4 in run_argv (argcp=0xffbfe66c, argv=0xffbfe670) at
>> git.c:624
>> #16 0x000ad3fc in cmd_main (argc=1, argv=0xffbfe6fc) at git.c:701
>> #17 0x001747a0 in main (argc=5, argv=0xffbfe6ec) at common-main.c:43
>>
>> 1. Relevant part of uname -a: "SunOS <hostname> 5.11 11.3 sun4v sparc
>> sun4v".
>>
next prev parent reply other threads:[~2017-05-16 5:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-15 12:49 Git 2.13.0 segfaults on Solaris SPARC due to DC_SHA1=YesPlease being on by default Ævar Arnfjörð Bjarmason
2017-05-15 13:58 ` Marc Stevens
2017-05-15 14:13 ` Ævar Arnfjörð Bjarmason
2017-05-15 22:09 ` Jeff King
2017-06-01 14:03 ` demerphq
[not found] ` <CAKKM46vwM9pxyMxTc4jA0z_8vGKdDGCGg9ziKkFAsqr5ULYJxA@mail.gmail.com>
[not found] ` <007001d2cd88$2b916180$82b42480$@marc-stevens.nl>
2017-05-16 5:43 ` Michael Kebe [this message]
2017-05-17 5:39 ` [PATCH] sha1dc: fix issues with a big endian platform Junio C Hamano
2017-05-17 6:30 ` Ævar Arnfjörð Bjarmason
2017-05-17 7:09 ` Junio C Hamano
2017-05-17 11:38 ` [PATCH/RFC 0/3] Use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason
2017-05-17 18:52 ` Stefan Beller
2017-05-17 19:45 ` Ævar Arnfjörð Bjarmason
2017-05-17 19:57 ` Stefan Beller
2017-05-18 0:11 ` Brandon Williams
2017-05-17 11:38 ` [PATCH/RFC 1/3] sha1dc: update from my fork of upstream Ævar Arnfjörð Bjarmason
2017-05-17 11:38 ` [PATCH/RFC 2/3] sha1dc: use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason
2017-05-17 15:26 ` [PATCH] sha1dc: fix issues with a big endian platform Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKKM46sS_5bVe5a6wNN7SdVoGvwmVxnLAZTxJ+tSftXfZKeGWg@mail.gmail.com \
--to=michael.kebe@gmail.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=marc@marc-stevens.nl \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).