[Toybox] getrandom(2)

[enh]

On Fri, Jul 6, 2018, 18:15 Rob Landley <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?

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

Lemme try a fix... ok, how's that?
>

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.

Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20180706/569a423b/attachment.htm>