Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Feb 2019 17:09:37 +0100
From: Markus Wichmann <>
Subject: Re: Stdio resource usage

On Wed, Feb 20, 2019 at 02:24:23PM -0500, Rich Felker wrote:
> For what it's worth, gcc has a -fconserve-stack that in principle
> should avoid this problem, but I could never get it to do anything. If
> it works now we should probably detect and add it to default CFLAGS.
> Rich

Well, that also doesn't help since gcc is the compiler that *doesn't*
exhibit the problem. clang does. And clang doesn't have an option to
conserve stack (that I've seen).

I am wondering what other possibilities exist to prevent the issue. If
we won't change the algorithm, that only leaves exploring other
possibilities for the memory allocation.

So, what are our choices?

- Heap allocation: But that can fail. Now, printf() is actually allowed
  to fail, but no-one expects it to. I would expect such behavior to be
  problematic at best.
- Static allocation: Without synchronization this won't be thread-safe,
  with synchronization it won't be re-entrant. Now, as far as I could
  see, the printf() family is actually not required to be re-entrant
  (e.g. signal-safety(7) fails to list any of them), but I have seen
  sprintf() in signal handlers in the wild (well, exception handlers,
- Thread-local static allocation: Which is always a hassle in libc, and
  does not take care of re-entrancy. It would only solve the
  thread-safety issue.
- As-needed stack allocation (e.g. alloca()): This fails to prevent the
  worst case allocation, though it would make the average allocation
  more bearable. But I don't know if especially clever compilers like
  clang wouldn't optimize this stuff away, and we'd be back to square

Any ideas left?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.