linux-kernel - Re: [PATCH] xfrm: policy: Restructure RCU-read locking in xfrm_sk_policy

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:   Tue, 22 Jun 2021 13:21:59 +0200
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Varad Gautam <varad.gautam@...e.com>
CC:     <linux-kernel@...r.kernel.org>,
        linux-rt-users <linux-rt-users@...r.kernel.org>,
        <netdev@...r.kernel.org>, Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        "Jakub Kicinski" <kuba@...nel.org>,
        Florian Westphal <fw@...len.de>,
        "Ahmed S. Darwish" <a.darwish@...utronix.de>,
        Frederic Weisbecker <frederic@...nel.org>,
        <stable@...r.kernel.org>
Subject: Re: [PATCH] xfrm: policy: Restructure RCU-read locking in
 xfrm_sk_policy_lookup

On Mon, Jun 21, 2021 at 01:05:28PM +0200, Steffen Klassert wrote:
> On Mon, Jun 21, 2021 at 11:11:18AM +0200, Varad Gautam wrote:
> > 
> > Right, I misread the call chain - security_xfrm_policy_lookup does not reach
> > xfrm_policy_lookup, making this patch unnecessary. The bug I have is:
> > 
> > T1, holding hash_resize_mutex and sleeping inside synchronize_rcu:
> > 
> > __schedule
> > schedule
> > schedule_timeout
> > wait_for_completion
> > __wait_rcu_gp
> > synchronize_rcu
> > xfrm_hash_resize
> > 
> > And T2 producing RCU-stalls since it blocked on the mutex:
> > 
> > __schedule
> > schedule
> > __rt_mutex_slowlock
> > rt_mutex_slowlock_locked
> > rt_mutex_slowlock
> > xfrm_policy_lookup_bytype.constprop.77
> 
> Ugh, why does xfrm_policy_lookup_bytype use a mutex? This is called
> in the receive path inside a sofirq.
> 
> The bug was introduced by: 
> 
> commit 77cc278f7b202e4f16f8596837219d02cb090b96
> Author: Ahmed S. Darwish <a.darwish@...utronix.de>
> Date:   Mon Jul 20 17:55:22 2020 +0200
> 
>     xfrm: policy: Use sequence counters with associated lock
> 
>     A sequence counter write side critical section must be protected by some
>     form of locking to serialize writers. If the serialization primitive is
>     not disabling preemption implicitly, preemption has to be explicitly
>     disabled before entering the sequence counter write side critical
>     section.
> 
>     A plain seqcount_t does not contain the information of which lock must
>     be held when entering a write side critical section.
> 
>     Use the new seqcount_spinlock_t and seqcount_mutex_t data types instead,
>     which allow to associate a lock with the sequence counter. This enables
>     lockdep to verify that the lock used for writer serialization is held
>     when the write side critical section is entered.
> 
>     If lockdep is disabled this lock association is compiled out and has
>     neither storage size nor runtime overhead.
> 
>     Signed-off-by: Ahmed S. Darwish <a.darwish@...utronix.de>
>     Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
>     Link: https://lkml.kernel.org/r/20200720155530.1173732-17-a.darwish@linutronix.de
> 
> This uses a seqcount_mutex_t for xfrm_policy_hash_generation, that's
> wrong.

Varad, can you try to replace the seqcount_mutex_t for xfrm_policy_hash_generation
by a seqcount_spinlock_t? I'm not familiar with that seqcount changes,
but we should not end up with using a mutex in this codepath.