Paul Dale <paul.d...@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.
> 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:
> ----------------------------------------------------
signature.asc
Description: PGP signature
