Paul Dale <> wrote:
    > Library contexts are going to allow us to separate different portions of 
    > 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? 
    > not suggesting that complete visible is a good idea, but partial 
    > over some areas of the core would be useful. E.g. the core components 
    > 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 
    > 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:

    > ----------------------------------------------------

Attachment: signature.asc
Description: PGP signature

Reply via email to