summaryrefslogtreecommitdiff
path: root/src/lib/libc
diff options
context:
space:
mode:
authortb <>2021-12-24 12:02:15 +0000
committertb <>2021-12-24 12:02:15 +0000
commite52fde876fd50f605f22b3abd919333afe296d0a (patch)
tree518ab7c6cb69569d0b68bf095c06dc3de7f8d27f /src/lib/libc
parent7c2b9956d9045a7ef0f3b959fca4529c4078608f (diff)
downloadopenbsd-e52fde876fd50f605f22b3abd919333afe296d0a.tar.gz
openbsd-e52fde876fd50f605f22b3abd919333afe296d0a.tar.bz2
openbsd-e52fde876fd50f605f22b3abd919333afe296d0a.zip
Prepare to provide EVP_CIPHER_CTX_buf_noconst()
This is just a dumb 'return ctx->buf' whose name was chosen to be consistent with EVP_CIPHER_CTX_iv{,_noconst}() though there is no EVP_CIPHER_CTX_buf() ok jsing The backstory is this: This wonderful API will be needed by MariaDB once EVP is opaque. To be able to use its own handrolled AES CTR variant, it needs to reach inside the cipher ctx's buffer and mess with it: uchar *buf= EVP_CIPHER_CTX_buf_noconst(ctx); /* Not much we can do, block ciphers cannot encrypt data that aren't a multiple of the block length. At least not without padding. Let's do something CTR-like for the last partial block. NOTE this assumes that there are only buf_len bytes in the buf. If OpenSSL will change that, we'll need to change the implementation of this class too. */ Being the dumb return ctx->buf that it is, the EVP_CIPHER_CTX_buf_noconst() API obviously doesn't provide a means of doing any length checks. If it is any consolation, it was committed with the vague hope of being a temporary measure as OpenSSL commit 83b06347 suggests: Note that the accessors / writers for iv, buf and num may go away, as those rather belong in the implementation's own structure (cipher_data) when the implementation would affect them [...] As is true for many temporary kludges and dumb accessors, these are here to stay a with us for a while. While I'm at it, MariaDB has other phantastic things it did to ease its pain with the OpenSSL 1.1 API transition. To avoid one of two allocations (we're talking about ~50 and ~170 bytes) per EVP_{MD,CIPHER}_CTX instantiation, it defines EVP_{MD,CIPHER}_CTX_SIZE and uses arrays of these sizes that it aligns, casts and passes as ctx to the EVP API. Of course, they need to safeguard themselves against the inevitable buffer overruns that this might cause since the type is opaque and could (and actually did) change its size between two OpenSSL releases. There is a runtime check in mysys_ssl/openssl.c that uses CRYPTO_set_mem_functions() to replace malloc() with "coc_malloc()" to determine the sizes that OpenSSL would allocate internally when doing EVP_{MD,CIPHER}_CTX_new() and match them to MariaDB's ideas of the ctx sizes. Go look, I'm not making this stuff up.
Diffstat (limited to 'src/lib/libc')
0 files changed, 0 insertions, 0 deletions