netdev - Re: [oss-drivers] Re: [PATCH bpf] bpf: verifier: make sure callees don't prune with caller differences

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

Date:   Thu, 13 Dec 2018 10:57:44 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Jiong Wang <jiong.wang@...ronome.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        daniel@...earbox.net, oss-drivers@...ronome.com,
        netdev@...r.kernel.org
Subject: Re: [oss-drivers] Re: [PATCH bpf] bpf: verifier: make sure callees
 don't prune with caller differences

On Thu, Dec 13, 2018 at 04:40:06PM +0000, Edward Cree wrote:
> On 13/12/18 10:52, Jiong Wang wrote:
> > Because there is inter-procedure register allocation support in LLVM
> > (-enable-ipra), which could effectively eliminate register save/restore for
> > one caller-saved register across function call if the compiler can prove
> > callee or any other childs on the callgraph doesn't use/clobber this
> > particular caller-saved register. Then the later sequence in caller after
> > the call site could just safely read the caller-saved without restoring it
> > from stack etc. But we are marking all caller-saved as NOT_INIT, such read
> > will be treated as reading from uninitialized value, so the program will be
> > rejected.
> I think "all r1-r5 are clobbered on call" is part of the eBPF ISA.  In

right. it's part of the calling convention.
afaik ipra is enabled by default, but it's a nop for bpf backend
which doesn't allow leaf function. The backend always requests a frame
to be setup from llvm core which effectively disables ipra.

When we've been discussing on and off the idea to teach verifier to recognize
which registers are used, so JITs can optimize prologue/epilogue.
I think it will help, but probably not a lot at this point, since bpf progs
are still tiny.