netdev - Re: [PATCH net-next] netfilter: revert introduction of egress hook

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: <c7c6fb40-06f9-8078-6f76-5dc75a094e25@iogearbox.net>
Date:   Wed, 18 Mar 2020 11:50:56 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Florian Westphal <fw@...len.de>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Alexei Starovoitov <ast@...nel.org>
Subject: Re: [PATCH net-next] netfilter: revert introduction of egress hook

On 3/18/20 11:02 AM, Florian Westphal wrote:
> Daniel Borkmann <daniel@...earbox.net> wrote:
>> This reverts the following commits:
>>
>>    8537f78647c0 ("netfilter: Introduce egress hook")
>>    5418d3881e1f ("netfilter: Generalize ingress hook")
>>    b030f194aed2 ("netfilter: Rename ingress hook include file")
>>
>>  From the discussion in [0], the author's main motivation to add a hook
>> in fast path is for an out of tree kernel module, which is a red flag
>> to begin with.
> 
> The author did post patches for nftables, i.e. you can hook up rulesets to
> this new hook point.
> 
>> is on future extensions w/o concrete code in the tree yet. Revert as
>> suggested [1] given the weak justification to add more hooks to critical
>> fast-path.
> 
> Do you have an alternative suggestion on how to expose this?

Yeah, I think we should not plaster the stack with same/similar hooks that
achieve the same functionality next to each other over and over at the cost
of performance for users .. ideally there should just be a single entry point
that is very lightweight/efficient when not used and can otherwise patch to
a direct call when in use. Recent work from KP Singh goes into this direction
with the fmodify_return work [0], so we would have a single static key which
wraps an empty function call entry which can then be patched by the kernel at
runtime. Inside that trampoline we can still keep the ordering intact, but
imho this would overall better reduce overhead when functionality is not used
compared to the practice of duplication today.

Thanks,
Daniel

   [0] https://lore.kernel.org/bpf/20200304191853.1529-1-kpsingh@chromium.org/