| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
classes_new is an array of pointers to struct crypto_ex_data, not
an array of struct crypto_ex_data_index, so this overallocated by
240 or 480 bytes on ILP32 or LP64, respectively.
found by jsg using smatch
ok jsing
|
| |
|
|
|
|
|
|
|
| |
rust-openssl tests do something weird and need lots of ex data (one index
for each registered callback, for example). This makes the regress pass
again.
noticed by anton
ok jsing
|
| |
|
|
|
|
|
|
|
| |
It's a double pointer, so we should allocate a pointer size, not the entire
struct. This saves roughly 500B per class.
CID 507397
ok jsing
|
| |
|
|
| |
ok jsing
|
|
|
CRYPTO_EX_DATA exists as a way to allow an application to attach data to
various components in libcrypto and libssl. The general idea is that there
are various "classes" (e.g. RSA) and an application can get an "index"
(which can have new/dup/free functions provided). The application can then
use the index to store a pointer to some form of data within that class,
for later retrieval.
However, even by OpenSSL standards, this is an insane API. The current
implementation allows for data to be set without calling new, indexes
can be used without allocation, new can be called without actually getting
an index and dup can be called either after new or without new (see regress
and RSA_get_ex_new_index(3)/CRYPTO_set_ex_data(3) for more details). On
top of this, the previous "overhaul" of the code was written to be
infinitely extensible.
For now, the rewrite intends to maintain the existing behaviour - once we
bed this down we can attempt to ratchet the API requirements and require
some sort of sensible sequence. The only intentional change is that there
is now a hard limit on the number of indexes that can be allocated
(previously there was none, relying only on ENOMEM).
ok tb@
|
