Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   FUJITA Tomonori <tomo@exabit.dev>
To:     rust-for-linux@vger.kernel.org, netdev@vger.kernel.org,
        linux-crypto@vger.kernel.org
Subject: [PATCH 0/2] rust: networking and crypto abstractions
Date:   Mon, 15 May 2023 04:34:27 +0000
Message-ID: <010101881db036fb-2fb6981d-e0ef-4ad1-83c3-54d64b6d93b3-000000@us-west-2.amazonses.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Feedback-ID: 1.us-west-2.j0GTvY5MHQQ5Spu+i4ZGzzYI1gDE7m7iuMEacWMZbe8=:AmazonSES
Precedence: bulk

This includes initial rust abstractions for networking and crypto.

I've been working on in-kernel TLS 1.3 handshake in Rust on the top of
this. Currently you can run simple TLS server code, which does a
handshake, sets up kTLS (Kernel TLS offload) to read and write some
bytes.

https://github.com/fujita/rust-tls

Seems that there are some potential users for in-kernel TLS 1.3
handshake (can be used for QUIC protocol too). Hopefully Rust could
help with auditing complicated security-relevant code in the kernel.

The TLS code isn't ready for reviewing yet but I like to push the
dependency for upstream. There might be other potential users for
networking and crypto abstractions.

The series should be cleanly applied to rust-next tree (ac9a786).

Note that this doesn't include all the dependency for the in-kernel
TLS handshake code. You can find at:

https://github.com/fujita/linux/tree/rust-tls


FUJITA Tomonori (2):
 rust: add synchronous message digest support
 rust: add socket support

rust/bindings/bindings_helper.h |   4 +
 rust/helpers.c                  |  24 ++++++
 rust/kernel/crypto.rs           | 108 +++++++++++++++++++++++++
 rust/kernel/lib.rs              |   4 +
 rust/kernel/net.rs              | 174 ++++++++++++++++++++++++++++++++++++++++
 5 files changed, 314 insertions(+)