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: <20170601.145624.1727289342819240334.davem@davemloft.net>
Date:   Thu, 01 Jun 2017 14:56:24 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     dsahern@...il.com
Cc:     ast@...com, kubakici@...pl, kafai@...com,
        hannes@...essinduktion.org, netdev@...r.kernel.org,
        daniel@...earbox.net, kernel-team@...com
Subject: Re: [PATCH v2 net-next 0/8] Introduce bpf ID

From: David Ahern <dsahern@...il.com>
Date: Thu, 1 Jun 2017 12:52:28 -0600

> On 6/1/17 12:27 PM, Alexei Starovoitov wrote:
>> '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.
> 
> I have explained this.
> 
> You are creating this hyper-complex almost completely invisible
> infrastructure. You are enabling binary blobs that can bypass the
> network stack and modify packets with almost no introspection on what is
> happening. BPF code can from a variety of sources -- OS vendors,
> upstream repos, 3rd party vendors (eg., H/W vendors), and "in-house"
> development. Each will swear to the end that any observed problem is not
> with their code. In my experience, it falls on to the OS and kernel
> experts to figure out why Linux is breaking something. To do that we
> need tools to look at what code is running where and something that can
> be used in production environments not requiring a disruption to the
> service that the box is providing.

I'm not convinced that the verifier processed instruction stream
cannot provide that facility properly.

In fact, because of how the maps and tail calls work, you can only
figure out what is really executing by looking at the final processed
instruction stream.