[Toybox] [PATCH] Android moved the scheduler policy functions in Q.

[Rob Landley]

On 5/2/19 12:37 PM, enh wrote:
> On Thu, May 2, 2019 at 9:35 AM Rob Landley <rob at landley.net> wrote:
>>
>> On 5/1/19 5:40 PM, enh via Toybox wrote:
>>> They're forwarded to libprocessgroup, but we may as well go straight to
>>> the source since neither library is in the NDK anyway.
>>>
>>> This code is unfortunate because it means that even `toybox true` ends
>>> up pulling in a JSON parser at runtime, because ps might call
>>> get_sched_policy/get_sched_policy_name. I'll experiment with
>>> dlopen-on-demand in portability.c and see whether the savings are
>>> worthwhile, but for now at least use the current library directly so we
>>> can save *one* dlopen!
>>
>> I'm as-needed in the linker but glibc defeated that by having librt pull in
>> libpthread when clock_gettime() has been part of glibc proper since the 2.17
>> release ~7 years ago.
> 
> does as-needed actually help when you're built RELRO? certainly
> Android does everything up front for RELRO (which has been mandatory
> for years). i don't know what glibc does, but i do know that my linux
> boxes are at least using partial RELRO these days.

I have no idea, compilers and optimization are moving targets, and I just
updated off of Ubuntu April 2014 edition last month. :)

That said, a V=1 build for defconfig on devuan has:

  -Wl,--as-needed -lutil -lcrypt -lm -lresolv -lz

resulting in:

$ ldd toybox
	linux-vdso.so.1
	libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
	/lib64/ld-linux-x86-64.so.2

So it's dropping out zlib, libresolv, libm, and libutil since it didn't
compile-time resolve anything out of them, so with the default flags at least it
still works?

Lemme look up what relro does...

https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro

Ah. It's the opposite of lazy binding, mark PLT and GOT read only once they've
been resolved. Yeah, pretty obvious. That should mostly just be a question for
the dynamic linker, not the compile-time linker, I'd think? I don't see why
--as-needed at compile time would stop working, since that's _resolved_ at
compile time. (It says don't generate the ELF references for libraries it didn't
need any symbols from.)

>> Meanwhile, Android seem to have reinvented the microkernel again and turned
>> everything in the world into message passing:
>>
>> https://security.googleblog.com/2019/03/open-sourcing-sandboxed-api.html
> 
> (fwiw, i think that's Chrome. certainly nothing to do with us.)

Oh good. (I'd eventually like to make _that_ support a development environment
too, but one bite of the elephant at a time...)

Rob