[Toybox] [PATCH] losetup: Wait for ueventd to create loop device on Android

[enh]

On Wed, Aug 24, 2022 at 6:04 AM Yi-yo Chiang via Toybox <
toybox at lists.landley.net> wrote:

>
>
> On Wed, Aug 24, 2022 at 7:56 PM Rob Landley <rob at landley.net> wrote:
>
>> On 8/24/22 05:04, Yi-yo Chiang wrote:
>> > Digging through git history and I believe AOSP has been using "tmpfs as
>> /dev"
>> > plus "init and/or ueventd servicing uevents" since at least Android 1.0
>> (circa
>> > 2008,
>> >
>> https://android.googlesource.com/platform/system/core/+/4f6e8d7a00cbeda1e70cc15be9c4af1018bdad53
>>
>> Devtmpfs was introduced in 2009, so it wasn't an option in 2008. Plus it
>> was
>> initially controversial because they had previously done a REALLY STUPID
>> implementation of the concept (I mean just spectacularly bad) that got
>> ripped out:
>>
>> https://lwn.net/Articles/331818/
>>
>> Devtmpfs got cleaned up into something simple and elegant which solves
>> half the
>> problem space of hotplug. It won't _eliminate_ the need for something like
>> ueventd because when a device shows up you often need to do more than
>> just make
>> a /dev node for it. But for the "give me this dev node" case, when you
>> make a
>> syscall() or insmod and a device shows up, it eliminates the race waiting
>> for
>> asynchronous node creation: when the process gets control back, the node
>> is there.
>>
>> > I'm not sure if the 2013 article is outdated, or are AOSP still on its
>> way to
>> > adopt devtmpfs. I'll bounce this question to David (dvander at google.com)
>>
>> It's a bit like the old "is android going to use containers" question.
>> Android
>> predated container support by years so it had to do other things at
>> first, and
>> then had legacy dependencies on those other things. But eventually stuff
>> like
>> minijail started working their way into the stack using container
>> plumbing.
>>
>
> Yeah I guess the situation is not unlike what you just described.
> The original devfs has its fair share of problems, so Android decided not
> to use it. (2008)
> Someone started developing devtmpfs (2009-2013), thinking it might benefit
> Android.
> But by the time devtmpfs reach usable quality, Android already has its
> pre-devtmpfs hack baked into its heart, and it's no trivial work to enable
> devtmpfs on Android now due to all sorts of stuff already depending on the
> current mechanism.
> Of all the things pushing devtmpfs away, I think selinux might be the most
> concerning.
> Status quo works well enough because /dev/... nodes are created by
> userspace daemon, and selinux covers all userspace processes.
> If kernel code is responsible for hot generating files under /dev, then
> selinux must interact with it somehow, which defines a new class of
> problems to solve, I think? (I'm no selinux expert)
> I'm not saying (adopt devtmpfs) can't happen, but anything security
> related must be heavily scrutinized, so this might not happen fast, and
> might not be high on the priority list .
>

like i said in response to a different message, it's actually worse than
that --- we have tried, multiple times, including at least one (but maybe
two?) post-2013 efforts.

(since dvander wasn't cc:ed on the earlier message i replied to, here's a
repeat for context...)

i know a lot of people have _hoped_ to use it and looked at it over the
years, but i don't think it's fit for purpose? the problem (ironically,
given your complaint) is that it doesn't know _enough_ about the system. so
it's racy and init has to run around after it fixing up the stuff (like
selinux labels) that it _doesn't_ set. (iirc it didn't even do regular unix
permissions right?) so if init's got to do _some_ of the work, init may as
well do _all_ of the work so there's no window where you can see a
"half-finished" node.

(and back to new content...)

for googlers https://issuetracker.google.com/233703650 is an interesting
bug where you can see a partner wanting to use devtmpfs and me, dvander's
boss, and "the highest up security guy who still writes code" all saying
roughly this. (it seems like none of us are certain, but we all think it
was some combination of selinux labels and unix permissions.)

