[Toybox] Android binaries?
Rich Felker
dalias at libc.org
Mon Aug 24 10:11:05 PDT 2020
On Mon, Aug 24, 2020 at 10:03:11AM -0700, enh wrote:
> On Mon, Aug 24, 2020 at 9:53 AM Rich Felker <dalias at libc.org> wrote:
> >
> > 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.
The arguments to socketcall are all in a buffer in memory, which can
be changed asynchronously by another task with access to the memory
(i.e. any other thread in the process). Thus there is no security
property obtained by performing filtering on them; at best you can
prevent casual unintended behavior.
Rich
More information about the Toybox
mailing list