Thoughts about library contexts

[Michael Richardson]

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.

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

    > ----------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190217/661140b7/attachment.sig>