what i don't know is how much work devtmpfs would need for us to be able to
use it, or whether we could realistically get that upstreamed. i don't
personally remember anyone trying --- iirc everyone who's looked at this
problem has just judged it "too hard to even try". which is a shame
because, yeah, it does solve _some_ problems. they're just not problems
that _real_ android usage has, at the cost of introducing ones that do
matter to real users. (sorry, yochiang! the fact that you even know what
mount(1) means "you are not the user" :-) )


>
>> To clarify: I'm not pushing back against your patch because I think
>> android
>> should be using devtmpfs instead. I already merged your patch, and expect
>> that
>> to be the status quo for a while. I'm just going "over the next few
>> years, this
>> is a thing you might want to look into". But if you're not already
>> working on
>> it, I wouldn't expect to see it in the next android release or the one
>> after that.
>>
>
> No worries, I understand you were just asking; and I'm also curious, thus
> I CCed David who might know.
>
>
>>
>> Sigh: there's a bunch of stuff I consider obvious that apparently isn't.
>> Back
>> when I made initramfs use tmpfs in 2013 and didn't exactly advertise the
>> benefits of that either. The embedded guys knew but most other people
>> didn't
>> notice. I should do some writeups on the advantages of various bits of
>> plumbing... Eh, throw it on the todo heap.
>>
>> > OTOH I also wouldn't be surprised if some deeply modified Android distro
>> > (wilderness) is already using devtmpfs.
>>
>> A quick google says devtmpfs is initialized in lineageos's boot messages,
>> but
>> who knows what that means?
>>
>> Hotplug has a whole mess of access handoffs to do securely, which I had to
>> understand deeply back when I was doing mdev but that was a decade ago
>> and I'm
>> kind of stale on at this point.
>>
>> "Device insertion" isn't the same as creating a /dev node. New hardware
>> showing
>> up may trigger driver loading which may require an insmod and/or firmware
>> loading. (You could put the firmware in initramfs and solve the license
>> issues
>> by having it be an externally loaded initramfs image, but no, they made a
>> special magic MECHANISM for it. Ugh.) And some devices don't even HAVE
>> /dev
>> nodes (ethernet and wifi, thank you bill joy) and some have multiple
>> nodes for
>> the same device (ala partitioned hard drives), and of course some device
>> nodes
>> don't correspond to hardware at all (/dev/loop0)... This is why the
>> original
>> devfs was horrible even BEFORE it tried to use solaris names for all the
>> devices.
>>
>> Also, devtmpfs doesn't usually create a world readable device, so a
>> hotplug
>> manager may adjust permissions and ownership. (That 2013 article I linked
>> to was
>> about letting drivers select permissions and uid:gid for the new node to
>> show up
>> as, which is a layering violation because THE KERNEL DOES NOT KNOW WHAT
>> ANY UID
>> OR GID OTHER THAN 0 OR 65534 MEAN, but that ship has apparently sailed...)
>>
>> I'm sure I wrote documentation about this, I'm like COMPULSIVE about doing
>> that... Darn it, best I can find is an ancient half-assed version that
>> trails
>> off into notes to self:
>>
>> https://www.kernel.org/doc/local/hotplug-history.html
>>
>> Another failure mode of mine. Sorry.
>>
>> Anyway, the point of all this is devtmpfs solves a specific problem and
>> clears
>> up some nasty races, but it is by no means ALL of hotplug, and
>> reenginering a
>> pre-devtmpfs hotplug solution to NOT create its own /dev nodes requires a
>> design
>> rethink. (Which is why I haven't cycled back around to mdev.c in toybox,
>> because
>> it's not just "finish the code". I started mdev in 2005 and devtmpfs
>> happened in
>> 2009, I ALSO have to redesign bits of my old hotplug layer to not try to
>> redo
>> what devtmpfs already does better, and have too many other things
>> competing for
>> focus.)
>>
>> But with devtmpfs as part of this complete breakfast, race conditions
>> like the
>> one you just patched don't happen as much.
>>
>> Rob
>>
>
>
> --
>
> Yi-yo Chiang
> Software Engineer
> yochiang at google.com
>
> I support flexible work schedules, and I’m sending this email now because
> it is within the hours I’m working today. Please do not feel obliged to
> reply straight away - I understand that you will reply during the hours you
> work, which may not match mine.
> _______________________________________________
> 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/20220824/3702d364/attachment-0001.htm>