IronPort-PHdr: =?us-ascii?q?9a23=3A1dSLnh3/riiekLZZsmDT+DRfVm0co7zxezQtwd8Z?=
 =?us-ascii?q?sesVIvTxwZ3uMQTl6Ol3ixeRBMOHs6sC07KempujcFRI2YyGvnEGfc4EfD4+ou?=
 =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?=
 =?us-ascii?q?POT1HZPZg9iq2+yo9JDffxhEiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?=
 =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?=
 =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QKsqUjq+8ahkVB7oiD?=
 =?us-ascii?q?8GNzEn9mHXltdwh79frB64uhBz35LYbISTOfVwZKPdec4RS3RHUMhfSidNBpqw?=
 =?us-ascii?q?Y5UTA+YEO+tTsovzqEYUrRamBgeiGePhxCFGiHD006061PguHwbJ0wIvBN8OrH?=
 =?us-ascii?q?fZoc/pOKoITey4zq/FxijDYfNM3jf97ZDFfA09of6SRbJwcdTeyU8yHA3Yi1Wf?=
 =?us-ascii?q?s4jlPzeL2eUNrmOW6PFgWv+0i2M8twFwoiSgxscrioXTgIIV0UrL+T92wIYyO9?=
 =?us-ascii?q?21UUh2asOnHptIryyWKoR7T8w4T2xopSo20KMKtJGlcCQQ1ZgqwQPUZeadfIiS?=
 =?us-ascii?q?+B3jUf6cITJ/hH14Zr2ynw2y8U28yu3kUcm0zUpKojJFktbSsnAN0ATe6tSdRf?=
 =?us-ascii?q?tn/0ehxC2P2xrP6uBEPU80la3bJ4QnwrEsjZocrV7PHir3mEXylKOWd0Mk9fa0?=
 =?us-ascii?q?6+n/f7nrqZCRO5V0hw3jKKgihMOyDfoiPgQTR2Sb/P6z1Lzn/U33WrVKifg2n7?=
 =?us-ascii?q?HCsJ/HPsQWvbK5Ag9J3YYj7BazFTGm0M8CknUdI1JFfwyHg5DzO17SOPD4Eeu/?=
 =?us-ascii?q?g1O0nTdvxvDGOKDhA5rUInjAjrjhZ7B95FBYyAco09Bf6IxbCqsbLPLwREDxrt?=
 =?us-ascii?q?rYAQE9MwCuxObnEtp93JsEWW2TGq+ZLL/SsViQ6+I3J+mDfpIVuCrnK/c+/fHj?=
 =?us-ascii?q?lmU5lkEAcqmpx5QXdGq0EehhI0WceXDsmMsOEX8WvgoiS+znkFmCUSBJZ3moRK?=
 =?us-ascii?q?0z+C00BZm8DYjdW4+tgKaO3DuhEpJKYWBGD0iGEW30eIWcR/cMdCWSL9d8nT0K?=
 =?us-ascii?q?T7ehT5Qh1RG1uQ/g1bVoM+rU9TcEtZ75yNd14OjTnwko9TNoF8Sdz32NT2Zsk2?=
 =?us-ascii?q?wWXz85xrp/oU1mylqYyah3meZYFd1I5/NRVgc1L4LTwPJgB9D1QALBcc+DSEy6?=
 =?us-ascii?q?TdW+HTExUtUxzscWY0lnBtWiigvO3zKwDL8Ik7yHHZk08qXb33jrOclx0WrJ1K?=
 =?us-ascii?q?4kj1M+WMtAKXWmhrJj9wjUH4PIk1+Wl6CldaQe3S7N9GCDzWyBvE1FSwNwUbjF?=
 =?us-ascii?q?UmoRZ0TIrNT1/F/NT7irCedvDgwU2MeEJalLatrvgh0SVf7lN9bfY2W3lD6YBQ?=
 =?us-ascii?q?uB2b6NKoHtfjNZlG/FAVUAuxga4HLDMA85HCrnqGXbRnQ6DVvyZ2v0+PR67Xa8?=
 =?us-ascii?q?SVU5iQqNahsln/C44hcPhOe0U/oJ36kcvC4qpnNzBln3l4bbE9OaphFJZKxGYM?=
 =?us-ascii?q?gl5F5M2CTerQMretTqNK1mh1gDYyxrrkju0FNxEYwGns805jt+1wd2KKSFwHtd?=
 =?us-ascii?q?ZjiY2tb2IbSRJW7sqlTnR6fQ21zamPTexa4L8/Rw/1n8tQWyFmI4/nln2sUT2H?=
 =?us-ascii?q?yZsNGCKBcRWIm5bFw+/RVx7+XefDM07Y7f/WdhPam9rnnJ3Nd/QKMdxwq6N/NW?=
 =?us-ascii?q?Lb+eHgb5E4VOH8ynNfAwkVGBdB8IPOlOsqUzOpX1WeGB3fuQIOt4nD+gxV9C6Y?=
 =?us-ascii?q?R531PEozFwUcbUzp0FxLeexQLBWDDi2gTy+vvrkJxJMGlBVlG0zjLpUcsIPPV/?=
