[Toybox] getrandom(2)

[Rob Landley]

On 07/06/2018 09:55 PM, enh wrote:
> 
> 
> On Fri, Jul 6, 2018, 18:15 Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 07/06/2018 03:14 PM, enh wrote:
>     > i'm not sure getrandom(2) is a good choice for a compile-time probe.
>     > certainly on Android it's common for your libc to be way ahead of your
>     > kernel.
> 
>     Hmmm. I didn't expect that. (libc provides a syscall wrapper for a syscall your
>     kernel doesn't have. Ok...)
> 
> Isn't musl the same? 

I have a longstanding argument with Rich about fork() being compile-time
probeable on nommu systems. Hence the MUSL_NOMMU_IS_BROKEN entry in Config.in.

The /dev/urandom fallback isn't a bad mitigation. The "this is a nommu system,
it _CAN'T_USE_NORMAL_ELF_BINARIES_, why are you pretending we're going to probe
for behavior differences _AT_RUNTIME_, and then needing to re-exec your own
binary when you forked (because vfork blocks the parent thread) and not being
able to reliably do so (/proc/self/exe isn't necessarily there in a chroot)
although I asked the kernel developers for a new API to make it suck less and I
should really test https://patchwork.kernel.org/patch/9949557/ but then it's
another new kernel api still requiring a fallback for 7 years of legacy support"...

Ahem. Can of worms.

>     Hmmm... I can't compile time probe for what the syscalls return because cross
>     compiling (and potentially deploying on a different kernel), and I don't want to
>     make the fallback code ubiquitous because embedded. Hmmm...
> 
> Why not?

I dislike having code that shouldn't be used built in. (I'm kinda unhappy about
having multiple codepaths do the same thing, having explicit config knobs to
test themand a plan to make one go away eventually mitigates it. You'll note it
took me this long to do it, even though I've known about it since
http://lists.busybox.net/pipermail/busybox/2016-June/084336.html or so.

>     I suppose I could make the fallback code's presence depend on
>     CONFIG_TOYBOX_ANDROID?
> 
>     > in this specific case, on Android getrandom(2) is very likely
>     > to return ENOSYS. for the arc4random functions (from BSD) we'll try
>     > getrandom but fall back to open/read/close. seems like xgetrandom
>     > might be better off doing that, on the assumption that folks will try
>     > to use prebuilts on old devices/hosts?
> 
>     Whereas on glibc I have the exact _opposite_ problem, 'FATAL: kernel too old" in
>     the library loader or entry code, because glibc checks the kernel version and
>     refuses to run on one older than it was built on. (I.E. gnu/dammit anything is
>     insane, part several thousand something.)
> 
> Oh, weird. I didn't know that. My Linux hosts usually have the opposite problem
> of a kernel years newer than their libc. 

Bask in the horror:

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/dl-osinfo.h;h=416ef93c477170569dcf16f5b9e8ab63fd5c3da6;hb=HEAD#l29

> I was actually assuming you'd be best off just removing the compile time check
> and using syscall(3). Wouldn't that be best for your musl prebuilts? And still
> work fine for glibc. 

What I'm thinking is once the system call is 7 years old I can just assume it's
there and remove the probe and the fallback code. The man page says it was added
to the 3.17 kernel which was released October 2014, so a little over 3 years
from now.

It's more that the existence of the CONFIG symbol is likely to remind me to
remove the fallback workaround someday, whereas if I just have it there in
portability.c it's more likely to fall off my todo list. (I see the menuconfig
contents more often.)

If the need for the fallback was _never_ going to go away, I'd probably just
leave it reading from /dev/urandom as the One True Codepath that works
everywhere. "Simple" is a local minima affected by ambient topology. :)

>     Rob

Rob