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

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 22 Apr 2020 13:21:09 +0200

David Ahern <[email-masked]> writes:

> On 4/21/20 7:25 AM, Toke Høiland-Jørgensen wrote:
>> David Ahern <[email-masked]> 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