netdev - Re: New xdpsock sample

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 28 Mar 2019 13:35:26 +0100
From:   Björn Töpel <bjorn.topel@...il.com>
To:     Maxim Mikityanskiy <maximmi@...lanox.com>
Cc:     Magnus Karlsson <magnus.karlsson@...il.com>,
        Magnus Karlsson <magnus.karlsson@...el.com>,
        Björn Töpel <bjorn.topel@...el.com>,
        Jonathan Lemon <bsd@...com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>
Subject: Re: New xdpsock sample

On Thu, 28 Mar 2019 at 10:48, Maxim Mikityanskiy <maximmi@...lanox.com> wrote:
>
[...]
> > > Thanks for the good input, Max! The rationale for making the sample
> > > simpler, was that most people was just C&Ping from it and used it in
> > > their own code, so we aimed for a simple "fits-most-people" sample.
>
> I don't think it's easier for them to use binaries in their own code
> than proper sources. Having the XDP program built from sources in libbpf
> doesn't complicate the sample in any way, though.
>

Correct, but then Clang would be a libbpf build dependency. Maybe
that's ok? If that is added, I'd be happy do remove the raw BPF
instructions. Personally, I don't have a hard time reading a couple of
lines of assembly, but I see your point and agree. Having it as C-code
would be better for the libbpf developers -- if the Clang build
dependency is ok.

> > > Let's make an "advanced user" sample as well, and add shared umem
> > > support to libbpf!
>
> Why create another sample if we have this one? Actually, how making
> another sample fixes this one? The issue is in libbpf anyway. It has a
> blob inside with no tools to regenerate it from C sources. And this lib
> is not even a sample, it can be used by real applications. Of course, it
> should be editable, otherwise no new feature can be added (without
> manually writing bytecode), and it's not the matter of shared UMEM.
>

Magnus and I took the route to simplify the sample, to make it easier
for new users. I still think that was the right path. Should there be
a sample showcasing all the knobs/pulleys? Sure.

> > > ...and as always, patches are very much welcome!
>
> Good approach - to drop a feature and wait until someone submits a patch
> to restore it. And how do you imagine that patch that adds back shared
> UMEM? The blob in libbpf has to be edited to accomplish this. It makes
> unnecessary trouble for anyone trying to contribute.
>

I appreciate that you are looking into the code/design with
constructive remarks -- but please refrain from being snarky.


Björn