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: <20170511.211920.2220259143750653022.davem@davemloft.net>
Date:   Thu, 11 May 2017 21:19:20 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     ast@...com
Cc:     daniel@...earbox.net, netdev@...r.kernel.org
Subject: Re: BPF relocations

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.

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.

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.