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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/