netdev - Re: [PATCH bpf-next 04/16] net: Add BPF_XDP_EGRESS as a bpf_attach

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:   Tue, 21 Apr 2020 07:49:23 -0600
From:   David Ahern <dsahern@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, kuba@...nel.org,
        prashantbhole.linux@...il.com, jasowang@...hat.com,
        brouer@...hat.com, toshiaki.makita1@...il.com,
        daniel@...earbox.net, john.fastabend@...il.com, ast@...nel.org,
        kafai@...com, songliubraving@...com, yhs@...com, andriin@...com,
        David Ahern <dahern@...italocean.com>
Subject: Re: [PATCH bpf-next 04/16] net: Add BPF_XDP_EGRESS as a
 bpf_attach_type

On 4/21/20 7:25 AM, Toke Høiland-Jørgensen wrote:
> David Ahern <dsahern@...il.com> writes:
> 
>> On 4/21/20 4:14 AM, Toke Høiland-Jørgensen wrote:
>>> As I pointed out on the RFC patch, I'm concerned whether this will work
>>> right with freplace programs attaching to XDP programs. It may just be
>>> that I'm missing something, but in that case please explain why it
>>> works? :)
>>
>> expected_attach_type is not unique to XDP. freplace is not unique to
>> XDP. IF there is a problem, it is not unique to XDP, and any
>> enhancements needed to freplace functionality will not be unique to XDP.
> 
> Still needs to be fixed, though :)

one problem at a time. I have a long list of items that are directly
relevant to what I want to do.

> 
> Also, at least looking through all the is_valid_access functions in
> filter.c, they all seem to "fail safe". I.e., specific
> expected_attach_type values can permit the program access to additional
> ranges. In which case an freplace program that doesn't have the right
> attach type will just be rejected if it tries to access such a field.
> Whereas here you're *disallowing* something based on a particular
> expected_attach_type, so you can end up with an egress program that
> should have been rejected by the verifier but isn't because it's missing
> the attach_type.

There are 6 existing valid access checks on expected_attach_type doing
the exact same thing - validating access based on attach type.