On Tue, 14 Feb 2023 12:17:37 +0100 Sabrina Dubroca wrote: > Changes in v2 > use reverse xmas tree ordering in tls_set_sw_offload and > do_tls_setsockopt_conf > turn the alt_crypto_info into an else if > selftests: add rekey_fail test > > Vadim suggested simplifying tls_set_sw_offload by copying the new > crypto_info in the context in do_tls_setsockopt_conf, and then > detecting the rekey in tls_set_sw_offload based on whether the iv was > already set, but I don't think we can have a common error path > (otherwise we'd free the aead etc on rekey failure). I decided instead > to reorganize tls_set_sw_offload so that the context is unmodified > until we know the rekey cannot fail. Some fields will be touched > during the rekey, but they will be set to the same value they had > before the rekey (prot->rec_seq_size, etc). > > Apoorv suggested to name the struct tls_crypto_info_keys "tls13" > rather than "tls12". Since we're using the same crypto_info data for > TLS1.3 as for 1.2, even if the tests only run for TLS1.3, I'd rather > keep the "tls12" name, in case we end up adding a > "tls13_crypto_info_aes_gcm_128" type in the future. > > Kuniyuki and Apoorv also suggested preventing rekeys on RX when we > haven't received a matching KeyUpdate message, but I'd rather let > userspace handle this and have a symmetric API between TX and RX on > the kernel side. It's a bit of a foot-gun, but we can't really stop a > broken userspace from rolling back the rec_seq on an existing > crypto_info either, and that seems like a worse possible breakage. And how will we handle re-keying in offload? > include/net/tls.h | 4 + > net/tls/tls.h | 3 +- > net/tls/tls_device.c | 2 +- > net/tls/tls_main.c | 37 +++- > net/tls/tls_sw.c | 189 +++++++++++++---- > tools/testing/selftests/net/tls.c | 336 +++++++++++++++++++++++++++++- Documentation please.
