[Toybox] Android binaries?

[Rich Felker]

On Sun, Aug 23, 2020 at 11:54:12PM -0500, Rob Landley wrote:
> On 8/21/20 6:36 PM, enh wrote:
> >     I'm writing a "reporting bugs" FAQ entry because of the recent github thread.
> > 
> >     I've also had a todo item to salvage todo entries I wrote for busybox forever
> >     ago, especially since the busybox devs crapped all over the current versions.
> >     For example,
> >     https://git.busybox.net/busybox/tree/docs/busybox.net/FAQ.html?h=95718b309169#n361
> >     used to be project-agnostic (usable advice no matter what open source project
> >     you were talking about), but in current https://busybox.net/FAQ.html#backporting
> >     they've inserted a large digression in the middle about configuring busybox
> >     source from the command line to make sure it doesn't apply to any other project
> >     and can't be generally referenced as advice by other projects.
> > 
> >     But anyway, the advice was "try to reproduce the bug on a current version before
> >     poking the developers because there's a nonzero chance we already fixed it", and
> >     for linux toybox I can point them at
> >     https://landley.net/toybox/downloads/binaries for current versions (even if they
> >     don't want to build it from source for their target)... but those are linked
> >     against musl?
> > 
> >     To check if it's been fixed on _android_, they need a bionic version. (I mean
> >     the musl versions will run but all sorts of subtle behavior's different.) 
> > 
> > yeah, i don't know --- Android's seccomp system call filter is pretty narrow and
> > doesn't cover all of the "legacy" system calls that musl probably uses. i
> > suspect arm32 musl doesn't work at all, but arm64 musl might mostly work?
> 
> Rich is fastidious about only using new syscalls when he can get away with it,
> and keeping the set of used syscalls to a minimum. I'd have to ask him what the
> actual set he's using is though.
> 
> But mostly I was thinking that when trying to reproduce a bug, swapping out the
> libc probably shouldn't be part of the standard reproduction sequence. Even when
> the bug isn't in libc, what will/won't trigger it can change.

musl supports running on kernels back to 2.6.0, and historically uses
the earliest/simplest syscall that can provide the needed
functionality for the function being called. However, often it
simplifies code to have older functions implemented in terms of newer
more general ones, and in that case, order usually gets switched
around so that the newer syscall is tried first and the old one is
only used as a fallback if (1) the new one fails with ENOSYS, and (2)
arguments are such that the old syscall is suitable. The next release
is also moving all the socket functions from the multiplexed
socketcall to the newer individual syscalls, with socketcall as a
fallback, not for implementation ease reasons but because the separate
syscalls are the only ones that are filterable with seccomp.

Aside from that, the syscalls used by a particular function are an
implementation detail that can and will change from version to
version, and sometimes these changes are out of necessity to fix a
bug. For example, it often comes up that newly realized
requirements/corner-cases for async-signal-safety, locking corner
cases, fork-related issues, etc. impose a requirement that a function
block signals during some critical section. Another case where this
happens is where it's discovered that there are kernel API bugs or
corner cases the kernel does not handle that need special treatment in
userspace, that require additional syscalls.

Rich