ocsp stapling global mutex

[Paul Querna <pa...@querna.org>]

Hi,

I was playing with OCSP Stapling in 2.3.6-alpha tonight, and I noticed
that in the common case path, we will always lock a global mutex.

I don't see why this is needed for the cache hit case that uses
non-SHM cache providers.

In fact, modssl_dispatch_ocsp_request, which is called on a cache
miss, already has a serialize_request, so I'm not sure why there is a
global mutex at all, even for cache updates.

It seems that inside stapling_mutex_{on,off} in ssl_util_stapling.c,
the global mutex should only be used if (mc->stapling_cache->flags &
AP_SOCACHE_FLAG_NOTMPSAFE) is true?

Thoughts?

Thanks,

Paul

Re: ocsp stapling global mutex

[Joe Orton <jo...@redhat.com>]

On Wed, Jul 14, 2010 at 10:33:43PM +0100, Dr Stephen Henson wrote:
> On 25/06/2010 08:10, Paul Querna wrote:
> > I was playing with OCSP Stapling in 2.3.6-alpha tonight, and I noticed
> > that in the common case path, we will always lock a global mutex.
> > 
> > I don't see why this is needed for the cache hit case that uses
> > non-SHM cache providers.
> > 
> > In fact, modssl_dispatch_ocsp_request, which is called on a cache
> > miss, already has a serialize_request, so I'm not sure why there is a
> > global mutex at all, even for cache updates.
> > 
> > It seems that inside stapling_mutex_{on,off} in ssl_util_stapling.c,
> > the global mutex should only be used if (mc->stapling_cache->flags &
> > AP_SOCACHE_FLAG_NOTMPSAFE) is true?
> 
> The reason for this is to keep the number of OCSP queries to a minimum, which is
> the main purpose of stapling.
> 
> If the cached response is acceptable the mutex will lock, retrieve and unlock
> which should be handled relatively quickly.

There are two independent uses of this lock though - serializing access 
to the cache, and serializing access to the responder.  The latter is 
only required in the case of a cache miss or a cache hit with a stale 
response.  The former is required iff the socache backend has the 
_NOTMPSAFE flag as Paul says.

So Paul's right that it's possible to optimize for a cache hit with a 
valid response if using a lockless cache such that no locking is 
required.  (looks like it would require only minor rejigging of the 
code)

Regards, Joe

Re: ocsp stapling global mutex

[Dr Stephen Henson <sh...@oss-institute.org>]

On 25/06/2010 08:10, Paul Querna wrote:
> Hi,
> 
> I was playing with OCSP Stapling in 2.3.6-alpha tonight, and I noticed
> that in the common case path, we will always lock a global mutex.
> 
> I don't see why this is needed for the cache hit case that uses
> non-SHM cache providers.
> 
> In fact, modssl_dispatch_ocsp_request, which is called on a cache
> miss, already has a serialize_request, so I'm not sure why there is a
> global mutex at all, even for cache updates.
> 
> It seems that inside stapling_mutex_{on,off} in ssl_util_stapling.c,
> the global mutex should only be used if (mc->stapling_cache->flags &
> AP_SOCACHE_FLAG_NOTMPSAFE) is true?
> 

The reason for this is to keep the number of OCSP queries to a minimum, which is
the main purpose of stapling.

If the cached response is acceptable the mutex will lock, retrieve and unlock
which should be handled relatively quickly.

In the case of an invalid (e.g. expired) or missing cached response an instance
locks, retrieves the cached response, realises it is invalid and then attempts
to retrieve and store an updated response from the responder and finally unlocks.

The update process could take a maybe a second or so. If the lock wasn't there
many instances on a heavily loaded server could query the responder almost
simultaneously.

Steve.
-- 
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org