netdev - Re: [PATCH net-next v5 1/3] net: flow_dissector: extend bpf flow dissector support with vnet hdr

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] [day] [month] [year] [list]

Date:   Fri, 11 Jun 2021 18:31:15 -0700
From:   Martin KaFai Lau <kafai@...com>
To:     Tanner Love <tannerlove.kernel@...il.com>
CC:     <netdev@...r.kernel.org>, "David S . Miller" <davem@...emloft.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Petar Penkov <ppenkov@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        Tanner Love <tannerlove@...gle.com>,
        Stanislav Fomichev <sdf@...gle.com>
Subject: Re: [PATCH net-next v5 1/3] net: flow_dissector: extend bpf flow
 dissector support with vnet hdr

On Fri, Jun 11, 2021 at 06:13:42PM -0700, Martin KaFai Lau wrote:
> On Fri, Jun 11, 2021 at 02:07:10PM -0700, Tanner Love wrote:
> > > A nit. It is a good chance to move the new BTF_ID_LIST_SINGLE
> > > and most of the check_flow_keys_access() to filter.c.
> > > Take a look at check_sock_access().
> > >
> > 
> > It's not clear to me why it's preferable to move most of the
> > check_flow_keys_access() to filter.c. In particular, the part of
> > your comment that I don't understand is the "most of" part. Why
> > would we want to separate the flow-keys-access-checking logic
> > into two separate functions? Thanks
> Right, actually, the whole function can be moved.
> I found it easier to follow from flow_dissector_is_valid_access()
> to flow_keys's access check without jumping around between two
> different files.
The verifier verbose() logs can be kept in verifier.c though.  I
think all the -EACCES cases can be consolidated to one verbose()
call in check_mem_access() under PTR_TO_FLOW_KEYS.