<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 24, 2020 at 9:53 AM Rich Felker <<a href="mailto:dalias@libc.org">dalias@libc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Aug 23, 2020 at 11:54:12PM -0500, Rob Landley wrote:<br>
> On 8/21/20 6:36 PM, enh wrote:<br>
> >     I'm writing a "reporting bugs" FAQ entry because of the recent github thread.<br>
> > <br>
> >     I've also had a todo item to salvage todo entries I wrote for busybox forever<br>
> >     ago, especially since the busybox devs crapped all over the current versions.<br>
> >     For example,<br>
> >     <a href="https://git.busybox.net/busybox/tree/docs/busybox.net/FAQ.html?h=95718b309169#n361" rel="noreferrer" target="_blank">https://git.busybox.net/busybox/tree/docs/busybox.net/FAQ.html?h=95718b309169#n361</a><br>
> >     used to be project-agnostic (usable advice no matter what open source project<br>
> >     you were talking about), but in current <a href="https://busybox.net/FAQ.html#backporting" rel="noreferrer" target="_blank">https://busybox.net/FAQ.html#backporting</a><br>
> >     they've inserted a large digression in the middle about configuring busybox<br>
> >     source from the command line to make sure it doesn't apply to any other project<br>
> >     and can't be generally referenced as advice by other projects.<br>
> > <br>
> >     But anyway, the advice was "try to reproduce the bug on a current version before<br>
> >     poking the developers because there's a nonzero chance we already fixed it", and<br>
> >     for linux toybox I can point them at<br>
> >     <a href="https://landley.net/toybox/downloads/binaries" rel="noreferrer" target="_blank">https://landley.net/toybox/downloads/binaries</a> for current versions (even if they<br>
> >     don't want to build it from source for their target)... but those are linked<br>
> >     against musl?<br>
> > <br>
> >     To check if it's been fixed on _android_, they need a bionic version. (I mean<br>
> >     the musl versions will run but all sorts of subtle behavior's different.) <br>
> > <br>
> > yeah, i don't know --- Android's seccomp system call filter is pretty narrow and<br>
> > doesn't cover all of the "legacy" system calls that musl probably uses. i<br>
> > suspect arm32 musl doesn't work at all, but arm64 musl might mostly work?<br>
> <br>
> Rich is fastidious about only using new syscalls when he can get away with it,<br>
> and keeping the set of used syscalls to a minimum. I'd have to ask him what the<br>
> actual set he's using is though.<br>
> <br>
> But mostly I was thinking that when trying to reproduce a bug, swapping out the<br>
> libc probably shouldn't be part of the standard reproduction sequence. Even when<br>
> the bug isn't in libc, what will/won't trigger it can change.<br>
<br>
musl supports running on kernels back to 2.6.0, and historically uses<br>
the earliest/simplest syscall that can provide the needed<br>
functionality for the function being called. However, often it<br>
simplifies code to have older functions implemented in terms of newer<br>
more general ones, and in that case, order usually gets switched<br>
around so that the newer syscall is tried first and the old one is<br>
only used as a fallback if (1) the new one fails with ENOSYS, and (2)<br>
arguments are such that the old syscall is suitable. The next release<br>
is also moving all the socket functions from the multiplexed<br>
socketcall to the newer individual syscalls, with socketcall as a<br>
fallback, not for implementation ease reasons but because the separate<br>
syscalls are the only ones that are filterable with seccomp.<br></blockquote><div><br></div><div>fwiw, i don't think that's actually true. afaik Android and ChromeOS both do this. looks like there's a CTS test too:</div><div><br></div><div># socketcall: call=={SYS_CONNECT,SYS_SOCKET,SYS_GETSOCKOPT}<br>socketcall: arg0 == 1 || arg0 == 3 || arg0 == 15; return EPERM<br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Aside from that, the syscalls used by a particular function are an<br>
implementation detail that can and will change from version to<br>
version, and sometimes these changes are out of necessity to fix a<br>
bug. For example, it often comes up that newly realized<br>
requirements/corner-cases for async-signal-safety, locking corner<br>
cases, fork-related issues, etc. impose a requirement that a function<br>
block signals during some critical section. Another case where this<br>
happens is where it's discovered that there are kernel API bugs or<br>
corner cases the kernel does not handle that need special treatment in<br>
userspace, that require additional syscalls.<br>
<br>
Rich<br>
</blockquote></div></div>