git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git 2.13.0 segfaults on Solaris SPARC due to DC_SHA1=YesPlease being on by default

From
Jeff King <peff@peff.net>
Date
May 15, 2017, 22:09 UTC
Message-ID
<20170515220939.vkgofpkdtpz7u26v@sigill.intra.peff.net>
In-Reply-To
<CACBZZX5Q9paMbYWH47fdK9GuNrE=F=FwR__E1yZ32EOAMw_w6w@mail.gmail.com>
On Mon, May 15, 2017 at 04:13:58PM +0200, Ævar Arnfjörð Bjarmason wrote:
Show 20 quoted lines
> 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:

Yeah, I would have expected SIGBUS there. If we have alignment issues, though, I'd expect that ARM systems will experience problems.

Block-sha1 uses a macro which allows unaligned loads on platforms that support it, and otherwise does the endian conversion on the fly as we load the bytes into a local variable (which presumably happens all in-register). That may be faster than doing a mass copy of the buffer.

-Peff
Previous: Ævar Arnfjörð BjarmasonNext: demerphq
Message 4 of 17 in “Git 2.13.0 segfaults on Solaris SPARC due to DC_SHA1=YesPlease being on by default”
  1. Ævar Arnfjörð BjarmasonMay 15, 2017
  2. Marc StevensMay 15, 2017
  3. Ævar Arnfjörð BjarmasonMay 15, 2017
  4. Jeff KingMay 15, 2017
  5. demerphqJun 1, 2017
  6. Michael KebeMay 16, 2017
  7. sha1dc: fix issues with a big endian platformJunio C Hamano, May 17, 2017
  8. Ævar Arnfjörð BjarmasonMay 17, 2017
  9. Junio C HamanoMay 17, 2017
  10. 0/3 Use sha1collisiondetection as a submoduleÆvar Arnfjörð Bjarmason, May 17, 2017
  11. 1/3 sha1dc: update from my fork of upstreamÆvar Arnfjörð Bjarmason, May 17, 2017
  12. 2/3 sha1dc: use sha1collisiondetection as a submoduleÆvar Arnfjörð Bjarmason, May 17, 2017
  13. Stefan BellerMay 17, 2017
  14. Ævar Arnfjörð BjarmasonMay 17, 2017
  15. Stefan BellerMay 17, 2017
  16. Brandon WilliamsMay 18, 2017
  17. Johannes SchindelinMay 17, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.