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]

Message-ID: <CAM_iQpX-2M4Q+drzf0_ncnDhLESmbG869Wuac1WujKwbkfQZiw@mail.gmail.com>
Date:   Thu, 20 Oct 2016 12:04:49 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Stephen Smalley <sds@...ho.nsa.gov>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Elad Raz <e@...draz.com>, Paul Moore <paul@...l-moore.com>,
        Richard Guy Briggs <rgb@...hat.com>
Subject: Re: [Patch net] net: saving irq context for peernet2id()

On Thu, Oct 20, 2016 at 11:29 AM, Cong Wang <xiyou.wangcong@...il.com> wrote:
> On Thu, Oct 20, 2016 at 7:58 AM, Stephen Smalley <sds@...ho.nsa.gov> wrote:
>> On 10/20/2016 02:52 AM, Cong Wang wrote:
>>> A kernel warning inside __local_bh_enable_ip() was reported by people
>>> running SELinux, this is caused due to some SELinux functions
>>> (indirectly) call peernet2id() with IRQ disabled in process context,
>>> when we re-enable BH with IRQ disabled kernel complains. Shut up this
>>> warning by saving IRQ context in peernet2id(), BH is still implicitly
>>> disabled.
>>
>> Not sure this suffices; kill_fasync() -> send_sigio() ->
>> send_sigio_to_task() -> sigio_perm() -> security_file_send_sigiotask()
>> -> selinux_file_send_sigiotask() -> ... -> audit_log() -> ... ->
>> peernet2id()
>
> Oh, this is a new one. kill_fasync() is called in IRQ handler, so we actually
> do multicast in IRQ context.... It makes no sense, netlink multicast could
> be very expensive if we have many listeners.
>
> I am Cc'ing Richard who added that multicast in audit_log_end(). It seems
> not easy to just move the multicast to a workqueue, since the skb is copied
> from audit_buffer which is freed immediately after that, probably need another
> queue like audit_skb_queue.

Please let me know if the attached patch makes any sense to you, before
I give it a serious test.

Thanks!

View attachment "audit.diff" of type "text/plain" (1828 bytes)