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]
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.

Powered by blists - more mailing lists