All of lore.kernel.org
 help / color / mirror / Atom feed
From: Todd Kjos <tkjos@google.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Todd Kjos <tkjos@android.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	selinux@vger.kernel.org,
	"open list:ANDROID DRIVERS" <devel@driverdev.osuosl.org>
Subject: Re: v5.1-rc1 binder_alloc_do_buffer_copy() BUG_ON triggered by selinux-testsuite
Date: Tue, 19 Mar 2019 18:08:10 -0700	[thread overview]
Message-ID: <CAHRSSEyKaV5a6C5fBV8NDm02Cxu2DfVsA7YbbEE8CDkn68KtzA@mail.gmail.com> (raw)
In-Reply-To: <CAHRSSEwM+XXxzxabmiPBEt=t80Jes16yjJhHhsOtGy4meYu2mw@mail.gmail.com>

Paul,

Looking at a snippet of the test output:

    Service Provider read_consumed: 8
    Service Provider command: BR_NOOP
    Service Provider command: BR_FAILED_REPLY  <-------------- the txn
failed as expected.
    Manager read_consumed: 8
    Manager command: BR_NOOP
    Manager command: BR_TRANSACTION_COMPLETE
    not ok 3
        <--------- but for some reason didn't exit(103)
    #   Failed test at ./test line 56.

It looks like the test script expects test_binder to fail with
exit(103) after processing the Server Provider commands. It's not
clear why it didn't, since the return of a BR_FAILED_REPLY for that
transaction should have executed this code (line 392 of
test_binder.c):

    if (cmd == BR_FAILED_REPLY ||
        cmd == BR_DEAD_REPLY ||
        cmd == BR_DEAD_BINDER) {
        fprintf(stderr,
                  "Failed response from Service Provider using Managers FD\n");
        exit(103);
    }

Could this be an issue with the test? At least it doesn't look like a
transaction is succeeding when it shouldn't.

-Todd

On Tue, Mar 19, 2019 at 5:15 PM Todd Kjos <tkjos@google.com> wrote:
>
> [...]
>
> > > Is there a public dashboard where I can take a look at those binder failures?
> >
> > Not really.  I send test results to a not-yet-publicized mailing list,
> > but there is more detail in the GitHub issue below (my last comment
> > has the verbose test output):
> >
> > * https://github.com/SELinuxProject/selinux-kernel/issues/46
> >
>
> Ok, so it looks like something was introduced that causes binder to be
> too permissive (test 3 transaction succeeded when failure is
> expected). I don't know of any recent binder changes that could have
> caused that.
>
> It will take me a while to set up this test environment. Is this easy
> for you to run? Any chance of bisecting or at least trying a few
> versions to narrow it down? Here's a list of the recent patchset -- it
> would be useful to know which caused it (or if none of them did):
>
> 9e98c678c2d6a Linux 5.1-rc1
> ...
> 26528be6720bb binder: fix handling of misaligned binder object
> bde4a19fc04f5 binder: use userspace pointer as base of buffer space
> c41358a5f5217 binder: remove user_buffer_offset
> db6b0b810bf94 binder: avoid kernel vm_area for buffer fixups
> 7a67a39320dfb binder: add function to copy binder object from buffer
> 8ced0c6231ead binder: add functions to copy to/from binder buffers
> 1a7c3d9bb7a92 binder: create userspace-to-binder-buffer copy function
> ...
> 1c163f4c7b3f6 (tag: v5.0) Linux 5.0
>
> Thanks,
>
> -Todd

  reply	other threads:[~2019-03-20  1:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-18 21:31 v5.1-rc1 binder_alloc_do_buffer_copy() BUG_ON triggered by selinux-testsuite Paul Moore
2019-03-18 22:50 ` Todd Kjos
2019-03-18 23:02   ` Paul Moore
2019-03-19 16:50     ` Todd Kjos
2019-03-19 19:33       ` Paul Moore
2019-03-19 22:08         ` Paul Moore
2019-03-19 22:16           ` Todd Kjos
2019-03-19 22:20             ` Paul Moore
2019-03-20  0:15               ` Todd Kjos
2019-03-20  1:08                 ` Todd Kjos [this message]
2019-03-20  3:04                   ` Paul Moore
2019-03-20 15:54                     ` Todd Kjos
2019-03-20 19:50                       ` Todd Kjos
2019-03-20 20:06                         ` Todd Kjos
2019-03-20 23:23                         ` Paul Moore
2019-03-20 23:26                           ` Todd Kjos
2019-03-20 23:34                             ` Paul Moore
2019-03-21  9:50                             ` Ondrej Mosnacek
2019-03-21 15:48                               ` Todd Kjos
2019-03-21 20:24                                 ` Paul Moore
2019-03-20 22:25                       ` Paul Moore
2019-03-20 22:29                         ` Todd Kjos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHRSSEyKaV5a6C5fBV8NDm02Cxu2DfVsA7YbbEE8CDkn68KtzA@mail.gmail.com \
    --to=tkjos@google.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=tkjos@android.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.