netdev - Re: [RFC net-next 1/4] net: ipv6: Make inet6addr

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] [day] [month] [year] [list]

Message-ID: <8e0a3f28-14fd-337d-c2e0-6b8419cbdddb@gmail.com>
Date:   Wed, 11 Oct 2017 15:56:47 -0600
From:   David Ahern <dsahern@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, jiri@...lanox.com, idosch@...lanox.com,
        kjlx@...pleofstupid.com
Subject: Re: [RFC net-next 1/4] net: ipv6: Make inet6addr_validator a blocking
 notifier

On 10/11/17 3:13 PM, David Miller wrote:
> From: David Ahern <dsahern@...il.com>
> Date: Tue, 10 Oct 2017 09:41:02 -0700
> 
>> +	/* validator notifier needs to be blocking;
>> +	 * do not call in softirq context
>> +	 */
>> +	if (!in_softirq()) {
> 
> I think we can test this better.

The callchain we are protecting against is
            7fff8149d0dd ipv6_add_addr ([kernel.kallsyms])
            7fff814a161b addrconf_prefix_rcv ([kernel.kallsyms])
            7fff814afb8a ndisc_router_discovery ([kernel.kallsyms])
            7fff814b0310 ndisc_rcv ([kernel.kallsyms])
            7fff814b62da icmpv6_rcv ([kernel.kallsyms])
            7fff81499c37 ip6_input_finish ([kernel.kallsyms])
            7fff81499e96 ip6_input ([kernel.kallsyms])
            7fff8149a519 ip6_mc_input ([kernel.kallsyms])
            7fff81499f9d ip6_rcv_finish ([kernel.kallsyms])
            7fff8149a349 ipv6_rcv ([kernel.kallsyms])
            7fff813fbe12 __netif_receive_skb_core ([kernel.kallsyms])
            7fff813fc04c __netif_receive_skb ([kernel.kallsyms])
            7fff813ff97c netif_receive_skb_internal ([kernel.kallsyms])

> 
> You should be able to audit the call sites and for each one set the
> value of a new boolean argument properly, and this way you can also
> give the boolean argument a descriptive name.

The safest is an in_atomic() check, but to your point I'll see if the
caller can pass in atomic vs blocking option as a bool.

> 
> Furthermore, we can also then pull the inet6_addr allocation out of
> the locking paths and thus use GFP_KERNEL when possible.
> 

Yes, I was thinking about that as a follow on -- how far down can the
rcu_read_lock_bh be pushed.