netdev - Re: [PATCH net-next v2 3/4] net: check tunnel option type in tunnel flags

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: <20180628094206.62b6d8e2@redhat.com>
Date:   Thu, 28 Jun 2018 09:42:06 +0200
From:   Jiri Benc <jbenc@...hat.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>, davem@...emloft.net,
        Roopa Prabhu <roopa@...ulusnetworks.com>, jiri@...nulli.us,
        jhs@...atatu.com, xiyou.wangcong@...il.com,
        oss-drivers@...ronome.com, netdev@...r.kernel.org,
        Pieter Jansen van Vuuren 
        <pieter.jansenvanvuuren@...ronome.com>
Subject: Re: [PATCH net-next v2 3/4] net: check tunnel option type in tunnel
 flags

On Wed, 27 Jun 2018 11:49:49 +0200, Daniel Borkmann wrote:
> Looks good to me, and yes in BPF case a mask like TUNNEL_OPTIONS_PRESENT is
> right approach since this is opaque info and solely defined by the BPF prog
> that is using the generic helper.

Wouldn't it make sense to introduce some safeguards here (in a backward
compatible way, of course)? It's easy to mistakenly set data for a
different tunnel type in a BPF program and then be surprised by the
result. It might help users if such usage was detected by the kernel,
one way or another.

I'm thinking about something like the BPF program voluntarily
specifying the type of the data; if not specified, the wildcard would be
used as it is now.

 Jiri