Message-ID: <1513256850.18008.1.camel@tycho.nsa.gov>
Subject: Re: [BUG]kernel softlockup due to sidtab_search_context run for
 long time because of too many sidtab context node
From: Stephen Smalley <sds@tycho.nsa.gov>
To: yangjihong <yangjihong1@huawei.com>,
        "paul@paul-moore.com" <paul@paul-moore.com>,
        "eparis@parisplace.org" <eparis@parisplace.org>,
        "selinux@tycho.nsa.gov" <selinux@tycho.nsa.gov>,
        Daniel J Walsh <dwalsh@redhat.com>, Lukas Vrabec <lvrabec@redhat.com>,
        Petr Lautrbach <plautrba@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Date: Thu, 14 Dec 2017 08:07:30 -0500
In-Reply-To: <1BC3DBD98AD61A4A9B2569BC1C0B4437D5D2AF@DGGEMM506-MBS.china.huawei.com>
References: <1BC3DBD98AD61A4A9B2569BC1C0B4437D5D1F3@DGGEMM506-MBS.china.huawei.com>
         <1513178296.19161.8.camel@tycho.nsa.gov>
         <1BC3DBD98AD61A4A9B2569BC1C0B4437D5D2AF@DGGEMM506-MBS.china.huawei.com>
Organization: National Security Agency
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2190
Lines: 46

On Thu, 2017-12-14 at 03:19 +0000, yangjihong wrote:
> Hello,
> 
> >  So, does docker just keep allocating a unique category set for
> > every new container, never reusing them even if the container is
> > destroyed? 
> >  That would be a bug in docker IMHO.  Or are you creating an
> > unbounded number of containers and never destroying the older ones?
> 
> I creat a containers, then destroy it,  and create second one,
> destroy it.......
> When docker created, it will mount overlay fs, because every
> containers has different selinux context, so a new sidtab node is
> generated and insert into the sidtab list  
> When docker destroyed, it will umount overlay fs, but umount
> operation does not seem relevant to "delete the node" hooks function,
> resulting in longer and longer sidtab list
> I think when umount, its selinux context will never reuse, so sidtab
> node is useless, it is best to delete i

The "selinux context will never reuse" is IMHO a bug in docker; if you
truly destroy the container (i.e. don't just stop its execution, but
delete it entirely), then the context should be reusable.

> >  sidtab_search_context() could no doubt be optimized for the
> > negative case; there was an earlier optimization for the positive
> > case by adding a cache to sidtab_context_to_sid() prior to calling
> > it.  It's a reverse lookup in the sidtab.
> 
> I think add cache may be not very userful, because every containers
> has different selinux context, so when one docker created, it will
> search the whole sidtab list, until compare the last node, When a new
> node arrives, it is always necessary to compare all the nodes first,
> and then insert. 
> All as long as the list does not delete the node, list will always
> increase, and search time will longer and longer, eventually leading
> to softlockup
> 
> 
> Is there any solution to this problem?

On the kernel side, we could certainly implement a reverse lookup hash
table.  And there could be a faster way to quickly check whether a
given category set has ever been used if we wanted to specialize in
that manner.  But that won't fix the fact that docker is allocating
unbounded security contexts.