Thoughts about library contexts

[Richard Levitte]

On Sun, 17 Feb 2019 23:18:08 +0100,
Paul Dale wrote:
> Library contexts are going to allow us to separate different portions of the TLS/cryptographic
> activity within one application.  No problems, here.  This seems like a useful and worthwhile
> idea.  It will e.g. be a way to separate FIPS and non-FIPS streams nicely.
> 
> I’ve a reservation about the current definition.  Why must they be opaque?  I’m not suggesting
> that complete visible is a good idea, but partial visibility over some areas of the core would be
> useful.  E.g. the core components ought to be able to access other core components without diving
> through an indirection scheme.

I'm not sure I understand...  Are you saying that you want OPENSSL_CTX
to be non-opaque?  What for?  The current implementation is basically
as a bag of "things", where the exact "thing" is identified with an
index.  The rest is defined by every sub-system that wants to store
"things" in a library context, i.e. they must get themselves an index
for each type of "thing", and then they simply get it from the library
context.

Do you need to know exactly how the bag of "things" is organized?

The diverse sub-system structures may be opaque or non-opaque as they
see fit, of course.

> What level of isolation do we want between different contexts?  We’re unlikely to be able to
> completely segregate them but should we make an effort to reduce information leakage between them?
>   E.g. the current properties has a couple of global databases that will be shared across all
> contexts – would they make better sense being one per context?  There would be a space cost, a
> reduction in the cache efficiency, … but it would add to segregation.  Enclaves could also assist.

You're talking about the property string cache...  yeah, I see no real
reason to store them away in a library context, it's not really like
we'd gain anything by having several of them with potentially the
exact same information.

So yeah, we do need to think about what stuff should go into the
library context and what shouldn't.  (I think Rich has voiced the
opinion that error stacks and error string tables shouldn't be tied to
a library context, and for the moment, I agree with that view)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/