netdev - Re: [Patch net] net: saving irq context for peernet2id()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 21 Oct 2016 21:55:53 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     David Miller <davem@...emloft.net>
Cc:     rgb@...hat.com, xiyou.wangcong@...il.com,
        Stephen Smalley <sds@...ho.nsa.gov>, netdev@...r.kernel.org,
        e@...draz.com
Subject: Re: [Patch net] net: saving irq context for peernet2id()

On Fri, Oct 21, 2016 at 4:53 PM, Paul Moore <paul@...l-moore.com> wrote:
> On Fri, Oct 21, 2016 at 4:33 PM, David Miller <davem@...emloft.net> wrote:
>> From: Paul Moore <paul@...l-moore.com>
>> Date: Fri, 21 Oct 2016 16:15:00 -0400
>>
>>> However, that's not the case is it?  Unless I missed something, the
>>> fix that Cong Wang is advocating (rework the audit multicast code), is
>>> a change that I have said I'm not going to accept during the -rc
>>> phase.  It has been a few days now and no alternate fix has been
>>> proposed, I'll give it a few more hours ...
>>
>> It really is the right way to fix this though.
>>
>> Nothing should be emitting netlink messages, potentially en-masse
>> to a multicast group or broadcast, in hardware interrupt context.
>>
>> I know it's been said that only systemd receives these things, so
>> that point doesn't need to be remade again.
>
> I think it is also worth noting that this code has been doing it this
> way for some time now.  I say this not to advocate that it is correct,
> only that there hasn't been a demonstrated problem until Cong Wang's
> patch.
>
>> We have many weeks until -final is released so I really don't
>> understand the reluctance at a slightly more involved fix in -rc2.  In
>> fact this is the most optimal time to try it this way, as we'll have
>> the maximum amount of time for it to have exposure for testing before
>> -final.
>
> Well, I understand what you are trying to say, but the maximum amount
> of time for exposure/testing would be to put it in -next.  The audit
> netlink code needs a rework, but introducing such a change in the -rc
> kernels is not something I'm going to do, especially when the change
> which triggered the regression is an optimization that can be easily
> reverted ... or fixed, but the only two options I've heard mentioned
> are the audit multicast rework and the revert; if someone has a third
> option I'm listening ...

It's the end of my day, and commitments over the weekend will limit
how much additional testing/work I can do so I went ahead and just
posted a simple revert to netdev, it should be in your inbox already.
Please fix this, either through a revert, or preferably some other fix
we haven't thought of yet, in time for -rc2.

Thanks.

-- 
paul moore
www.paul-moore.com