Don’t put an absurd amount of data onto the stack in some configs #692

issue gmaxwell openend this issue on November 9, 2019
  1. gmaxwell commented at 8:44 pm on November 9, 2019: contributor

    PR #337 adds a –with-ecmult-gen-precision=8 which puts >672kb onto the stack during gen_context or at runtime in signing context creation if –disable-ecmult-static-precomputation is also used.

    Default stacks being 8MB is mostly a 64-bit linux distroism.

    I expect this gen_context and context create with no statick precomp now crashes with that config on some systems. I believe the default stack on Windows is 1MB, linux kernel code stack size is 8kb, 32-bit linux default stack size is 2MB. Lots of other systems have a modest default stack. IIRC firefox multimedia threads have a 128kb stack.

    And, of course, whatever stack the library uses is added onto the caller, so it pays to be pretty conservative.

    The commit message seems to indicate that valgrind was telling you that the stack was out of control. You probably don’t want to ignore that– the valgrind default setting is the amount needed for 32-bit linux to not barf, some other systems as I mention are even more constrained.

    For normal usage this library shouldn’t put more than a few kilobytes onto the stack. There is an issue which specifies making the stack usage explicit (#188). I suppose allowances could be made for weird configs like –disable-ecmult-static-precomputation + –with-ecmult-gen-precision=8, but even there doing well over 100kb will probably start crashing real programs on real systems.

    Tests could probably get away with a fair bit more, since they control the entire calling stack and aren’t going to cause mysterious runtime crashes– but it would still be nice to be able to run them directly on the sort of low memory devices that can run the library.

  2. apoelstra commented at 9:08 pm on November 9, 2019: contributor
    #546 would fix this.
  3. mratsim cross-referenced this on Nov 10, 2019 from issue Check stack usage (other than EVM) by mratsim
  4. laanwj commented at 4:00 pm on November 10, 2019: member

    Ah yes, I also stumbled into this one once. I remember some tweaking of the parameters solved it, but yes, I agree being able to put half a MB of data on the stack is not a good default assumption.

    You might want to compile wth -Wframe-larger-than=... -Werror=frame-larger-than (r something like that) in the CI to detect these and fail on it.

  5. gmaxwell commented at 7:10 pm on November 10, 2019: contributor

    Does anyone have a usecase for gen-precision=8 or was it just added for completionism?

    If no one does, it should probably be dropped, @laanwj’s suggested warnings (Werror in CI only) added to clamp it to just above the peak usage with 4.

    Then hopefully 546 is eventually included, considering it looks like it gives 8’s performance with less memory than 4. :)

    It would be nice to guarantee in the standard config that it doesn’t use more than 4kb or so at runtime or at least so for non-batch verification, which I suspect is already achieved.

  6. gmaxwell renamed this:
    Don't put an absurd amount of data onto the stack
    Don't put an absurd amount of data onto the stack in some configs
    on Nov 15, 2019
  7. real-or-random cross-referenced this on Feb 25, 2020 from issue Signed-digit multi-comb for ecmult_gen (by peterdettman) by sipa
  8. real-or-random cross-referenced this on Dec 3, 2021 from issue Make signing table fully static by real-or-random
  9. real-or-random closed this on Dec 15, 2021

  10. real-or-random closed this on Dec 15, 2021


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin-core/secp256k1. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-22 01:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me