> On Feb 21, 2023, at 11:58 AM, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > >> On Feb 21, 2023, at 11:55 AM, David Howells <dhowells@xxxxxxxxxx> wrote: >> >> >> Since the first day of the LSS is the same as the final day of LSF and in the >> same venue, are there any filesystem + security subjects that would merit a >> common session? >> >> LSF/MM, May 8–10, Vancouver, BC (Canada) >> https://events.linuxfoundation.org/lsfmm >> >> LSS-NA, May 10-12, Vancouver, BC (Canada) >> https://events.linuxfoundation.org/linux-security-summit-north-america > > Two I know about: > > Network filesystems have ongoing interest in the kernel's Kerberos > infrastructure. > > NVMe and NFS folks are working on a TLS handshake upcall mechanism. A related topic is: why do we have to have an upcall for things like transport security layer handshakes? An upcall for this is going to cramp our ability to support TLS-protected root partitions and NFSROOT, for instance. The main complaint we are aware of is that the kernel's crypto library lags behind user space crypto. What is being done to keep the kernel crypto library modern? Alternately, are there solutions that would enable the kernel to safely invoke user space libraries without requiring an upcall/remote procedure call mechanism? Note that TLSv1.3 is not the only consumer of such a mechanism. There are other transport layer protocols that require a substantial handshake (eg, mutual authentication and/or cipher negotiation). There has been recent work for example on negotiating with computational storage where some attestation or other security steps are required before the CS device can be trusted. -- Chuck Lever
