netdev - Re: [RFC PATCHv2 bpf-next 1/2] xdp: add a new helper for dev map multicast support

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: <FDBD279B-B6F2-4612-B962-75CAFE147B0C@redhat.com>
Date:   Tue, 28 Apr 2020 13:09:32 +0200
From:   "Eelco Chaudron" <echaudro@...hat.com>
To:     "Lorenzo Bianconi" <lorenzo.bianconi@...hat.com>
Cc:     "Hangbin Liu" <liuhangbin@...il.com>, bpf@...r.kernel.org,
        netdev@...r.kernel.org,
        "Toke Høiland-Jørgensen" <toke@...hat.com>,
        "Jiri Benc" <jbenc@...hat.com>,
        "Jesper Dangaard Brouer" <brouer@...hat.com>, ast@...nel.org,
        "Daniel Borkmann" <daniel@...earbox.net>
Subject: Re: [RFC PATCHv2 bpf-next 1/2] xdp: add a new helper for dev map
 multicast support



On 24 Apr 2020, at 16:19, Lorenzo Bianconi wrote:

[...]

>> +{
>> +
>> +	switch (map->map_type) {
>> +	case BPF_MAP_TYPE_DEVMAP:
>> +		return dev_map_get_next_key(map, key, next_key);
>> +	case BPF_MAP_TYPE_DEVMAP_HASH:
>> +		return dev_map_hash_get_next_key(map, key, next_key);
>> +	default:
>> +		break;
>> +	}
>> +
>> +	return -ENOENT;
>> +}
>> +
>> +bool dev_in_exclude_map(struct bpf_dtab_netdev *obj, struct bpf_map 
>> *map,
>> +			int exclude_ifindex)
>> +{
>> +	struct bpf_dtab_netdev *in_obj = NULL;
>> +	u32 key, next_key;
>> +	int err;
>> +
>> +	if (!map)
>> +		return false;
>
> doing so it seems mandatory to define an exclude_map even if we want 
> just to do
> not forward the packet to the "ingress" interface.
> Moreover I was thinking that we can assume to never forward to in the 
> incoming
> interface. Doing so the code would be simpler I guess. Is there a use 
> case for
> it? (forward even to the ingress interface)
>

This part I can answer, it’s called VEPA, I think it’s part of IEEE 
802.1Qbg.