[Toybox] Android binaries?

[enh]

On Mon, Aug 24, 2020 at 9:53 AM Rich Felker <dalias at libc.org> wrote:

> 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.
>

fwiw, i don't think that's actually true. afaik Android and ChromeOS both
do this. looks like there's a CTS test too:

# socketcall: call=={SYS_CONNECT,SYS_SOCKET,SYS_GETSOCKOPT}
socketcall: arg0 == 1 || arg0 == 3 || arg0 == 15; return EPERM

i thought the x86 non-socketcall socket stuff was 3.15 anyway? iirc that's
why we're still using socketcall --- the only x86 device we shipped
ourselves (Nexus Player) had a kernel that was too old.


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20200824/d6211da2/attachment.htm>