netdev - Re: BPF relocations

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: <7c4afd3f-7ff5-292c-57ad-c4aa2058a8eb@fb.com>
Date:   Thu, 11 May 2017 19:17:21 -0700
From:   Alexei Starovoitov <ast@...com>
To:     David Miller <davem@...emloft.net>
CC:     <daniel@...earbox.net>, <netdev@...r.kernel.org>
Subject: Re: BPF relocations

On 5/11/17 6:19 PM, David Miller wrote:
> From: Alexei Starovoitov <ast@...com>
> Date: Thu, 11 May 2017 16:10:35 -0700
>
>> I don't see what we would use pc-relative relo for.
>
> We must have them at least for banches.
>
> Internally, we have to emit some kind of relocation as GAS makes it's
> first pass over the instructions.
>
> Afterwards, it walks the relocations and resolves all that can be done
> at assembly time, and preserves as relocations in the object file for
> those which it cannot.

got it. yes.
llvm has this thing as well. It calls it FK_PCRel_2
(FK stands for Fixup Kind) which is 16-bit pc relative relo
into 'off' bits of insn.
Fortunately for LLVM this fixup is never converted to actual relo
and it is applied before final .o is emitted.

So, indeed, defining 16-bit pc-relative relo for branches is
definitely useful.
I can imagine someone combining two .o files with 'goto's
crossing two functions or something.
Let's pick a code for it.

> Thinking further down the line many other kinds of PC relative
> relocations are possible, even if you don't allow calls.  For example:
>
> 	ldimm64	R1, 24 + (. - external_label)
>
> This would be a 64-bit PC relative reloc, with the value 24 in the
> addend.

yes. that would be useful as well.
I don't mind defining it for our semi-official bpf relo spec :)

> And eventually we want full linking.
>
> The example above may seem silly, but every other full CPU ELF
> specification handles these things completely and we should seek to be
> complete as well.

I agree that the further we go the more complete it will become.
My concern that if we define too many things because other archs
have them we may end up not using them when time comes, since we
didn't think of some minor detail.
So today I would only add 16-bit pc-relative and 64-bit pc-relative.
The former is clearly useful for branches and the latter for calls
and jmp tables.
Right now we don't have simple 'switch()'. llvm has to convert it
into a sequence of branches. It's ok-ish. Ideally we need jmp-table
like normal cpus do and ldimm64 + relo should work for such purpose.