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 


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?






Dr Paul Dale | Cryptographer | Network Security & Encryption 

Phone +61 7 3031 7217

Oracle Australia


Reply via email to