ktls: Add a tunable to disable TLS receive

[jhb]

Summary

TLS receive offload is really only beneficial for in-kernel use cases
(such as NFS over TLS) or when using a hardware offload. In addition,
several recent SAs have involved the TLS receive path, but the only
current mitigation for those is to disable TLS offload entirely.

Sponsored by: Netflix
Sponsored by: Chelsio Communications
Co-authored-by: John Baldwin <[e-mail]>

[markj]

tests/sys/kern/ktls_test.c

91

This should probably be ATF_REQUIRE_KTLS()?

[jhb]

I verified that with the default (still enabled), all of the current kyua tests still passed. I then disabled the sysctl and ran the stock kyua tests followed by running the updated kyua tests. I verified that all of the failing tests from the old kyua tests became skipped tests in the new run with the exception of the ktls_listening_socket test that is now split into two separate tests. It DTRT where TX passes but RX is skipped in the new test suite when RX is disabled. In the old tests the single test failed when RX was disabled.

From Claude:

Commit fbd2c4f28f82 — ktls: Add a tunable to disable TLS receive
                                                                                                                            
Adds kern.ipc.tls.rx_enable (CTLFLAG_RWTUN) to allow disabling KTLS receive independently of transmit. Motivation is
security — provides a finer-grained mitigation for RX-path vulnerabilities without disabling all KTLS.                      
                
Kernel side:                                                                                                                
- The guard in ktls_enable_rx() is correctly extended: !ktls_offload_enable || !ktls_rx_offload_enable. The RX-specific
check is properly subordinate — if the global enable is off, you stop there.                                                
 
Test changes:                                                                                                               
- ATF_REQUIRE_KTLS_RX() correctly calls both require_ktls() and require_ktls_rx() — the former checks kern.ipc.tls.enable,
the latter checks kern.ipc.tls.rx_enable. So tests skip properly under either condition.                                    
- The old ktls_listening_socket test was testing both TX and RX in one body with duplicate structure. Refactoring it into a
shared helper ktls_listening_socket(tc, optname) and two separate ATF test cases (_tx / _rx) is cleaner and more correct —  
each can now carry its own ATF_REQUIRE_KTLS / ATF_REQUIRE_KTLS_RX check.                                                    
- The ATF_TP_ADD_TC registration at the bottom correctly replaces the single old test with the two new ones.
                                                                                                                            
Man page: ktls.4 is updated appropriately.

[jhb]

tests/sys/kern/ktls_test.c

91

Humm, it feels a bit odd to mix a macro and a function? Another approach would be to call ATF_REQUIRE_KTLS() from the body of require_ktls_rx() which might be cleaner as a "hard" enforcement that you always check the global before the rx knob?

[markj]

tests/sys/kern/ktls_test.c

91

The approach you suggested sounds fine too.

[ziaee]

I think this would be great for a Relnotes: yes!

[jhb]

Rework ATL_REQUIRE_KTLS_RX