Re: Thoughts about library contexts
On Mon, 18 Feb 2019 11:17:45 +0100, Matt Caswell wrote: > At the moment OPENSSL_CTX is implemented using CRYPTO_EX_DATA. An alternative > implementation approach would be that the struct is internally transparent and > is just a bucket of stuff (without using CRYPTO_EX at all). I guess the reason > for doing so would be performance (to reduce the indirection of going via > CRYPTO_EX). The central idea here is that OPENSSL_CTX is a bag of "stuff" and that each sub-system should decide on their own what its "stuff" is. Of course, the bag could have been made like a structure with specific pointers for each sub-system that wants to store something, but I find that approach a bit messy, as the sub-systems become less self contained, and also have less control over their own "stuff". For example, if there's a need for a lock to retrieve some data, does everyone else have to learn to use that lock, and what happens if someone forgets, i.e. how error prone can it become? As an alternative, if the sub-system defines its own internal API for access of stuff, that does all the needed locking, why does everyone else need to know exactly how it's stored in the library context? The reason why I chose CRYPTO_EX_DATA for internal storage? I was actually about to implement a generic "bag", when I realised that we already have that in CRYPTO_EX_DATA. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: Thoughts about library contexts
On Mon, Feb 18, 2019 at 8:36 PM Matt Caswell wrote: > > > On 18/02/2019 10:28, Tim Hudson wrote: > > It should remain completely opaque. > > As a general rule, I've never seen a context where someone regretted > making a > > structure opaque over time, but the converse is not true. > > This is opaque and should remain opaque. > > We need the flexibility to adjust the implementation at will over time. > > I think we're debating whether it is internally opaque or not. Externally > opaque > is a given IMO. > And my comments apply to internally opaque too - I was aware of that context when I wrote them - this is something that we will want to change as it evolves over time. And we shouldn't have a pile of knowledge of the internals of one part of the library spreading over the other parts. Tim.
Re: Thoughts about library contexts
On 18/02/2019 10:28, Tim Hudson wrote: > It should remain completely opaque. > As a general rule, I've never seen a context where someone regretted making a > structure opaque over time, but the converse is not true. > This is opaque and should remain opaque. > We need the flexibility to adjust the implementation at will over time. I think we're debating whether it is internally opaque or not. Externally opaque is a given IMO. Matt > > For anything where partial visibility is seen as desirable, it should be > raised > specifically as to what issue would drive that - as frankly I don't see a > context where that would make sense. > > Tim.
Re: Thoughts about library contexts
Paul Dale 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
Re: Thoughts about library contexts
On Sun, 17 Feb 2019 23:18:08 +0100, Paul Dale 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. I'm not sure I understand... Are you saying that you want OPENSSL_CTX to be non-opaque? What for? The current implementation is basically as a bag of "things", where the exact "thing" is identified with an index. The rest is defined by every sub-system that wants to store "things" in a library context, i.e. they must get themselves an index for each type of "thing", and then they simply get it from the library context. Do you need to know exactly how the bag of "things" is organized? The diverse sub-system structures may be opaque or non-opaque as they see fit, of course. > 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. You're talking about the property string cache... yeah, I see no real reason to store them away in a library context, it's not really like we'd gain anything by having several of them with potentially the exact same information. So yeah, we do need to think about what stuff should go into the library context and what shouldn't. (I think Rich has voiced the opinion that error stacks and error string tables shouldn't be tied to a library context, and for the moment, I agree with that view) Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Thoughts about library contexts
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
