ls -1 /dev/{ashmem，联编程序}产生/dev/ashmem的预期结果，但对/dev/binder产生错误

Question

背景

在另一个帖子中，我报告说：

我在UEFI系统上运行Ubuntu20.04.1，默认内核5.4.0-42-泛型(从Main安装)。我希望加载两个内核模块("ashmem“和"binder")，并启用安全引导。至少对我来说，在启用安全启动的情况下，“绑定器”加载得很好，但是"ashmem“没有在启用安全启动的情况下加载。这两个模块加载安全启动禁用。

对于上面的内容，我要补充的是，在Ubuntu20.04的初始清洁安装过程中，我已经启用了安全启动(并注册了MOK)。尽管如此，按照林茨风提供的优秀建议，我在初始安装之后运行了以下命令：

sudo kmodsign sha512 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der /lib/modules/`uname -r`/kernel/drivers/staging/android/ashmem_linux.ko

在运行上述程序之后，我重新运行：

sudo modprobe ashmem_linux

sudo modprobe binder_linux

lsmod | grep -e ashmem_linux -e binder_linux

成功！“灰烬”和“活页夹”都装好了！谢谢林茨风!！

而且，安波克现在为我启动时启用了安全启动，这是我的最终目标。:)

错误消息

虽然“ashmem”和“binder”现在都加载了，而且安波克现在已经启动(并且似乎正常工作)，但现在启用了安全引导，我仍然运行了以下代码：

ls -1 /dev/{ashmem,binder}

我得到了以下信息：

ls: cannot access '/dev/binder': No such file or directory
/dev/ashmem

现在，我仍然很好奇为什么要获得关于“binder”模块的上述错误(“无法访问'/dev/binder'：没有这样的文件或目录”)，以及是否应该关注。

问题

1. 是否应该在加载“binder”模块时创建/dev/binder？(这个错误应该引起我的关注吗？)
2. 如果在加载“binder”模块时应该创建/dev/binder，我如何强制/dev/binder创建？
3. 如果在加载“binder”模块时应该创建/dev/binder (也就是说，如果我发现了一个bug)，那么在Launchpad上应该报告错误吗？

根据lsmod的说法，重申“ashmem”和“binder”负载。而且，安波克现在似乎在安全启动的情况下为我正常工作。我贴在这里是为了(a)满足我自己的好奇心，(b)为其他人记录这件事，(c)确定是否应该提交关于活页夹的错误报告(如果需要的话，在哪里存档)。

Answer 1

更仔细地回顾Anbox的安装页面，我注意到以下内容：

在Ubuntu19.10中，绑定器驱动程序在加载时不会创建/dev/binder。这是故意的。相反，它提供了对binderfs (请参阅https://brauner.github.io/2019/01/09/android-binderfs.html)的支持，这是因为PR收件箱/收件箱#1309

虽然上面并没有具体提到Ubuntu20.04的情况，但我猜想这也适用于它。考虑到这一点，下面是对我自己问题的拟议答案：

1. 不，不应该在加载“binder”模块时创建/dev/binder。(错误消息不应该让我担心。)
2. 没有必要(也可能没有办法)强制创建/dev/binder。
3. 没有必要在Launchpad (或其他地方)上报告此错误。

如果有人想提供另一个(更好的)答案，请随意这样做。我将把这个问题保留几天，但是如果在接下来的几天内我没有看到任何其他的答案/评论，我会把它标记成答案。:)

Answer 2

不知道为什么/dev/binder不是在加载binder_linux时自动创建的。但是，手动创建它是可能的(显然是使用sudo或root )。

mkdir /dev/binder
mount -t binder binder /dev/binder

我跟随了这篇文章，这让我成功了。