On Mon, Aug 24, 2020 at 9:53 AM Rich Felker <dal...@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 >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net