Messages in this thread | | | From | Ondrej Mosnacek <> | Date | Mon, 3 Feb 2020 09:46:51 +0100 | Subject | Re: possible deadlock in sidtab_sid2str_put |
| |
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.
| |