MBED-TLS/Wolf-TLS handshake and async pal-sk

[mkauli]

Hi,

I currently port the Edge-OPC proxy to our embedded firmware using an proprietary OS. Everything works find til the point when the MQTT connection should be established using TLS - tlsio_wolfssl & tlsio_mbedtls using sync calls to receive/send data while handshaking phase. For example the receive function expects that the receive buffer directly is filled when the receive function returns.

The problem is, the underlaying xio_sk (used by tlsio_wolfssl & tlsio_mbedtls) implements an async send/receive mechanism via prx-scheduler/pal-ev

How can I handle this issue? I saw that the involved sources are part of the shared-c-utility - maybe the shared-c-utility is a better place to ask?

Best regards Martin Kaul

[marcschier]

Hi Martin,

I think we should address this here. C-shared's IO abstractions are all based on the polling contract, and since our underlying XIO is not looping, but event driven, the behavior of the entire layered stack would be owned by us.

So to make it work for the other tlsio typically this means we need to ensure that __dowork logic is running periodically when Read/Write events are received and data is available. Since openssl and schannel do not need dowork to run by default - it works. However, openssl now also would benefit from dowork to be called for renego, so we should fix this in XIO.

Unfortunately this means we need a way to tell the top of the layered IO stack to call it, but only the bottom XIO knows when. So we need some signaling, i.e. a virtual dowork. And thus there is no easy workaround I think.

I have added this to our backlog.

Cheers, Marc

[marcschier]

The work was triaged, and moved to September.

[marcschier]

In the meantime, please could you sync to HEAD and see what's missing? I have added code to run dowork for every read and write event which should technically process the received buffers and pass them on up.

[mkauli]

Hi Marc,

thanks for your work and fast reply :-) - I will update my local version to head.

[marcschier]

@mkauli, no guarantees that this works with wolfssl. I believe it would and thus might be able to get you unblocked until we are able to add/test wolfssl end to end in September.

If you get unblocked, and you feel like changing the cmakelists.txt files to add wolfssl options, we would gladly take this as a contribution. In that case, it would also be super cool if you can add a dockerfile build environment in bld/docker, that this wolfssl cmake configuration can be built against! :-)