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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k1277om2.fsf@toke.dk>
Date:   Wed, 22 Apr 2020 13:21:09 +0200
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     David Ahern <dsahern@...il.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

David Ahern <dsahern@...il.com> writes:

> 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.

Not saying a fix to freplace *has* to be part of this series; just
saying that I would be more comfortable if that was fixed before we
merge this.

>> 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.

See my point about default black/white listing, though. You are adding a
new restriction to an existing program type based on this, so surely we
should make sure this restriction actually sticks, no?

-Toke