netdev - Re: [RFC PATCH net-next 1/2] bpf: Save original ebpf instructions

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:   Mon, 6 Feb 2017 11:56:40 +0100
From:   Quentin Monnet <quentin.monnet@...nd.com>
To:     David Ahern <dsa@...ulusnetworks.com>,
        Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
        alexei.starovoitov@...il.com
Cc:     roopa@...ulusnetworks.com
Subject: Re: [RFC PATCH net-next 1/2] bpf: Save original ebpf instructions

Hi Daniel, David,

2017-02-03 (15:28 -0700) ~ David Ahern <dsa@...ulusnetworks.com>
> On 2/3/17 2:09 PM, Daniel Borkmann wrote:
>> On 02/03/2017 09:38 PM, David Ahern wrote:
>>> Similar to classic bpf, support saving original ebpf instructions
>>>
>>> Signed-off-by: David Ahern <dsa@...ulusnetworks.com>
>>
>> Not convinced that this is in the right direction, this not only *significantly*
>> increases mem footprint for each and every program, but also when you dump this,
>> then map references from relocs inside the insns are meaningless (f.e. what about
>> prog arrays used in tail calls?), so things like criu also won't be able to use
>> this kind of interface for dump and restore. If it's just for debugging, then
>> why not extend the existing tracing infrastructure around bpf that was started
>> with intention to gain more visibility.
> 
> 
> Yes, saving the original bpf increases the memory footprint. If you noticed, a kmemdup is used for the exact instruction size (no page round up). Right now programs are limited to a single page, so worst case  is an extra page per program. I am open to other suggestions. For example, bpf_prog is rounded up to a page which means there could be room at the end of the page for the original instructions. This is definitely true for the ip vrf programs which will be < 32 instructions even with the namespace checking and the conversions done kernel side.
> 
> Tracepoints will not solve the problem for me for a number of reasons. Tracepoints have to be hit to return data, and there is no way the tracepoint can return relevant information for me to verify that the correct filter was downloaded. I want the original code. I want to audit what was installed. In my case there could be N VRFs, and I want 'ip vrf' or ifupdown2 or any other command to be able to verify that each cgroup has the correct program, and to verify that the default VRF does *not* have a program installed.
> 
> Generically, the bpf code might contain relative data but that's for the user or decoder program to deal with. Surely there is no harm in returning the original, downloaded bpf code to a properly privileged process. If I am debugging some weird network behavior, I want to be able to determine what bpf code is running where and to see what it is doing to whatever degree possible. Saving the original code is the first part of this.
> 

This reminds me of that patchset I sent some time ago [1] to dump a
program, and which was rejected for the same reasons. I'd like to stand
with David and confirm that I am interested as well in a solution that
would allow to dump the bytecode without relying on tracepoints.

Quentin

[1] https://www.spinics.net/lists/netdev/msg373259.html