[Toybox] runcon requires CONFIG_TOYBOX_NORECURSE=y

[Rob Landley]

On 01/19/2016 04:07 PM, enh wrote:
>> A number of commands don't even have _attempts_
>> at TOYBOX_FREE exit cleanup code yet.
> 
> personally i care a lot less about leaks than i do about reading
> uninitialized memory (like the recent ls case).
> 
> (interestingly, although Android's debug malloc's leak detection has a
> special "give up on mksh, it's hopeless" special case, there isn't one
> for toybox. no one's brought that up yet.)

Over in my Aboriginal Linux project I've had my nose recently rubbed in
the need to start work on toysh (hush is crap, ash doesn't support
nommu, and bash 2.05b from the dawn of time is coming to the end of its
usefulness), and one of the things the recent utf8 fontmetrics stuff
applies to is command line history, so that can of worms is likely to
get opened this year. (I should do test.c first...)

I rely on exit() to free certain kinds of allocations, but things like
patch and sed can't leak memory from their main loop because they may
apply to an arbitrarily large file (or arbitrarily large number of
files, etc).

Programs that run arbitrarily long like servers and shells, also have
the same constraints. I expect toysh to have the full CFG_TOYBOX_FREE
stuff and have its allocations be auditable because I myself may
(eventually) want to audit them.

>> For example I'm implementing top
>> right now and noticing that iotop (which I'm mergeing with it) doesn't
>> free its process arrays on exit. If you run run iotop from within a
>> bootloader, it would have to. Right now, that's a blue sky todo item,
>> but is it important to somebody...? I got a "please prioritize xz
>> decompress" email last week, but haven't had anybody ping me about
>> bootloaders.
> 
> ps/top are the two remaining big-ticket items as far as i'm concerned.
> i haven't been saying anything (or sending any patches recently)
> because it seems too much "under construction" at the moment.

I'm trying to cut a release at the end of the month, and I want all the
pending ps.c work to be in that release, so I'm doing it now...

> i'm
> assuming you'll finish after i can make changes in N but before N
> ships, so i'll fix up anything still broken at that time and then
> switch us over for O (but still probably before N ships).

There's a lot of shared infrastructure between ps, top, iotop, pgrep,
pkill, and possibly another command or two. There are too MANY commands
in here (more than I'm confortable with in one toys/*/*.c file), but I'm
not sure how to break out a chunk to go in lib/ here. They all share
struct typography typos[], and the magic ordering in the slot[] array
(mostly but not entirely derived from /proc/$$/stat)...

I should probably make another TAGGED_ARRAY with SLOT_pid and SLOT_ppid
and so on to index the slot[] array (possibly invent a
NAMELESS_TAGGED_ARRAY so the actual struct doesn't need a char *name at
the start since we only want the macros, not the char * strings).

But shared_match_process() is referencing TT fields, those need to
become a struct or something I could break out and embed in the various
commands' GLOBALS() blocks. And that struct would also need to include
TT.bits used by get_ps(), and then there's string_field() and parse_ko()
that are shared between these commands...

At some point after I finish top, I need to I need to do a pass making a
lib/procpid.c, then I can break the hairball up into ps.c, top.c, and
pgrep.c with no more than a couple commands in each...

And that should be the stopping point to cut a release. :)

>> Then again I didn't even know the cyanogenmod guys had
>> switched to toybox until I stumbled accross it in an unrelated google
>> search, and they've got a whole tree of changes for building on macosx.
>> Why? I dunno. Not sure how to ask them...)
> 
> they track AOSP, so us switching to toybox switches them.

Yes and no, they were layering busybox on top and have apparently stopped:

http://review.cyanogenmod.org/#/c/119819/1

Except toybox isn't a 100% replacement for busybox yet. (I'm working on
it!) So losing the bits of busybox toybox doesn't do yet is painful for
them:

https://plus.google.com/+OpengappsOrg/posts/FJ2v1kNxzHV

I did:

  git clone https://github.com/CyanogenMod/android_external_toybox
  cd android_external_toybox
  git fetch https://android.googlesource.com/platform/external/toybox \
    master:android
  git log android..cm-13.0 --no-merges

And there's a number of commits (like "fix remount") that seem of
general interest. Haven't heard a thing about them here, of course, but
I might take a look and see what portion of this is real. (I note that
the later installs following a symlink to overwrite the toybox binary is
why I made toybox install itself read-only.

As for toybox stomping other package's binaries, I'd like it to use
--remove-destination but I'm not _quite_ sure that's supported on all
the systems it would be installing on? (It's a nonstandard extension. I
suppose I could do rm then cp...)

> i've no idea
> what they're doing with Mac OS though. the AOSP makefile doesn't try
> to build toybox for the host.

They're #ifdeffing out the LSB headers, for one thing. I posted about
that here a week or so back.

> long-term i'd like to stop checking in
> the generated files, and that would require me to build at least those
> tools on the host, but trying to fit what you do into our build system
> seems sufficiently painful that i'll probably never get around to it
> unless someone volunteers.

I might volunteer, but I need to take apart the android build system
first. :)

I probably need to write a section in code.html enumerating what make.sh
does. (I might need to break code.html up a code/make.html and
code/lib.html and code/main.html so on. I know I need to add sections on
lib/interestingtimes.c and lib/linestack.c, and probably move the comma
stuff out of lib/getmountlist.c into its own file...)

But for right now, I need to finish top. :)

Rob