Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 21 Mar 2021 23:00:09 -0700
From:   Eric Biggers <ebiggers@kernel.org>
To:     Dan Carpenter <dan.carpenter@oracle.com>
Cc:     linux-crypto@vger.kernel.org, Neil Horman <nhorman@tuxdriver.com>,
        Corentin Labbe <clabbe@baylibre.com>, stable@vger.kernel.org
Subject: Re: [PATCH] crypto: rng - fix crypto_rng_reset() refcounting when
 !CRYPTO_STATS
Message-ID: <YFgyaeeY6k6Pltw7@sol.localdomain>
References: <20210322050748.265604-1-ebiggers@kernel.org>
 <20210322054522.GC1667@kadam>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210322054522.GC1667@kadam>
Precedence: bulk

On Mon, Mar 22, 2021 at 08:45:22AM +0300, Dan Carpenter wrote:
> On Sun, Mar 21, 2021 at 10:07:48PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > crypto_stats_get() is a no-op when the kernel is compiled without
> > CONFIG_CRYPTO_STATS, so pairing it with crypto_alg_put() unconditionally
> > (as crypto_rng_reset() does) is wrong.
> > 
> 
> Presumably the intention was that _get() and _put() should always pair.
> It's really ugly and horrible that they don't. We could have
> predicted bug like this would happen and will continue to happen until
> the crypto_stats_get() is renamed.
> 

Well, the crypto stats stuff has always been pretty broken, so I don't think
people have looked at it too closely.  Currently crypto_stats_get() pairs with
one of the functions that tallies the statistics, such as
crypto_stats_rng_seed() or crypto_stats_aead_encrypt().  What change are you
suggesting, exactly?  Maybe moving the conditional crypto_alg_put() into a new
function crypto_stats_put() and moving it into the callers?  Or do you think the
functions should just be renamed to something like crypto_stats_begin() and
crypto_stats_end_{rng_seed,aead_encrypt}()?

Another issue is that a lot of operations (such as the rng one in question here)
don't actually need the get/put at all because they are never asynchronous.  I
didn't aim to address that in my patch though...

- Eric