netdev - Re: [PATCH 2/2] rust: add socket support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <01010188279a3c77-331a93b1-4bef-491f-b772-564ec329b92c-000000@us-west-2.amazonses.com>
Date: Wed, 17 May 2023 02:46:39 +0000
From: FUJITA Tomonori <tomo@...bit.dev>
To: wedsonaf@...il.com
Cc: tomo@...bit.dev, rust-for-linux@...r.kernel.org,
 netdev@...r.kernel.org, linux-crypto@...r.kernel.org,
 fujita.tomonori@...il.com
Subject: Re: [PATCH 2/2] rust: add socket support

Hi,

On Tue, 16 May 2023 14:08:47 -0300
Wedson Almeida Filho <wedsonaf@...il.com> wrote:

> We have basic networking support in the `rust` branch. In fact, we
> also have support for async networking in there as well. For example,
> the 9p server uses it.
> 
> At the moment we're prioritizing upstreaming the pieces for which we
> have projects waiting. Do you have an _actual_ user in mind for this?

I've implemented in-kernel TLS 1.3 handshake on the top of this.

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

The in-kernel TLS handshake feature is controversial. Proposals were
rejected in the past. So I like to know the opinions of subsystem
maintainers early, implementing in-kernel security-relevant code in
Rust could change the situation.

The requirement for networking is simple, read/write with a vector and
setsockopt. So I submitted minimum abstractions.

> In any case, let's please start with that instead of a brand-new
> reimplementation.

Sure, if netdev maintainers could merge Rust abstractions for
networking soon, I'll rework on this. But I don't think there is much
overlap between this and rust branch. Even if we could have
abstractions specific for TCP like TcpListener and TcpStream, we still
need thin abstractions for socket because there are several use-cases
of non IP sockets, I think.

Thanks,