[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhTzG1tzfkyCQL++M2USPnZmxoOeuo23qoLjdgtPan9D2w@mail.gmail.com>
Date: Wed, 6 Jul 2016 10:37:53 -0400
From: Paul Moore <paul@...l-moore.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: David Miller <davem@...emloft.net>, dsa@...ulusnetworks.com,
Linux-Netdev <netdev@...r.kernel.org>
Subject: Re: Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with
CIPSO & Smack
On Wed, Jul 6, 2016 at 10:15 AM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> On 7/6/2016 5:50 AM, Paul Moore wrote:
>> On Tue, Jul 5, 2016 at 8:38 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>>> I have encountered a system hang with my Smack
>>> networking tests that bisects to the change below.
>>> I can't say that I have any idea why the change
>>> would impact the Smack processing, but there appears
>>> to be some serious packet processing going on. The
>>> Smack code is using CIPSO on the loopback interface.
>>> The test is supposed to verify that labels can be
>>> set on the packets using CIPSO. Unlabeled packets
>>> do not appear to be impacted. I do not know if SELinux
>>> is affected, and if not, why not. Smack and SELinux
>>> use CIPSO differently.
>> For the past several months I've been running the SELinux testsuite on
>> a weekly basis against Linus' kernel plus the SELinux and audit
>> development trees and I haven't noticed any problems that haven't
>> already been reported. While not exhaustive, the testsuite does
>> exercise the NetLabel/CIPSO code. I'll see if I can take a closer
>> look at the Smack code, but do you rely on the inet_skb_param values
>> in Smack? We did have a similar problem in the NetLabel core code
>> that we fixed with 04f81f0154e4bf002be6f4d85668ce1257efa4d9; it's
>> possible there is a similar problem in code that we just aren't
>> exercising with SELinux at the moment.
>
> I reported that problem, and that problem was fixed.
Yep, I know, that is why I included the commit ID.
> I'm looking at the Linus tree and see no structure inet_skb_param.
I mistakenly added an extra "a", look for "struct inet_skb_parm" near
the top of include/net/ip.h; it was modified as part of the
pull-request/merge you mentioned.
--
paul moore
www.paul-moore.com
Powered by blists - more mailing lists