Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <000000000000143de7059d2ba3e5@google.com> <000000000000fdbd71059d32a906@google.com>
 <CAHC9VhS_Bfywhp+6H03bY7LrQsBz+io672pSS0DpiZKFiz4L6g@mail.gmail.com>
 <850873b8-8a30-58e5-ad3c-86fb35296130@tycho.nsa.gov> <CAFqZXNuxFTKXVZDpPGCTHifn_AeCdVmP+PZrMDKDOYiLOWtsUA@mail.gmail.com>
 <CAHC9VhR9a1xEB3gXUkb4KRVkwXUAo-701ZumN2OTOmJ7r5ez8g@mail.gmail.com>
 <CAFqZXNv77JHa-6BPzEomZaj2uJqGrBRXrK68cTL0N0--Kz_PkA@mail.gmail.com> <CAHC9VhTHUjdYujta-bOd=AG+XLic6rAZbp2sEpC86vVnpkmBVA@mail.gmail.com>
In-Reply-To: <CAHC9VhTHUjdYujta-bOd=AG+XLic6rAZbp2sEpC86vVnpkmBVA@mail.gmail.com>
From:   Ondrej Mosnacek <omosnace@redhat.com>
Date:   Mon, 3 Feb 2020 09:46:51 +0100
Message-ID: <CAFqZXNviT4NRyE=CkiQdNy0DRfAi6pV-u=RcJhmMooDuPNhwRw@mail.gmail.com>
Subject: Re: possible deadlock in sidtab_sid2str_put
To:     Paul Moore <paul@paul-moore.com>
Cc:     Stephen Smalley <sds@tycho.nsa.gov>,
        Jeff Vander Stoep <jeffv@google.com>,
        Eric Paris <eparis@parisplace.org>,
        Jann Horn <jannh@google.com>,
        Kees Cook <keescook@chromium.org>,
        Linux kernel mailing list <linux-kernel@vger.kernel.org>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        SElinux list <selinux@vger.kernel.org>,
        syzkaller-bugs@googlegroups.com,
        syzbot <syzbot+61cba5033e2072d61806@syzkaller.appspotmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jan 28, 2020 at 6:29 PM Paul Moore <paul@paul-moore.com> wrote:
> On Tue, Jan 28, 2020 at 11:31 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > ... the current rawhide 5.5.0-1 kernel seems to have some bug
> > that prevents it from booting on anything with more than one core.
> > I'll see if I can work around it somehow...
>
> I'm not sure how you are building your kernels, but gcc v10 is causing
> a lot of problems, I would suggest compiling with an earlier gcc for
> the near future until things get sorted (I'm doing the kernel-secnext
> builds on stable Fedora, not Rawhide, for now).

Right, thanks, I was using the Rawhide buildroot to build the test
kernel (derived from Rawhide dist-git source + selinux-next + the
patch). Fortunately the Rawhide kernel can be also built against the
f31 target without any additional hacks, so I managed to build a an
upstream-based kernel with GCC 9 and it didn't have the
crash-on-multi-core issue. Regardless, I wasn't able to reproduce the
syzbot crash locally, so I had to ask syzbot to test the patch from my
git tree [1] and it passed.

Nonetheless, I checked to see how the sidtab string cache + IRQ-safe
locking (assuming mostly cache hits) compares to the non-cache
situation with a category-free label
(unconfined_u:unconfined_r:unconfined_t:s0) and the cache (3.2% impact
when mostly hits) is still faster than the non-cache version (5.5%
impact best case, 65% impact worst case).

I intend to incorporate all this information into the log message and
then post the patch.

[1] https://groups.google.com/d/msg/syzkaller-bugs/1UwATFnIiW8/kOpRrjyNAAAJ

--
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.