netdev - Re: [RFC,POC] iptables/nftables to epbf/xdp via common intermediate layer

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]

Date:   Tue, 6 Mar 2018 19:03:09 +0100
From:   Florian Westphal <fw@...len.de>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Florian Westphal <fw@...len.de>,
        Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
        ast@...nel.org, pablo@...filter.org
Subject: Re: [RFC,POC] iptables/nftables to epbf/xdp via common intermediate
 layer

Edward Cree <ecree@...arflare.com> wrote:
> On 06/03/18 16:42, Florian Westphal wrote:
> > I would also add 'highlevel' objects that are themselves translated into
> > basic operations.  Most obvious example
> > are 'fetch 4 bytes x bytes into transport header'.
> >
> > Frontend should not need to bother with ipv4 details, such as ip
> > options.  Instead IMR should take care of this and generate the needed
> > instructions to fetch iph->ihl and figure out the correct transport
> > header offset.
> Presumably then for this the IMR regs will cease to have any connection to
>  BPF regs and will simply be (SSA?) r0, r1, ... as far as needed (not
>  limited to 10 regs like BPF)?  Then register allocation all happens in
>  the IMR->BPF conversion (even for things 64 bits or smaller).
> 
> I wonder how sophisticated we should be about register allocation; whether
>  we should go the whole hog with graph-colouring algorithms or linear
>  scan, or just do something naïve like an LRU.
> 
> Relatedly, should we spill values to the stack when we run out of
>  registers, or should we just rely on being able to rematerialise them
>  from parsing the packet again?

I don't know.  I suspect we should go for naive algorithm only,
but I would defer such decision to Alexei/Daniel.

f.e. i don't know if using llvm is a good idea or not, I did not
intend to turn proposed imr into full blown compiler in any case,
I only want to avoid code duplication for iptables/nftables -> ebpf
translator.