netdev - eBPF tunable max instructions or max tail call?

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-next>] [day] [month] [year] [list]

Message-ID: <CAMp4zn-6G+41PrsAHH3ZuKcKa-o16_d7ZEuRE517v42iA=Y-Ug@mail.gmail.com>
Date:	Mon, 11 Jul 2016 17:56:07 -0700
From:	Sargun Dhillon <sargun@...gun.me>
To:	netdev@...r.kernel.org
Subject: eBPF tunable max instructions or max tail call?

It would be nice to have eBPF programs that are longer than 4096
instructions. I'm trying to implement XSalsa20 in eBPF, and
unfortunately, it doesn't fit into 4096 instructions since I'm
unrolling all of the loops. Further than that, doing tail calls to
process each block results in me hitting the tail call limit.

It don't think that it makes much sense to expose the crypto API as
BPF helpers, as I'm not sure if we can ensure safety, and timely
execution with it. I may be wrong here, and if there is a sane, safe
way to expose the crypto API, I'm all ears.

Other than that, it would be nice to make the max instructions a knob,
and I don't think that it has much downside, given it's only checked
on load time. It would be nice to make the tail call limit a tunable
as well, but I'm unsure of the performance impact it might have given
that it's checked at runtime.

What do y'all think is reasonable? Make them both tunable? Just one? None?