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. 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
