On Wed, 05 Jun 2019 03:11:57 +0200, Dr Paul Dale wrote: > > > For a minimally invasive change, the various OSSL_PARAM_construct_ calls > could be modified to > allocate space for the parameter and its return size if NULL is passed for > either.
If NULL is passed as return_size, it means the owner isn't interested in the size (this is obviously the case when the OSSL_PARAM array is to be used with a set_params type of call, but may also be true in a get_params type of call if the owner knows the expected size through some other means, such as a parameter being documented to *always* be a 32-bit integer, or for a OSSL_PARAM_UTF8_STRING where the ending NUL byte is always trustable) But you're talking about allocating the whole OSSL_PARAM array on the heap, aren't you? While not structly opposed (even though I think that's wasteful), I think this should be done with a separate set of functions (intuitively, having names with '_alloc_' rather than '_construct_' could be an idea). > There would need to be some indication of this and a cleanup array call. > > Done properly, this would permit the same efficiency on the owner’s side but > would also simplify > OSSL_PARAM array creation for those who aren’t as concerned. > The theoretical const array of OSSL_PARAM would still be possible. > > Is this workable or should something more significantly different be used > before things freeze > with the 3.0 release? > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > On 5 Jun 2019, at 10:50 am, Dr Paul Dale <[email protected]> wrote: > > I thought the references were to allow const arrays of OSSL_PARAM to be > viable. > > A quick check through the code reveals these in test and doc only. There > are two instances of > OSSL_PARAM arrays being declared in evp, both add the pointed to variable > after creation, both > only have two elements (the integer and the terminator) and both are > stack allocated. I.e. > there is currently is no example of the use case for which the > indirection is present :( > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > On 5 Jun 2019, at 10:31 am, SHANE LONTIS <[email protected]> > wrote: > > I presume the reference approach was used to solve the issue of who > actually owns/free's > the data. > > On 5 Jun 2019, at 9:18 am, Dr Paul Dale <[email protected]> > wrote: > > Shane’s major complaints are about the indirection the OSSL_PARAM > structure forces ― > for integers and return lengths and the necessity of allocating > additional memory in > parallel with the OSSL_PARAM. > > The extra indirection was intended to support const arrays of > OSSL_PARAM, which turn > out to be a rarity because they aren’t thread safe. With most > OSSL_PARAM structure > being dynamically created, the need for the indirection seems > redundant. E.g. could > the return length be moved into OSSL_PARAM? I think so. > > Moving integral values into the structure is more difficult > because BIGNUMs will > always need to be references. Allocating additional memory will > still be required. > I’ve got three obvious solutions: > > 1. include a void * in the OSSL_PARAM structure that needs to be > freed when the > structure is destroyed or > 2. have a block of data in the OSSL_PARAM structure that can be > used for native types > (OSSL_UNION_ALIGN works perfectly for this) or > 3. add a flag field to the OSSL_PARAM to indicate that the > referenced value needs to > be freed. > > The memory allocation comes to the for when reading e.g. a file > and extracting data ― > either the reader needs a lot of local variables to hold > everything or it has to > allocated for each. The file’s data is transient in memory. > > For the most part, the receiver side APIs seem reasonable. It is > the owning side that > has the complications. > > I think I might be able come up with some owner side routines > that assist here but > allowing changes to the params structure would be far easier. > > I kind of like using the OSSL_PARAM arrays as a replacement for > string ctrl functions > if not ctrl as well (subject to backward compatibility concerns). > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > On 4 Jun 2019, at 11:26 pm, Richard Levitte > <[email protected]> wrote: > > On Tue, 04 Jun 2019 14:57:00 +0200, > Salz, Rich wrote: > > Part of the idea was that this would be a means of > communication > > between application and provider, just like controls > are with > libcrypto sub-systems. > > I can probably find the email thread (or maybe it was a > GitHub > comment on my proposal for params), where you said, quite > definitively, that this was *not* a general-purpose > mechanism but > rather a way to expose the necessary internals for opaque > objects > like RSA keys. > > Either I misunderstood what you said at the time, or you > misunderstood > what I said... there's definitely a disconnect here > somewhere. > > What I wonder is why it should be exclusively only one of > those > options? > > Either way, the OSSL_PARAM is defined publically and openly > (i.e. > non-opaque), and we currently have the following functions in > the > public API: > > EVP_MD_CTX_set_params > EVP_MD_CTX_get_params > OSSL_PROVIDER_get_params > > I fully expect that more will come. I have a branch where > I've > EVP_MAC_CTX_set_params, for example, and I wouldn't be > surprised if > EVP_CIPHER_CTX_set_params and EVP_CIPHER_CTX_get_params > appear before > long (I'm actually rather surprised they haven't already), > and I'm > absolutely sure we will see similar functions for asymmetric > algorithms. > > What changed your mind? > > Perhaps not surprisingly, I agree with Shane's assessment > and am > strongly opposed to the project foisting this on everyone > at this > time. @DavidBen, your thoughts? > > Maybe we're reading differently, I didn't see Shane being > opposed to > parameter passing in this way per se, just the exact form of > the > OSSL_PARAM structure, which is different. > > Cheers, > Richard > > -- > Richard Levitte [email protected] > OpenSSL Project http://www.openssl.org/~levitte/ > > -- Richard Levitte [email protected] OpenSSL Project http://www.openssl.org/~levitte/
