On Fri, Feb 09, 2024 at 02:27:26PM +0530, Ashutosh Bapat wrote:
> On Fri, Feb 9, 2024 at 2:18 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>> Hmm, but the backtrace() manpage says
>>
>> • backtrace() and backtrace_symbols_fd() don't call malloc() explic‐
>> itly, but they are part of libgcc, which gets loaded dynamically
>> when first used. Dynamic loading usually triggers a call to mal‐
>> loc(3). If you need certain calls to these two functions to not
>> allocate memory (in signal handlers, for example), you need to make
>> sure libgcc is loaded beforehand.
>>
>> and the patch ensures that libgcc is loaded by calling a dummy
>> backtrace() at the start of the process.
FWIW, anything I am reading about the matter freaks me out, including
the dlopen() part in all the backends:
https://www.gnu.org/software/libc/manual/html_node/Backtraces.html
So I really question whether it is a good idea to assume if this will
always be safe depending on the version of libgcc dealt with,
increasing the impact area. Perhaps that's worrying too much, but it
looks like one of these things where we'd better be really careful.
> We defer actual action triggered by a signal till CHECK_FOR_INTERRUPTS
> is called. I understand that we can't do that here since we want to
> capture the backtrace at that moment and can't wait till next CFI. But
> printing the backend can surely wait till next CFI right?
Delaying the call of backtrace() to happen during a CFI() would be
safe, yes, and writing data to stderr would not really be an issue as
at least the data would be sent somewhere. That's less useful, but
we do that for memory contexts.
--
Michael