netdev - Re: Suggestions for TC Rust Projects

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]

Date: Wed, 24 Jan 2024 08:52:33 -0300
From: Pedro Tammela <pctammela@...atatu.com>
To: Trevor Gross <tmgross@...ch.edu>, Jamal Hadi Salim <jhs@...atatu.com>
Cc: netdev@...r.kernel.org, rust-for-linux@...r.kernel.org,
 Cong Wang <xiyou.wangcong@...il.com>, Jiri Pirko <jiri@...nulli.us>
Subject: Re: Suggestions for TC Rust Projects

On 24/01/2024 03:10, Trevor Gross wrote:
> On Tue, Jan 23, 2024 at 3:23 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>> [...]
>>
>> I think a good starting point would be tc actions. You can write a
>> simple hello world action.
>> Actions will put to test your approach for implementing netlink and
>> skbs which are widely used in the net stack for both control(by
>> netlink) and the runtime datapath. If you can jump that hoop it will
>> open a lot of doors for you into the network stack.
>> Here's a simple action:
>> https://elixir.bootlin.com/linux/v6.8-rc1/source/net/sched/act_simple.c
>> Actually that one may be hiding a lot of abstractions - but if you
>> look at it we can discuss what it is hiding.
> 
> That sounds great, getting an OOT equivalent should be a feasible
> first step. I will pass the information along.
> 
>> Note: We have written user space netlink code using rust and it was
>> fine but the kernel side is more complex.
> 
> Would that be the code at https://github.com/rust-netlink? 

Not really, we wrote a small low level netlink library for an internal tool.
What Jamal means is that dealing with netlink as it was intended in Rust 
is not a huge hassle[1]. When we were writing the tool we saw that all 
of the existing netlink libraries at the time were doing a serialization 
model, which was not acceptable to us. We wanted to build the message in 
place without any intermediate structs.

The challenging part for the kernel part will probably be the 
abstraction and the interfacing with all the C API that exists to 
validate the netlink attributes which is a must.

As for documentation `man 7 netlink` is pretty complete and the iproute2 
source code is usually a good test suite for responses.

[1]

Take a look at this snippet for instance:

```
#[derive(Default, NetlinkPolicy)]
pub struct P4TCActOpts {
     #[nlattr(nldefs::P4TC_ACT_OPT)]
     sel: nltypes::DynaSel,
}

#[derive(Default, NetlinkPolicy)]
pub struct TCAction {
     #[nlattr_str(nldefs::TCA_ACT_KIND)]
     kind: String,
     #[nlnest(nldefs::TCA_ACT_OPTIONS)]
     opt: P4TCActOpts,
}
```

The NetlinkPolicy trait handles all the boilerplate to construct the 
message in place and in our implementation it's method base:

```
let action = TCAction::default();
action.kind(msg, "foo"); // Adds the attribute `TCA_ACT_KIND` to the msg 
in place
```

It kind of resembles the netlink policies in the kernel, so perhaps the 
above could be a good starting point for the kernel abstraction.