netdev - Re: [PATCH net-next] net/tls: Use RCU API to access tls

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20220803074957.33783ad4@kernel.org>
Date:   Wed, 3 Aug 2022 07:49:57 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Maxim Mikityanskiy <maximmi@...dia.com>
Cc:     "davem@...emloft.net" <davem@...emloft.net>,
        Tariq Toukan <tariqt@...dia.com>,
        Gal Pressman <gal@...dia.com>,
        "john.fastabend@...il.com" <john.fastabend@...il.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        Saeed Mahameed <saeedm@...dia.com>,
        Boris Pismenny <borisp@...dia.com>,
        "Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH net-next] net/tls: Use RCU API to access tls_ctx->netdev

On Wed, 3 Aug 2022 09:33:48 +0000 Maxim Mikityanskiy wrote:
> > > The documentation of rcu_access_pointer says it shouldn't be used on
> > > the update side, because we lose lockdep protection:
> > > 
> > > --cut--
> > > 
> > > Although rcu_access_pointer() may also be used in cases
> > > where update-side locks prevent the value of the pointer from changing,
> > > you should instead use rcu_dereference_protected() for this use case.  
> > 
> > I think what this is trying to say is to not use the
> > rcu_access_pointer() as a hack against lockdep:  
> 
> Well, maybe we understand it in different ways. This is how I parsed it
> (the whole comment):
> 
> 1. rcu_access_pointer is not for the read side. So, it's either for the
> write side or for usage outside all locks.
> 
> 2. It's not for dereferencing. So, it's for reading the pointer's value
> on the write side or outside all locks.
> 
> 3. Although it can be used on the write side, rcu_dereference_protected
> should be used. So, it's for reading the pointer's value outside all
> locks.

Using rcu_deref* when we don't dereference the pointer does not compute
for me, but it's not a big deal. 

Let me CC Paul for clarification of the docs, as it may also be
confusing to others and therefore worth rewording. But our case is 
not that important so unless Paul chimes in clearly indicating one
interpretation is right - either way is fine by me for v2.