<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">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 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" class="gmail_signature"><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>