netdev - Re: [PATCH v2 net-next 0/8] Introduce bpf ID

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]

Message-ID: <cae83d5f-85ea-4c16-5f6b-2b71f0768b05@fb.com>
Date:   Thu, 1 Jun 2017 11:27:56 -0700
From:   Alexei Starovoitov <ast@...com>
To:     David Ahern <dsahern@...il.com>, Jakub Kicinski <kubakici@...pl>,
        Martin KaFai Lau <kafai@...com>,
        Hannes Frederic Sowa <hannes@...essinduktion.org>
CC:     <netdev@...r.kernel.org>, Daniel Borkmann <daniel@...earbox.net>,
        <kernel-team@...com>
Subject: Re: [PATCH v2 net-next 0/8] Introduce bpf ID

On 6/1/17 10:51 AM, David Ahern wrote:
> On 6/1/17 11:24 AM, Alexei Starovoitov wrote:
>>
>> what problem are we trying to solve?
>> If we don't agree on the problem, we won't be able to agree on the
>> solution.
>
> I want the ability to retrieve the BPF instructions pushed to the
> kernel. Not just for cgroups and VRF, but everywhere - cgroups, sockets,
> xdp, filters, etc. I have this stated many times, including to you at
> netconf in April. From that discussion and the discussion on the RFC
> patch I sent in February, I thought we had an agreement that saving the
> instructions was the first step.
>
> Quentin at 6wind has expressed a similar interest for cls_bpf and
> act_bpf code.
>
> I read Jakub's email as wanting the same but for XDP.
>
> The patches I referenced earlier save the original instructions and
> enable them to be read by userspace from an fd return by the bpf
> syscall. Combine that with the ID and we have a solution.

Please explain the problem instead of pushing for 'solution'.
In this case I do not see a problem that saving original instructions
will solve.

'I want to retrieve original instructions' is not a problem. It's a
push for 'solution'. Explaining 'why' you want to see original
instructions would describe the actual problem.
If you're trying to debug something you're interested in original
source code and in the instructions that kernel is running.
To correlate to source code we have prog_tag (that was computed
over original insns).
To see kernel instructions in the interpreter and JITed assembler
we have this set of patches.
Original instructions are not useful for debugging,
since they have map_fds which can be long gone when program
is running, therefore to solve introspection problem we need to
look into real kernel instructions.

My understanding that 6wind wants to see original instructions to
accelerate them somehow using out of tree technology.
I'm not interested to help that cause. I also suspect that
retrieving kernel instructions will not be much different from
that point of view, but at least returning kernel insns is
solving introspection problem for everyone.

Returning kernel insns also doesn't burn unnecessary memory,
whereas original insns will be there as dead weight.
Hence before we add them we need to be absolutely clear that
there is no cheaper alternative possible.