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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 7 May 2020 16:41:02 -0700
From:   Alexei Starovoitov <>
To:     John Fastabend <>
Cc:     Toke Høiland-Jørgensen <>,
        Björn Töpel <>,
        bpf <>, Netdev <>,
        Jesper Dangaard Brouer <>
Subject: Re: XDP bpf_tail_call_redirect(): yea or nay?

On Thu, May 7, 2020 at 11:09 AM John Fastabend <> wrote:
> I think it would work but I it would be even nicer if clang, verifier
> and jit caught the tail call pattern and did it automatically.

I've been advocating for proper tail calls for some time :)
All it needs is indirect jump instruction in the ISA.
The changes to llvm are trivial. Encoding of new insn is
straightforward as well.
The verifier side is tricky.
What you're proposing makes sense to me.
Somehow I thought that we need full indirect jump from day one,
but above is much simpler. It's a subset of it.
It's still an indirect jump, but target is always fixed.
The register will be initialized with fixed address of next kernel function
(or helper). That should be easy enough to support in the verifier.
llvm will generate:
ld_imm64 rX = addr_of_next_helper // that could be encoded via pseudo,
like for calls to helpers
jmp *rX

We can introduce an extension to JA insn instead that
takes 64-bit immediate or pc relative offset, but I think
it will be more messy to support through llvm, libbpf relocations and
the verifier.

Powered by blists - more mailing lists