A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9_BASE 2025-06-15T15:58:56+00:00 2025-06-15T15:58:56+00:00 tb 2025-06-15T15:58:56+00:00 urn:sha1:5a73189c01a533dce529ab97311cbc7fa95c27ab ok beck 2025-06-07T04:37:01+00:00 tb 2025-06-07T04:37:01+00:00 urn:sha1:e3bb436a26295a47435997715acf0a7eac465f6c 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 2024-08-03T07:45:26+00:00 tb 2024-08-03T07:45:26+00:00 urn:sha1:2b41f5780c5f133132d9403d020e195c9ad4919d 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 2024-08-03T07:43:33+00:00 tb 2024-08-03T07:43:33+00:00 urn:sha1:d7b328b513d2128dfbee9482c01b4e22de59f428 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 2024-08-02T14:02:33+00:00 tb 2024-08-02T14:02:33+00:00 urn:sha1:3f8ee49b42e8a18a7e21ac4d0b5091931372b9a0 ok jsing 2024-08-02T10:48:54+00:00 jsing 2024-08-02T10:48:54+00:00 urn:sha1:238e8f729447488ba7da46567db3c52117fd06ad 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@