The backtracing code will warn you if you attempt to forcibly enable
backtracing for a privileged executable. This is apparently upsetting
the Driver/filelists.swift test.
Since we want to force it on for tests, so that we will definitely get
backtraces, add an option to suppress warning messages, and turn that
on for tests as well.
rdar://144497613
We should harden the output path setting so that it can't be used
as part of an exploit to get a crashing process to overwrite a
file at an attacker-controller path, or to divert the crash report
to `/dev/null` to hide their tracks or other such undesirable
activity.
Take a copy of the setting at start-up and write-protect it to
prevent attackers overwriting it.
Note that we already protect against attempts to trigger the
backtracer from privileged programs (both on Darwin and Linux);
this is really a belt and braces measure to make life harder for
attackers.
rdar://136977833
Add the ability to specify a filename or directory name as the output-to
setting in `SWIFT_BACKTRACE`. If the option is set to a directory name,
generate a unique filename in that directory using the process name,
process ID and timestamp.
rdar://136977833
Also remove the code that deals with file descriptors; we will now
only start the backtracer for processes that have the get-task-allow
entitlement, which means that they've been specifically signed for
debugging, and *that* means that it is no longer critical to ensure
that unexpectedly inherited fds are closed.
rdar://137551812
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
Rather than just on or off, I've changed it to allow "off", "fast",
or "full". "fast" means that we'll do symbol lookup, but we won't
try to find inline frames and we won't run line number programs
(those are the things that are taking considerable time in some
cases).
rdar://122302117
Symbolication can take some time, depending on the binaries involved.
In certain contexts it's better for the backtrace to finish quickly,
and then symbolication could be done offline.
rdar://122302117
We shouldn't try to erase the message when in non-color mode; mostly
that's intended for redirected output scenarios anyway, and in that case
we don't really want garbage in the output.
Also, improve the failure messages when the backtracer itself goes
wrong or can't be executed.
Finally, change the behaviour slightly so that *if* we're explicitly
enabled, *and* the backtracer path wasn't explicitly specified, *and*
we can't find the backtracer, we print a warning on start-up. We
don't do that in any other case because we don't want spurious warnings
everywhere.
rdar://118055527
When we crash, emit a message straight away that says we're working
on a backtrace. If starting the backtracer fails, report that also.
Finally, add a duration to the messages output by the backtracer, so
that we can see how long it took.
rdar://118055527
We have two stacks that we set up during crash handling, both of
which were potentially misaligned. This only tripped us up on
Ubuntu 20.04 on aarch64 - my guess is that maybe `clone()` aligns
the stack pointer on newer kernels which is why we didn't see it
on 22.04.
rdar://110743884
`__cxa_demangle()` is a rather unusual API; one of its "features" is that
the pointer you pass in must either be `nullptr`, in which case it
will call `malloc()` itself, _or_ it has to be a pointer to a block
of memory allocated with `malloc()`, because `__cxa_demangle()` may
`realloc()` it for you.
This seems to me to be something of a non-obvious footgun, so we never
pass the caller's pointer through to `__cxa_demangle()`, which lets them
decide how they want to allocate space.
rdar://110261712
The `status` argument to the `_swift_backtrace_demangle()` function
isn't especially useful, won't match behaviour on Windows, and we
actually don't use it in the Swift code that calls this SPI.
Remove it.
rdar://110261712
Use the new module structure rather the old SwiftShims header. This
is much cleaner and lets us include operating system headers to get
the relevant definitions where possible.
Add code to support ELF and DWARF, including decompression using
zlib, zstd and liblzma if those turn out to be required and available.
rdar://110261712
Mike and Max made various helpful suggestions, so I've added and updated
various comments and amended the code to cope with partial reads and
writes.
rdar://110261430
This also adds a function to demangle a symbol, and a way for the
backtracing code to report warning messages to the same place as
the main runtime.
I'd like to rename the _swift_isThunkFunction() SPI also, but we
can't do that until we've made the changes to the _Backtracing
library, so we'll do that there instead.
rdar://110261430
Some symbolication frameworks have a symbol cache; we probably don't want
to use that for test cases, to avoid running into problems where the cache
holds stale information.
rdar://105409147
We really, really shouldn't be running the external backtracer for setuid
binaries. It's just too dangerous.
So don't do that. And if someone tries to force us, emit a warning.
rdar://105391747
