netdev - Re: [RFC][Proposal] BPF Control MAP

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: <20190320052752.xs4bf3v432b6thyx@ast-mbp.dhcp.thefacebook.com>
Date:   Tue, 19 Mar 2019 22:27:54 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Saeed Mahameed <saeedm@...lanox.com>
Cc:     "songliubraving@...com" <songliubraving@...com>,
        "toke@...hat.com" <toke@...hat.com>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "andrew.gospodarek@...adcom.com" <andrew.gospodarek@...adcom.com>,
        "jesper.brouer@...il.com" <jesper.brouer@...il.com>,
        "bblanco@...il.com" <bblanco@...il.com>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
        "iovisor-dev@...ts.iovisor.org" <iovisor-dev@...ts.iovisor.org>,
        "bjorn.topel@...il.com" <bjorn.topel@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "kafai@...com" <kafai@...com>
Subject: Re: [RFC][Proposal] BPF Control MAP

On Wed, Mar 20, 2019 at 04:47:11AM +0000, Saeed Mahameed wrote:
> 
> consider the following command line, with bpftool that compiled way
> before xsk-ring-szie attribute was introduced.

perfect. let's agree on the use case first...

> $ bpftool xdp set eth0 xsk-ring-size 128

would be great to have. no doubt.

> what this can eventually do:
>  
> fd = create_map(BPF_CONTROL, map_attr.ctrl_type = XDP_ATTR)
> 
> //Query BTF of the control (XDP) map
> query_map_attributes(fd, &map_attr);

and bpf_map_info returns btf_key_type_id and btf_value_type_id
Are you saying btf_key_type_id will return single u32 with name 'ifindex' ?
Where do you specify netns_id+dev_id ?

> // Find if control map values btf layout include the new member
> offset = btf_get_offset_of_memeber_name(map_attr.btf, "xsk-ring-size",
> BTF_TYPE_INT);
> if (offset < 0)
>      return offset; // the new member is not supported in kernel
> 
> *(value + offset) = (int)new_val;
> map_update(fd, <eth0 ifindex>, value);

what about other fields in this value ?
If zero do not update ?
Shouldn't it be read/modify/write ?
So lookup everything first, modify only that '*(value + offset)'
and do map_update ?
and the driver received full blob of bytes for all fields.
What driver suppose to do ? Rewrite all fields ?
Or try to be smart and do read+if_not_the_same_write ?

Different ifindexes will be different drivers,
so single map providing single btf_value_type_id for all of them
isn't going to work.

I hope you see that such api is falling apart even for simplest use case.