netdev - Re: Code quality and XDP

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: <20161008062817.45d6ac2b@redhat.com>
Date:   Sat, 8 Oct 2016 06:28:17 +0200
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Tom Herbert <tom@...bertland.com>
Cc:     brouer@...hat.com,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Code quality and XDP


On Sat, 8 Oct 2016 07:25:01 +0900 Tom Herbert <tom@...bertland.com> wrote:

> One concern raised at netdev concerning XDP is how are we going to
> maintain code quality, security, and correctness of programs being
> loaded. With kernel bypass it is not just the kernel code path that is
> being bypassed, but also the processes that hold the quality of code
> being accepted to a high bar. Our users expect that quality to be
> maintained.
> 
> I suggest that we need XDP programs to be subject to the same scrutiny
> that any other kernel netdev code is. One idea is to sign programs
> that have been accepted into the kernel. By default only signed
> programs would be allowed to be loaded, the override to allow unsigned
> programs might be a kernel config or a least a boot parameter
> (enabling the override needs to be very explicit).

Sorry, I think this "lock-down" will kill the DDoS use-case.  In the
DDoS mitigation use-case, is all about flexibility to adapt quickly to
changing attacks.  Thus, you need the ability to quickly modify your
programs to catch attack signatures.


> The acceptable XDP programs should probably be under their own
> directory. Such a directory should only contain kernel code, not
> userspace code also as is currently in samples/bpf.
>
> A nice side effect of this model is when the same XDP programs are
> being used in non-Linux environments (HW offload, other OSes, etc.)
> the process could maintain quality expections in those environments
> also.

I'm not against having some 'signed' eBPF/XDP programs.  If a XDP
programs behavior is well-defined enough, this would also open up for
HW offloading of "programs" that does the same functionality (without
looking at the eBPF code).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer