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]

Date:   Sat, 8 Oct 2016 12:11:51 -0700
From:   Tom Herbert <tom@...bertland.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Code quality and XDP

On Fri, Oct 7, 2016 at 9:28 PM, Jesper Dangaard Brouer
<brouer@...hat.com> wrote:
>
> 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.
>
As I mentioned the ability to run arbitrary programs can be explicitly
be disabled for such use-cases. But not all use cases of XDP require
such dynamic program-ability and not every user is going to need or
want this capability. For instance, an ILA router should be a
straightforward program to implement and not really need dynamic
modification (it is controlled through configuration). If someone
chooses to do a proprietary ILA router themselves they can do that by
disabling the lock-down, but they shouldn't expect any support from
the community when things got wrong. This is no different then when
people post to netdev about problems they are having with proprietary
modules. If they use an in-tree implementation then we could support
that.

Tom

>
>> 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