Thoughts about library contexts

Matt Caswell matt at openssl.org
Mon Feb 18 10:17:45 UTC 2019



On 18/02/2019 01:38, Michael Richardson wrote:
> 
> Paul Dale <paul.dale at oracle.com> 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.
> 
> If by opaque, you mean that the C "struct" definition is not visible to the
> application, then that's required so that we can maintain ABI across changes
> to the structure.

I think Paul is specifically referring to the new OPENSSL_CTX structure which is
opaque even internally (i.e. it it's only transparent to the OPENSSL_CTX code
itself).

At the moment OPENSSL_CTX is implemented using CRYPTO_EX_DATA. An alternative
implementation approach would be that the struct is internally transparent and
is just a bucket of stuff (without using CRYPTO_EX at all). I guess the reason
for doing so would be performance (to reduce the indirection of going via
CRYPTO_EX).

Matt

> 
>     > 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.
> 
>     > Thoughts anyone?
> 
>     > Pauli
> 
>     > --
> 
>     > Oracle
> 
>     > Dr Paul Dale | Cryptographer | Network Security & Encryption
> 
>     > Phone +61 7 3031 7217
> 
>     > Oracle Australia
> 
> 
> 
>     > ----------------------------------------------------
>     > Alternatives:
> 
>     > ----------------------------------------------------
> 


More information about the openssl-project mailing list