Re: [PATCH] selinux-testsuite: Update binder for kernel 5.4 support

[Paul Moore <paul@paul-moore.com>]

On Mon, Oct 7, 2019 at 11:17 AM Richard Haines
<richard_c_haines@btinternet.com> wrote:
> On Mon, 2019-10-07 at 10:28 -0400, Stephen Smalley wrote:
> > On 10/6/19 4:51 AM, Richard Haines wrote:
> > > Kernel 5.4 commit ca2864c6e8965c37df97f11e6f99e83e09806b1c
> > > ("binder: Add
> > > default binder devices through binderfs when configured"), changed
> > > the way
> > > the binder device is initialised and no longer automatically
> > > generates
> > > /dev/binder when CONFIG_ANDROID_BINDERFS=y.
> >
> > This seems like a userspace ABI break, no?  Same kernel config
> > before
> > and after this commit yields different behavior for /dev/binder.  I
> > suppose one might argue that one would only enable
> > CONFIG_ANDROID_BINDERFS if one wanted to use it instead of
> > /dev/binder
> > but the original commit that introduced binderfs specifically said
> > that
> > backward compatibility was preserved.
> I'll need to check this further, but from what I've seen so far, is
> that the /dev/binder is not available until you mount binderfs etc.
> that's why Paul had the failure on 5.4 as before then is was available
> when the binder driver first initialised.
>
> If indeed the above binder commit is seen as breaking backwards
> compatability, then this patch would not be needed (although it does
> tidy up some areas).

My guess is that the binder folks don't view this as a backwards
compatibility issue since you have to enable binderfs first.  I'm
honestly not sure how many distro kernels, outside Android, enable
this anyway; the secnext kernels explicitly patch the Rawhide kernel
config to enable binder.

> > > These changes implement the following:
> > > Kernel < 5.0 - use /dev/binder that is set by:
> > >      CONFIG_ANDROID_BINDER_DEVICES="binder"
> > > Kernel >= 5.0 - use /dev/binder-test that will be generated by the
> > > test
> > > using binderfs services.
> >
> > So you switch to using binderfs for any kernel that supports it (5.0
> > or
> > later) rather than only at the point where it ceases to be
> > backward-compatible (5.4)?  Not objecting per se, but wanted to
> > clarify
> > the discrepancy between distinguishing based on 5.0 here even though
> > the
> > breaking change doesn't occur until 5.4.
>
> Yes I decided that as I'm only testing binder SELinux, then I would use
> the original /dev/binder on < 5.0 and test binderfs on 5.0+. If you
> would like the tests more specific just let me know (I made the
> assumption that the binder team would have tests for their bits).

When in doubt, I think it is better to assume that there are *no*
tests.  Unfortunately It has been my experience that this holds true
more often than not.

-- 
paul moore
www.paul-moore.com