<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 24, 2022 at 6:04 AM Yi-yo Chiang via Toybox <<a href="mailto:toybox@lists.landley.net">toybox@lists.landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 24, 2022 at 7:56 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/24/22 05:04, Yi-yo Chiang wrote:<br>
> Digging through git history and I believe AOSP has been using "tmpfs as /dev"<br>
> plus "init and/or ueventd servicing uevents" since at least Android 1.0 (circa<br>
> 2008,<br>
> <a href="https://android.googlesource.com/platform/system/core/+/4f6e8d7a00cbeda1e70cc15be9c4af1018bdad53" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/system/core/+/4f6e8d7a00cbeda1e70cc15be9c4af1018bdad53</a><br>
<br>
Devtmpfs was introduced in 2009, so it wasn't an option in 2008. Plus it was<br>
initially controversial because they had previously done a REALLY STUPID<br>
implementation of the concept (I mean just spectacularly bad) that got ripped out:<br>
<br>
<a href="https://lwn.net/Articles/331818/" rel="noreferrer" target="_blank">https://lwn.net/Articles/331818/</a><br>
<br>
Devtmpfs got cleaned up into something simple and elegant which solves half the<br>
problem space of hotplug. It won't _eliminate_ the need for something like<br>
ueventd because when a device shows up you often need to do more than just make<br>
a /dev node for it. But for the "give me this dev node" case, when you make a<br>
syscall() or insmod and a device shows up, it eliminates the race waiting for<br>
asynchronous node creation: when the process gets control back, the node is there.<br>
<br>
> I'm not sure if the 2013 article is outdated, or are AOSP still on its way to<br>
> adopt devtmpfs. I'll bounce this question to David (<a href="mailto:dvander@google.com" target="_blank">dvander@google.com</a>)<br>
<br>
It's a bit like the old "is android going to use containers" question. Android<br>
predated container support by years so it had to do other things at first, and<br>
then had legacy dependencies on those other things. But eventually stuff like<br>
minijail started working their way into the stack using container plumbing.<br></blockquote><div><br></div><div>Yeah I guess the situation is not unlike what you just described.</div><div>The original devfs has its fair share of problems, so Android decided not to use it. (2008)</div><div>Someone started developing devtmpfs (2009-2013), thinking it might benefit Android.</div><div>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.</div><div>Of all the things pushing devtmpfs away, I think selinux might be the most concerning. </div><div>Status quo works well enough because /dev/... nodes are created by userspace daemon, and selinux covers all userspace processes.</div><div>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)<br></div><div>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 . </div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>(since dvander wasn't cc:ed on the earlier message i replied to, here's a repeat for context...)</div><div><br></div><div>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.<br></div><div><br></div><div>(and back to new content...)</div><div><br></div><div>for googlers <a href="https://issuetracker.google.com/233703650">https://issuetracker.google.com/233703650</a> 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.)</div><div><br></div><div>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" :-) )</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
To clarify: I'm not pushing back against your patch because I think android<br>
should be using devtmpfs instead. I already merged your patch, and expect that<br>
to be the status quo for a while. I'm just going "over the next few years, this<br>
is a thing you might want to look into". But if you're not already working on<br>
it, I wouldn't expect to see it in the next android release or the one after that.<br></blockquote><div><br></div><div>No worries, I understand you were just asking; and I'm also curious, thus I CCed David who might know.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Sigh: there's a bunch of stuff I consider obvious that apparently isn't. Back<br>
when I made initramfs use tmpfs in 2013 and didn't exactly advertise the<br>
benefits of that either. The embedded guys knew but most other people didn't<br>
notice. I should do some writeups on the advantages of various bits of<br>
plumbing... Eh, throw it on the todo heap.<br>
<br>
> OTOH I also wouldn't be surprised if some deeply modified Android distro<br>
> (wilderness) is already using devtmpfs.<br>
<br>
A quick google says devtmpfs is initialized in lineageos's boot messages, but<br>
who knows what that means?<br>
<br>
Hotplug has a whole mess of access handoffs to do securely, which I had to<br>
understand deeply back when I was doing mdev but that was a decade ago and I'm<br>
kind of stale on at this point.<br>
<br>
"Device insertion" isn't the same as creating a /dev node. New hardware showing<br>
up may trigger driver loading which may require an insmod and/or firmware<br>
loading. (You could put the firmware in initramfs and solve the license issues<br>
by having it be an externally loaded initramfs image, but no, they made a<br>
special magic MECHANISM for it. Ugh.) And some devices don't even HAVE /dev<br>
nodes (ethernet and wifi, thank you bill joy) and some have multiple nodes for<br>
the same device (ala partitioned hard drives), and of course some device nodes<br>
don't correspond to hardware at all (/dev/loop0)... This is why the original<br>
devfs was horrible even BEFORE it tried to use solaris names for all the devices.<br>
<br>
Also, devtmpfs doesn't usually create a world readable device, so a hotplug<br>
manager may adjust permissions and ownership. (That 2013 article I linked to was<br>
about letting drivers select permissions and uid:gid for the new node to show up<br>
as, which is a layering violation because THE KERNEL DOES NOT KNOW WHAT ANY UID<br>
OR GID OTHER THAN 0 OR 65534 MEAN, but that ship has apparently sailed...)<br>
<br>
I'm sure I wrote documentation about this, I'm like COMPULSIVE about doing<br>
that... Darn it, best I can find is an ancient half-assed version that trails<br>
off into notes to self:<br>
<br>
<a href="https://www.kernel.org/doc/local/hotplug-history.html" rel="noreferrer" target="_blank">https://www.kernel.org/doc/local/hotplug-history.html</a><br>
<br>
Another failure mode of mine. Sorry.<br>
<br>
Anyway, the point of all this is devtmpfs solves a specific problem and clears<br>
up some nasty races, but it is by no means ALL of hotplug, and reenginering a<br>
pre-devtmpfs hotplug solution to NOT create its own /dev nodes requires a design<br>
rethink. (Which is why I haven't cycled back around to mdev.c in toybox, because<br>
it's not just "finish the code". I started mdev in 2005 and devtmpfs happened in<br>
2009, I ALSO have to redesign bits of my old hotplug layer to not try to redo<br>
what devtmpfs already does better, and have too many other things competing for<br>
focus.)<br>
<br>
But with devtmpfs as part of this complete breakfast, race conditions like the<br>
one you just patched don't happen as much.<br>
<br>
Rob<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><table width="90%" border="0" cellspacing="0" cellpadding="0" style="margin:0px;padding:0px;font-family:"Times New Roman";max-width:348px"><tbody style="margin:0px;padding:0px"><tr style="margin:0px;padding:0px"><td style="padding:0px"><table border="0" cellspacing="0" cellpadding="0" style="margin:0px;padding:20px 0px 0px"><tbody style="margin:0px;padding:0px"><tr style="margin:0px;padding:0px"><td valign="top" style="padding:0px 20px 0px 0px;vertical-align:top;border-right:1px solid rgb(213,213,213)"><img src="https://i.imgur.com/eGpkLls.png" width="200" height="64"><br></td><td style="padding:0px 0px 0px 20px"><table border="0" cellspacing="0" cellpadding="0" style="margin:0px;padding:0px"><tbody style="margin:0px;padding:0px"><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:1px 0px 5px;font-size:13px;line-height:13px;color:rgb(56,58,53);font-weight:700">Yi-yo Chiang</td></tr><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:0px 0px 5px;font-size:11px;line-height:13px;color:rgb(56,58,53)">Software Engineer</td></tr><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:0px 0px 5px;font-size:11px;line-height:13px;color:rgb(56,58,53)"><a href="mailto:yochiang@google.com" target="_blank">yochiang@google.com</a></td></tr><tr style="margin:0px;padding:0px"><td colspan="2" style="font-family:Arial,Helvetica,Verdana,sans-serif;padding:0px 0px 3px;font-size:11px;line-height:13px;color:rgb(3,112,248)"></td></tr></tbody></table></td></tr></tbody></table></td></tr></tbody></table><div><font size="1">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.</font><br></div></div></div></div>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div>