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

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

From
Jeff King <peff@peff.net>
Date
Jun 15, 2018, 17:31 UTC
Message-ID
<20180615173155.GC3067@sigill.intra.peff.net>
In-Reply-To
<xmqq1sd82e9h.fsf@gitster-ct.c.googlers.com>
On Fri, Jun 15, 2018 at 09:41:46AM -0700, Junio C Hamano wrote:
Show 20 quoted lines
> Derrick Stolee <stolee@gmail.com> writes:
> 
> > On 6/14/2018 11:44 PM, Jeff King wrote:
> >> The return value of ewah_read_mmap() is now an ssize_t,
> >> since we could (in theory) process up to 32GB of data. This
> >> would never happen in practice, but a corrupt or malicious
> >> .bitmap or index file could convince us to do so.
> >
> > Aside: Why a 32GB limit? Usually I see 32-bit issues limiting by 2
> > (signed) or 4 GB (unsigned). Is there something specifically in the
> > bitmap format that stops at this size?
> 
> The proposed log message for 1/3 has this bit
> 
>   - check the size for integer overflow (this should be
>     impossible on 64-bit, as the size is given as a 32-bit
>     count of 8-byte words, but is possible on a 32-bit
>     system)
> 
> 4 Giga 8-byte words makes 32 Giga bytes, I'd guess.

Yes, exactly. It's definitely an odd size. I think using the same varints we use in the packfile would be more efficient (and they're already variable-length records), though we tend to have few enough of these that it probably doesn't matter.

I think a more useful change for the bitmap format would be some kind of index. IIRC, right now readers have to linearly scan the whole file in order to use a single bitmap.

With Stolee's commit-metadata files, we could potentially move to storing reachability bitmaps as a data element there. But there are two complications:

 - the bitmaps themselves are dependent on having an ordered list of
   objects (one per bit) to talk about. And that's why they're
   integrated with packfiles, since that provides a constrained universe
   with a set ordering.
 - the existing storage isn't entirely independent between bitmaps. Some
   of them are basically "deltas" off of nearby bitmaps.
-Peff
Previous: Junio C HamanoNext: Derrick Stolee
Message 52 of 58 in “security: potential out-of-bound read at ewah_io.c |ewah_read_mmap|”
  1. Luat NguyenJun 14, 2018
  2. Jeff KingJun 15, 2018
  3. 1/3 ewah_read_mmap: bounds-check mmap readsJeff King, Jun 15, 2018
  4. SZEDER GáborJun 15, 2018
  5. Junio C HamanoJun 15, 2018
  6. SZEDER GáborJun 15, 2018
  7. Jeff KingJun 15, 2018
  8. Junio C HamanoJun 15, 2018
  9. Junio C HamanoJun 15, 2018
  10. Jeff KingJun 15, 2018
  11. Junio C HamanoJun 15, 2018
  12. SZEDER GáborJun 16, 2018
  13. Jeff KingJun 16, 2018
  14. 2/3 ewah: drop ewah_deserialize functionJeff King, Jun 15, 2018
  15. 3/3 ewah: drop ewah_serialize_native functionJeff King, Jun 15, 2018
  16. Ramsay JonesJun 15, 2018
  17. Ramsay JonesJun 15, 2018
  18. 0/8 Delete unused methods in EWAH bitmapDerrick Stolee, Jun 15, 2018
  19. 2/8 ewah/bitmap.c: delete unused 'bitmap_each_bit()'Derrick Stolee, Jun 15, 2018
  20. Ramsay JonesJun 15, 2018
  21. 4/8 ewah_bitmap: delete unused 'ewah_and_not()'Derrick Stolee, Jun 15, 2018
  22. 6/8 ewah_bitmap: delete unused 'ewah_or()'Derrick Stolee, Jun 15, 2018
  23. 8/8 ewah_io: delete unused 'ewah_serialize_native()'Derrick Stolee, Jun 15, 2018
  24. Ramsay JonesJun 15, 2018
  25. Derrick StoleeJun 15, 2018
  26. 1/8 ewah/bitmap.c: delete unused 'bitmap_clear()'Derrick Stolee, Jun 15, 2018
  27. Ramsay JonesJun 15, 2018
  28. Derrick StoleeJun 15, 2018
  29. 7/8 ewah_io: delete unused 'ewah_serialize()'Derrick Stolee, Jun 15, 2018
  30. 3/8 ewah_bitmap: delete unused 'ewah_and()'Derrick Stolee, Jun 15, 2018
  31. 5/8 ewah_bitmap: delete unused 'ewah_not()'Derrick Stolee, Jun 15, 2018
  32. Derrick StoleeJun 15, 2018
  33. 0/7 Delete unused methods in EWAH bitmapDerrick Stolee, Jun 15, 2018
  34. 1/7 ewah/bitmap.c: delete unused 'bitmap_clear()'Derrick Stolee, Jun 15, 2018
  35. 2/7 ewah/bitmap.c: delete unused 'bitmap_each_bit()'Derrick Stolee, Jun 15, 2018
  36. 3/7 ewah_bitmap: delete unused 'ewah_and()'Derrick Stolee, Jun 15, 2018
  37. 4/7 ewah_bitmap: delete unused 'ewah_and_not()'Derrick Stolee, Jun 15, 2018
  38. 7/7 ewah_io: delete unused 'ewah_serialize()'Derrick Stolee, Jun 15, 2018
  39. 5/7 ewah_bitmap: delete unused 'ewah_not()'Derrick Stolee, Jun 15, 2018
  40. 6/7 ewah_bitmap: delete unused 'ewah_or()'Derrick Stolee, Jun 15, 2018
  41. Junio C HamanoJun 15, 2018
  42. Derrick StoleeJun 15, 2018
  43. Junio C HamanoJun 15, 2018
  44. Jeff KingJun 15, 2018
  45. Derrick StoleeJun 15, 2018
  46. Jeff KingJun 15, 2018
  47. Junio C HamanoJun 15, 2018
  48. Jeff KingJun 15, 2018
  49. 4/3 ewah: adjust callers of ewah_read_mmap()Jeff King, Jun 15, 2018
  50. Derrick StoleeJun 15, 2018
  51. Junio C HamanoJun 15, 2018
  52. Jeff KingJun 15, 2018
  53. Derrick StoleeJun 15, 2018
  54. Jeff KingJun 15, 2018
  55. Junio C HamanoJun 15, 2018
  56. Junio C HamanoJun 15, 2018
  57. Dyer, EdwinJun 19, 2018
  58. Jeff KingJun 19, 2018

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.