Kernel TLS in 4.13-rc1

Kernel TLS in 4.13-rc1

[David Oberhollenzer]

Hi!

I recently wanted to take a look at the kernel TLS support that
made it into 4.13-rc1, but ran into some issues.

After fixing the benchmark/test tool that the patch description
linked to (https://github.com/Mellanox/tls-af_ktls_tool) to make
sure that the server and client actually *agree* on AES-128-GCM,
I simply ran the client program with the --verify-sendpage option.

The handshake and setting up of the sockets appears to work but
the program complains that the sent and received page contents
do not match (sent is 0x12 repeated all over and received looks
pretty random).

I compiled the 4.13-rc1 tarball from kernel.org with
defconfig/kvmconfig for x86_64 and ran it on qemu using a
freshly debootstraped Debian sid rootfs.

I previously also tried it on a physical machine (localmodconfig,
also x86_64), running CentOS 7 and a custom build of recent gnutls
and its dependencies, with the same results.

Surely somebody must have tested this before it was merged? What
am I missing? Am I using a broken version of the benchmark tool
or am I holding it wrong?


Thanks,

David

Re: Kernel TLS in 4.13-rc1

[Dave Watson]

On 07/23/17 09:39 PM, David Oberhollenzer wrote:
> After fixing the benchmark/test tool that the patch description
> linked to (https://github.com/Mellanox/tls-af_ktls_tool) to make
> sure that the server and client actually *agree* on AES-128-GCM,
> I simply ran the client program with the --verify-sendpage option.
> 
> The handshake and setting up of the sockets appears to work but
> the program complains that the sent and received page contents
> do not match (sent is 0x12 repeated all over and received looks
> pretty random).

The --verify functions depend on the RX path as well, which has not
been merged.  Any programs / tests using OpenSSL + patches should work
fine.

If you want to use the tool, something like this should work, so that
the receive path uses gnutls:

./server --no-echo

./client --server-port 12345 --sendfile some_file --server-host localhost

Re: Kernel TLS in 4.13-rc1

[David Oberhollenzer]

On 07/24/2017 11:10 PM, Dave Watson wrote:
> On 07/23/17 09:39 PM, David Oberhollenzer wrote:
>> After fixing the benchmark/test tool that the patch description
>> linked to (https://github.com/Mellanox/tls-af_ktls_tool) to make
>> sure that the server and client actually *agree* on AES-128-GCM,
>> I simply ran the client program with the --verify-sendpage option.
>>
>> The handshake and setting up of the sockets appears to work but
>> the program complains that the sent and received page contents
>> do not match (sent is 0x12 repeated all over and received looks
>> pretty random).
> 
> The --verify functions depend on the RX path as well, which has not
> been merged.  Any programs / tests using OpenSSL + patches should work
> fine.
> 
> If you want to use the tool, something like this should work, so that
> the receive path uses gnutls:
> 
> ./server --no-echo
> 
> ./client --server-port 12345 --sendfile some_file --server-host localhost
> 

Thanks! This appears to work as expected (output from the server matches the
input from the client and the pcap dumps look fine).

>From briefly browsing through the code of the test tool I was initially under
the impression that it would generate an error message and terminate if an
attempt was made at configuring ktls for the RX path.

Anyway, I already read in the patch description that RX wasn't included yet,
still requires a few cleanups and would follow at some point.

Is there currently a "not-so-clean" version of the RX patches floating around
somewhere that we could take a look at?


Thanks,

David

Re: Kernel TLS in 4.13-rc1

[Dave Watson]

On 07/30/17 11:14 PM, David Oberhollenzer wrote:
> On 07/24/2017 11:10 PM, Dave Watson wrote:
> > On 07/23/17 09:39 PM, David Oberhollenzer wrote:
> >> After fixing the benchmark/test tool that the patch description
> >> linked to (https://github.com/Mellanox/tls-af_ktls_tool) to make
> >> sure that the server and client actually *agree* on AES-128-GCM,
> >> I simply ran the client program with the --verify-sendpage option.
> >>
> >> The handshake and setting up of the sockets appears to work but
> >> the program complains that the sent and received page contents
> >> do not match (sent is 0x12 repeated all over and received looks
> >> pretty random).
> > 
> > The --verify functions depend on the RX path as well, which has not
> > been merged.  Any programs / tests using OpenSSL + patches should work
> > fine.
> > 
> > If you want to use the tool, something like this should work, so that
> > the receive path uses gnutls:
> > 
> > ./server --no-echo
> > 
> > ./client --server-port 12345 --sendfile some_file --server-host localhost
> > 
> 
> Thanks! This appears to work as expected (output from the server matches the
> input from the client and the pcap dumps look fine).
> 
> From briefly browsing through the code of the test tool I was initially under
> the impression that it would generate an error message and terminate if an
> attempt was made at configuring ktls for the RX path.
> 
> Anyway, I already read in the patch description that RX wasn't included yet,
> still requires a few cleanups and would follow at some point.
> 
> Is there currently a "not-so-clean" version of the RX patches floating around
> somewhere that we could take a look at?

I dumped the current state here.  Still plenty rough but at least passes
--verify-transmission for me.

https://github.com/ktls/net_next_ktls/tree/tls_recv_net_next

and config changes to af_ktls-tool

https://github.com/ktls/af_ktls-tool/tree/RX