On Wednesday, 29 March 2023 22:59:13 CEST Diederik de Haas wrote: > Control: reopen -1 > > On Tuesday, 21 March 2023 14:21:05 CEST Debian Bug Tracking System wrote: > > > In https://github.com/waydroid/waydroid/issues/811 I asked 'upstream' > > > for recommendations on which/how/what kernel modules to enable. > > > > In https://git.kernel.org/linus/9e18d0c82f0c07f2a41898d4adbb698a953403ee > > the default value of BINDER_DEVICES was changed to > > "binder,hwbinder,vndbinder" whereas the Debian kernel only has "binder". > > Also in other places they use the 3 values, but I haven't been able to > > find out *why*. > > As I wouldn't be able to make the argument to change it to something else > > and the most important thing is to enable ANDROID_BINDER_IPC, which is > > already the case, there's no need to keep this bug open. > > > > If someone *can* substantiate why and how things should be changed, they > > should file a bug report (themselves) making the case. > > Just received an (unexpected) extra response, which DOES answer the Q I had: > > "BINDER_DEVICES defines which binder device names should appear in /dev. > Different android versions required different devices to be available: the > latest android version uses "binder,hwbinder,vndbinder" meaning /dev/binder, > / dev/hwbinder, /dev/vndbinder. > At some point Google realized that it's inconvenient to have this change at > compile time, so they introduced BINDERFS: you can mount a filesystem of > type binder somewhere and use IOCTLs on it to allocate new device names. > > So if you use BINDERFS it doesn't matter which value of BINDER_DEVICES you > set because you can add (or remove) devices at runtime. In this case > BINDER_DEVICES is just the set of initial devices present in the root of a > binderfs. > > For mainline linux, BINDERFS is heavily recomended. Waydroid will use it to > create all the binder devices it needs. You can leave BINDER_DEVICES empty > or unchanged or whatever you prefer." > > I don't really understand how or what `ioctl`s are, but I'm pretty sure > others do and can now make an informed choice if and how things could be > improved. I'm pretty sure that'll be for Trixie, which has the nice benefit > that it can be extensively tested. Possibly unintentional, but another reply came in with a valid point AFAICT: "That caught me by surprise because I knew Waydroid worked on bullseye already, and it has the same CONFIGs. Then I finally realized... When you compile binder as a module (rather than built-in), when inserting the module you can provide the binder device names you want in the module parameters! So in this case `CONFIG_BINDER_DEVICES="binder"` is not a limitation." Is this an intended feature or a security concern? The patch description which turned the module from a `bool` into a `tristate` explicitly mentioned security as a reason so that the module would ONLY be loaded when needed, instead of always for everyone ... for security reasons.
Attachment:
signature.asc
Description: This is a digitally signed message part.