Re: Using a stock openssl BIO

> On 15 Jul 2021, at 04:17, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Thomas^WA bad person recently nerdsniped me (with the help of an accidental use
> of an SSL connection in a benchmark leading to poor results) into checking what
> would be needed to benefit from SSL/TLS hardware acceleration (available with
> suitable hardware, OS support (linux and freebsd) and openssl 3).

Now why does that sounds so familiar.. =)

> In the backend the first reason is:
>
> * Private substitute BIO: this does the sending and receiving using send() and
> * recv() instead. This is so that we can enable and disable interrupts
> * just while calling recv(). We cannot have interrupts occurring while
> * the bulk of OpenSSL runs, because it uses malloc() and possibly other
> * non-reentrant libc facilities.
>
> I think this part has been obsolete for a while now

I concur.

> The second part is
> * We also need to call send() and recv()
> * directly so it gets passed through the socket/signals layer on Win32.
>
> And the not stated need to set/unset pgwin32_noblock around the recv/send
> calls.
>
> I don't think the signal handling stuff is still needed with nonblocking
> sockets? It seems we could just ensure that there's a pgwin32_poll_signals()
> somewhere higher up in secure_read/write()? E.g. in
> ProcessClientReadInterrupt()/ProcessClientWriteInterrupt() or with an explicit
> call.
>
> And the pgwin32_noblock handling could just be done outside the SSL_read/write().

I hadn't yet looked at the pgwin32 parts in detail, but this is along what I
was thinking (just more refined).

> On the client side it looks like things would be a bit harder. The main problem
> seems to be dealing with SIGPIPE. We could possibly deal with that by moving
> the handling of that a layer up. That's a thick nest of ugly stuff :(.

My initial plan was to keep this for the backend, as the invasiveness of the
frontend patch is unlikely to be justified by the returns of the acceleration.

> FWIW, I don't think hardware tls acceleration is a particularly crucial thing
> for now.

Agreed, it will most likely be of limited use to most. It might however make
sense to "get in on the ground floor" to be ready in case it's expanded on in
kernel+OpenSSL with postgres automatically just reaping the benefits. Either
way I was hoping to get to a patch which is close enough to what it would need
to look like so we can decide with the facts at hand.

> I don't plan to work on this, but Thomas encouraged me to mention this on the
> list when I mention it to him.

I still have it on my TODO for after the vacation, and hope to reach that part
of the list soon.

--
Daniel Gustafsson https://vmware.com/