netdev - Re: static and dynamic linking. Was: [PATCH bpf-next v3 1/5] bpf: Support chain calling multiple BPF

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: <8c251f3d-67bd-9bc2-8037-a15d93b48674@solarflare.com>
Date:   Tue, 12 Nov 2019 21:25:06 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>
CC:     John Fastabend <john.fastabend@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Marek Majkowski <marek@...udflare.com>,
        Lorenz Bauer <lmb@...udflare.com>,
        Alan Maguire <alan.maguire@...cle.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <bpf@...r.kernel.org>
Subject: Re: static and dynamic linking. Was: [PATCH bpf-next v3 1/5] bpf:
 Support chain calling multiple BPF

On 12/11/2019 19:52, Alexei Starovoitov wrote:
> We haven't yet defined what 'extern' keyword in the program means.
> There are a preliminary patches for llvm to support extern variables. Extern
> functions are not done yet. We have to walk before we run. With dynamic linking
> I'm proposing an api for the kernel that I think will work regardless of how
> libbpf and llvm decide to define the meaning of 'extern'.
Fwiw the 'natural' C way of doing it would be that for any extern symbol in
 the C file, the ELF file gets a symbol entry with st_shndx=SHN_UNDEF, and
 code in .text that uses that symbol gets relocation entries.  That's (AIUI)
 how it works on 'normal' architectures, and that's what my ebld linker
 understands; when it sees a definition in another file for that symbol
 (matched just by the symbol name) it applies all the relocations of the
 symbol to the appropriate progbits.
I don't really see what else you could define 'extern' to mean.

> Partial verification should be available regardless of
> whether kernel performs dynamic linking or libbpf staticly links multiple .o
> together.
It's not clear to me how partial verification would work for statically
 linked programs — could you elaborate on this?

-Ed