"D. J. Bernstein" <posting-openssl-users@xxxxxxxxxxxx> writes:
> It seems that an OSSL_FUNC_DECODER_DECODE function dynamically allocates
> space for a key, sets up an OSSL_OBJECT_PARAM_REFERENCE with the address
> of a pointer to the key, and passes that to data_cb(), which (typically)
> calls an OSSL_FUNC_KEYMGMT_LOAD function to copy that pointer into a
> previously allocated key-management object.
>
> After data_cb() returns, the OSSL_FUNC_DECODER_DECODE function passes
> the pointer to *_free(), so (to avoid use-after-free, double-free, and
> memory leaks) it's critical for the OSSL_FUNC_KEYMGMT_LOAD function to
> have set the pointer to 0 (via the supplied address) if and only if it
> in fact copied the pointer.
>
> Did I get the memory-management responsibilities straight here? This is
> extrapolating from code; I wasn't able to find documentation on point.
For this model of interaction between decoder and keymgmt ('cause that's
essentially what this is), that's the same "hand-over" that we do.
The documentation for this is lacking, because at least at the time, we
figured it's up to each provider author to figure out how to do the
"hand-over", and there may be other ideas out there.
For all I know, a provider could just as well choose to place the key in
an internal cache and pass the cache index in an "data" OSSL_PARAM
(OSSL_OBJECT_PARAM_DATA), and have the keymgmt "load" function pick up
that cache index through the reference argument.
There is some concrete documentation for the OSSL_OBJECT_PARAM macros:
provider-object(7). Does that help?
All things considered, it may be time for us to write some encoder /
decoder guidelines... ossl-guide-encoder(7) and ossl-guide-decoder(7),
perhaps?
Cheers,
Richard
--
Richard Levitte levitte@xxxxxxxxxxx
OpenSSL Project http://www.openssl.org/~levitte/
