Don't mess up RelIplt symbols during relocatable processing
Summary:
During upgrading of the FreeBSD source tree with lld 7.0.0, I noticed
that it started complaining about crt1.o having an "index past the
end of the symbol table".
Such a symbol table looks approximately like this, viewed with
readelf -s (note the Ndx field being messed up):
Symbol table '.symtab' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 NOTYPE WEAK HIDDEN RSV[0xffff] __rel_iplt_end
3: 00000000 0 NOTYPE WEAK HIDDEN RSV[0xffff] __rel_iplt_start
At first, it seemed that recent ifunc relocation work had caused this:
<https://reviews.freebsd.org/rS339351>, but it turned out that it was
due to incorrect processing of the object files by lld, when using -r
(a.k.a. --relocatable).
Bisecting showed that rL324421 ("Convert a use of Config->Static") was
the commit where this new behavior began. Simply reverting it solved
the issue, and the __rel_iplt symbols had an index of UND again.
Looking at Rafael's commit message, I think he simply missed the
possibility of --relocatable being in effect, so I have added an
additional check for it.
I also added a simple regression test case.
Reviewers: grimar, ruiu, emaste, espindola
Reviewed By: ruiu
Subscribers: arichardson, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D53515
This fixes a problem in lld where it places incorrect indexes for ifunc
related symbols in crt1.o and friends, making it impossible to link most
normal programs with it.
Rework the way jemalloc uses mmap(2) on FreeBSD.
This makes it directly use MAP_EXCL and MAP_ALIGNED() instead
of weird workarounds involving mapping at random places and then
unmapping parts of them.
Discussed with: jasone
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Disable runtime detection of lazy purging support on FreeBSD.
The check doesn't seem to serve any purpose here, and this shaves
off three syscalls on binary startup.
Discussed by: jasone
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
If pf logs the user id ('pass out log (user)') have tcpdump also print
this.
Example output:
00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, ttl 64, id 57539, offset 0, flags [none], proto UDP (17), length 55)
172.16.2.2.18337 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x16e4!] 40222+ A? google.be. (27)
PR: 122773
Differential Revision: https://reviews.freebsd.org/D17625
Although _libelf_is_mips64el is only called in contexts where we've
already checked that e_class is ELFCLASS64 but this may change in the
future. Add a safety belt so that we don't access an invalid e_ehdr64
union member if it does.
Reported by: jkoshy (in review D17380)
In r339350 filter_reloc() was removed, to fix the case of stripping
statically linked binaries with relocations (which may come from ifunc
use, for example). As a side effect this changed the behaviour when
stripping object files - the output was broken both before and after
r339350, in different ways. Unfortunately GCC's build process relies
on the previous behaviour, so:
- Revert r339350, restoring filter_reloc().
- Fix an unitialized variable use (commited as r3638 in ELF Tool Chain).
- Change filter_reloc() to omit relocations referencing removed
symbols, while retaining relocations with no symbol reference.
- Retain the entire relocation section if it references the dynamic
symbol table (fix from kaiw in D17596).
PR: 232176
Reported by: antoine
Reviewed by: kaiw
MFC with: r339350
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17596
specified. This fixes searching the paths specified in
/usr/local/etc/man.d/*.conf, as currently apropos/whatis from mandoc
suite aren't aware about them.
PR: 227922
Reviewed by: bapt
Approved by: re (gjb), kib (mentor)
Differential Revision: https://reviews.freebsd.org/D17454
elfcopy contained logic to filter individual relocations in STRIP_ALL
mode. However, this is not valid; relocations emitted by the linker are
required, unless they apply to an entire section being removed (which is
handled by other logic in elfcopy).
Note that filter_reloc was also buggy: for RELA relocation sections it
operated on uninitialized rel.r_info resulting in invalid operation.
The logic most likely needs to be inverted: instead of removing
relocations because their associated symbols are being removed, we must
keep symbols referenced by relocations. That said, in practice we do
not encounter this code path today: objects being stripped are either
dynamically linked binaries which retain .dynsym, or static binaries
with no relocations.
Just remove filter_reloc. This fixes certain cases including statically
linked binaries containing ifuncs. Stripping binaries with relocations
referencing removed symbols was already broken, and after this change
may still be broken in a different way.
PR: 232176
Reviewed by: kaiw, kib, markj
Approved by: re (rgrimes)
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17519
ELF spec says that for SHT_REL and SHT_RELA sh_link should reference the
associated string table and sh_info should reference the "section to
which the relocation applies." ELF Tool Chain's elfcopy / strip use
this (in part) to control whether or not the relocation entry is copied
to the output.
LLVM PR 37538 https://bugs.llvm.org/show_bug.cgi?id=37538
Approved by: re (kib)
Obtained from: llvm r344226 (backported for 6.0)
move all elements from the adist_send and adist_recv lists back onto the
adist_free list, but we don't wake consumers waitings for the adist_free list
to become non-empty. This can lead to the sender process stopping audit trail
files distribution and waiting forever.
Fix the problem by adding the missing wakeup.
While here slow down spinning on CPU in case of a short race in
sender_disconnect() and add an explaination when it can occur.
PR: 201953
Reported by: peter
Approved by: re (kib)
file name and opening it. This race was not properly handled, because we were
copying new name before checking for openat(2) error and when we were trying
again we were starting with the next trail file. This could result in skipping
distribution of such a trail file.
Fix this problem by checking for ENOENT first (only for .not_terminated files)
and then updating (or not) tr_filename before restarting the search.
PR: 200139
Reported by: peter
Approved by: re (kib)
libelf maintains two views of endianness: e_byteorder, and
e_ident[EI_DATA] in the ELF header itself. e_byteorder is not always
kept in sync, so use the ELF header endianness to test for mips64el.
PR: 231790
Bisected by: sbruno
Reviewed by: jhb
Approved by: re (kib)
MFC with: r338478
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17380
Previously Clang required ifunc resolution functions to take no
arguments, presumably because GCC documented ifunc resolvers as taking
no arguments. However, GCC accepts resolvers accepting arguments, and
our rtld passes CPU ID information (cpuid, hwcap, etc.) to ifunc
resolvers. Just remove the check from the in-tree compiler for our in-
tree compiler; a different (per-OS) approach may be required upstream.
Reported by: mjg
Approved by: re (rgrimes)
MFC after: 1 week
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
For now, the libraries can be built and installed using:
cd /usr/src/lib/libclang_rt/fuzzer && \
make obj && \
make depend && \
make && \
sudo make install
cd /usr/src/lib/libclang_rt/fuzzer_no_main && \
make obj && \
make depend && \
make && \
sudo make install
See https://llvm.org/docs/LibFuzzer.html for more information.
[ELF] - Allow LLD to produce file symbols.
This is for PR36716 and
this enables emitting STT_FILE symbols.
Output size affect is minor:
lld binary size changes from 52,883,408 to 52,949,400
clang binary size changes from 83,136,456 to 83,219,600
Differential revision: https://reviews.llvm.org/D45261
This fixes a regression in lld that made it stop emitting STT_FILE
symbols, which ctfmerge relies upon to uniquify function table entries
that reference STB_LOCAL symbols. Consequently, ctfmerge stopped
emitting entries for static functions into the function table, and
dtrace no longer gets type info for them.
Approved by: re (kib)
Reported by: markj
PR: 230444
MFC after: 3 days
[CodeGen] Initialize large arrays by copying from a global
Currently, clang compiles explicit initializers for array elements
into series of store instructions. For large arrays of built-in types
this results in bloated output code and significant amount of time
spent on the instruction selection phase. This patch fixes the issue
by initializing such arrays with global constants that store the
binary image of the initializer.
Differential Revision: https://reviews.llvm.org/D43181
This should fix a compiler hang (and excessive memory usage) while
building the science/rmg port.
Approved by: re (kib)
Reported by: yuri@tsoft.com
See also: https://bugs.llvm.org/show_bug.cgi?id=38798
MFC after: 3 days
Initialize LiveRegs once in BranchFolder::mergeCommonTails
This should fix '(TRI && "LivePhysRegs is not initialized."' assertions
when building the lang/qt5-qml port in certain configurations.
Approved by: re (kib)
Reported by: Piotr Kubaj <pkubaj@anongoth.pl>
PR: 231355
MFC after: 3 days
the hard-coded string "not available" to ensure reproducible builds.
Discussed with: emaste
Approved by: re (rgrimes)
Sponsored by: The FreeBSD Foundation
Not all libpcap backends use the BPF compatible set
of IOCTLs. For example the mlx5 backend uses libibverbs
which is currently not capsicum compatible.
Disable sandboxing for such backends.
MFC after: 3 days
Discussed with: emaste@
Approved by: re (kib)
Sponsored by: Mellanox Technologies
Update libarchive to 3.3.3
As all important changes have already been merged from libarchive git
this is just version number bump, documentation update and some
polishing for cpio tests. Other source code changes are not relevant to
FreeBSD.
Approved by: re (gjb)
MFC after: 1 week
MIPS64 does not store the 'r_info' field of a relocation table entry as
a 64-bit value consisting of a 32-bit symbol index in the high 32 bits
and a 32-bit type in the low 32 bits as on other architectures. Instead,
the 64-bit 'r_info' field is really a 32-bit symbol index followed by four
individual byte type fields. For big-endian MIPS64, treating this as a
64-bit integer happens to be compatible with the layout expected by other
architectures (symbol index in upper 32-bits of resulting "native" 64-bit
integer). However, for little-endian MIPS64 the parsed 64-bit integer
contains the symbol index in the low 32 bits and the 4 individual byte
type fields in the upper 32-bits (but as if the upper 32-bits were
byte-swapped).
To cope, add two helper routines in gelf_getrel.c to translate between the
correct native 'r_info' value and the value obtained after the normal
byte-swap translation. Use these routines in gelf_getrel(), gelf_getrela(),
gelf_update_rel(), and gelf_update_rela(). This fixes 'readelf -r' on
little-endian MIPS64 objects which was previously decoding incorrect
relocations as well as 'objcopy: invalid symbox index' warnings from
objcopy when extracting debug symbols from kernel modules.
Even with this fixed, objcopy was still crashing when trying to extract
debug symbols from little-endian MIPS64 modules. The workaround in
gelf_*rel*() depends on the current ELF object having a valid ELF header
so that the 'e_machine' field can be compared against EM_MIPS. objcopy
was parsing the relocation entries to possibly rewrite the 'r_info' fields
in the update_relocs() function before writing the initial ELF header to
the destination object file. Move the initial write of the ELF header
earlier before copy_contents() so that update_relocs() uses the correct
symbol index values.
Note that this change should really go upstream. The binutils readelf
source has a similar hack for MIPS64EL though I implemented this version
from scratch using the MIPS64 ABI PDF as a reference.
Discussed with: jkoshy
Reviewed by: emaste, imp
Approved by: re (gjb, kib)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D15734
This matches the name and avoids logging of warnings to console with
default syslog.conf, esp. getting rid of:
warning: /etc/hosts.allow, line ..: can't verify hostname: \
getaddrinfo(.., AF_INET) failed
The current kernel ifunc implementation creates a PLT entry for each
ifunc definition. ifunc calls therefore consist of a call to the
PLT entry followed by an indirect jump. The jump target is written
during boot when the kernel linker resolves R_[*]_IRELATIVE relocations.
This implementation is defined by requirements for userland code, where
text relocations are avoided. This requirement is not present for the
kernel, so the implementation has avoidable overhead (namely, an extra
indirect jump per call).
Address this for now by adding a special option to the static linker
to inhibit PLT creation for ifuncs. Instead, relocations to ifunc call
sites are passed through to the output file, so the kernel linker can
enumerate such call sites and apply PC-relative relocations directly
to the text section. Thus the overhead of an ifunc call becomes exactly
the same as that of an ordinary function call. This option is only for
use by the kernel and will not work for regular programs.
The final form of this optimization is up for debate; for now, this
change is simple and static enough to be acceptable as an interim
solution.
Reviewed by: emaste
Discussed with: arichardson, dim
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D16748
ObsoleteFiles.inc:
Remove manual pages for arc4random_addrandom(3) and
arc4random_stir(3).
contrib/ntp/lib/isc/random.c:
contrib/ntp/sntp/libevent/evutil_rand.c:
Eliminate in-tree usage of arc4random_addrandom().
crypto/heimdal/lib/roken/rand.c:
crypto/openssh/config.h:
Eliminate in-tree usage of arc4random_stir().
include/stdlib.h:
Remove arc4random_stir() and arc4random_addrandom() prototypes,
provide temporary shims for transistion period.
lib/libc/gen/Makefile.inc:
Hook arc4random-compat.c to build, add hint for Chacha20 source for
kernel, and remove arc4random_addrandom(3) and arc4random_stir(3)
links.
lib/libc/gen/arc4random.c:
Adopt OpenBSD arc4random.c,v 1.54 with bare minimum changes, use the
sys/crypto/chacha20 implementation of keystream.
lib/libc/gen/Symbol.map:
Remove arc4random_stir and arc4random_addrandom interfaces.
lib/libc/gen/arc4random.h:
Adopt OpenBSD arc4random.h,v 1.4 but provide _ARC4_LOCK of our own.
lib/libc/gen/arc4random.3:
Adopt OpenBSD arc4random.3,v 1.35 but keep FreeBSD r114444 and
r118247.
lib/libc/gen/arc4random-compat.c:
Compatibility shims for arc4random_stir and arc4random_addrandom
functions to preserve ABI. Log once when called but do nothing
otherwise.
lib/libc/gen/getentropy.c:
lib/libc/include/libc_private.h:
Fold __arc4_sysctl into getentropy.c (renamed to arnd_sysctl).
Remove from libc_private.h as a result.
sys/crypto/chacha20/chacha.c:
sys/crypto/chacha20/chacha.h:
Make it possible to use the kernel implementation in libc.
PR: 182610
Reviewed by: cem, markm
Obtained from: OpenBSD
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16760
* correctly prepare a buffer to obtain interface description from a kernel and
truncate long description instead of dropping it altogether and
spamming logs;
* skip calling strlen() for each description and each SNMP request
for MIB-II/ifXTable's ifAlias.
* teach bsnmpd to allocate memory dynamically for interface descriptions
to decrease memory usage for common case and not to break
if long description occurs;
PR: 217763
Reviewed by: harti and others
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D16459
Adjust MaxAtomicInlineWidth for i386/i486 targets.
This is to fix the bug reported in
https://bugs.llvm.org/show_bug.cgi?id=34347#c6. Currently, all
MaxAtomicInlineWidth of x86-32 targets are set to 64. However, i386
doesn't support any cmpxchg related instructions. i486 only supports
cmpxchg. So in this patch MaxAtomicInlineWidth is reset as follows:
For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is
supported. For i486, the MaxAtomicInlineWidth should be 32 because
it supports cmpxchg. For others 32 bits x86 cpu, the
MaxAtomicInlineWidth should be 64 because of cmpxchg8b.
Differential Revision: https://reviews.llvm.org/D42154
This should fix buildworld on i386, because of our system libraries
missing __atomic_load_8, and possibly other 64 bit atomic functions, for
that architecture.
We should really fix that at some point, but since we have been actually
using cmpxchg8b for years now, it does not seem to matter much...
While here pet mandoc and igor.
Reviewed by: bcr, eadler, krion, mat
Approved by: krion (mentor), mat (mentor)
Differential Revision: https://reviews.freebsd.org/D16376
WPA: Ignore unauthenticated encrypted EAPOL-Key data
Ignore unauthenticated encrypted EAPOL-Key data in supplicant
processing. When using WPA2, these are frames that have the Encrypted
flag set, but not the MIC flag.
When using WPA2, EAPOL-Key frames that had the Encrypted flag set but
not the MIC flag, had their data field decrypted without first verifying
the MIC. In case the data field was encrypted using RC4 (i.e., when
negotiating TKIP as the pairwise cipher), this meant that
unauthenticated but decrypted data would then be processed. An adversary
could abuse this as a decryption oracle to recover sensitive information
in the data field of EAPOL-Key messages (e.g., the group key).
(CVE-2018-14526)
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
Obtained from: git://w1.fi/hostap.git
MFC after: 1 day
Security: CVE-2018-14526
Security: VuXML: 6bedc863-9fbe-11e8-945f-206a8a720317
bectl(8) is an administrative interface for working with ZFS boot
environments, intended to provide a superset of the functionality provided
by sysutils/beadm.
libbe(3) is the back-end library that the required functionality has been
pulled out into for later reuse.
These were originally written for GSoC 2017 under the mentorship of
allanjude@.
bectl(8) has proven pretty stable in my testing, with the known bug
documented in the man page.
Relnotes: yes
[x86] Fix a really subtle miscompile due to a somewhat glaring bug in
EFLAGS copy lowering.
If you have a branch of LLVM, you may want to cherrypick this. It is
extremely unlikely to hit this case empirically, but it will likely
manifest as an "impossible" branch being taken somewhere, and will be
... very hard to debug.
Hitting this requires complex conditions living across complex
control flow combined with some interesting memory (non-stack)
initialized with the results of a comparison. Also, because you have
to arrange for an EFLAGS copy to be in *just* the right place, almost
anything you do to the code will hide the bug. I was unable to reduce
anything remotely resembling a "good" test case from the place where
I hit it, and so instead I have constructed synthetic MIR testing
that directly exercises the bug in question (as well as the good
behavior for completeness).
The issue is that we would mistakenly assume any SETcc with a valid
condition and an initial operand that was a register and a virtual
register at that to be a register *defining* SETcc...
It isn't though....
This would in turn cause us to test some other bizarre register,
typically the base pointer of some memory. Now, testing this register
and using that to branch on doesn't make any sense. It even fails the
machine verifier (if you are running it) due to the wrong register
class. But it will make it through LLVM, assemble, and it *looks*
fine... But wow do you get a very unsual and surprising branch taken
in your actual code.
The fix is to actually check what kind of SETcc instruction we're
dealing with. Because there are a bunch of them, I just test the
may-store bit in the instruction. I've also added an assert for
sanity that ensure we are, in fact, *defining* the register operand.
=D
Noticed by: kib
MFC after: 1 week
higher mode, in <https://reviews.llvm.org/rL338419>. Since we do not
yet have this C11 function, comment out the line for now, as a
workaround for a number of failing ports. Discussion with upstream is
ongoing about an acceptable permanent fix.
PR: 230400
Reported by: jbeich
NT_GNU_PROPERTY_TYPE_0 in a .note.gnu.property section "contains a
program property note which describes special handling requirements
for linker and run-time loader." (from the System V Application Binary
Interface - Linux Extensions")
Intel CET uses two processor-specific program properties in
NT_GNU_PROPERTY_TYPE_0: GNU_PROPERTY_X86_FEATURE_1_IBT to indicate that
all executable sections are compatible with Indirect Branch Tracking,
and GNU_PROPERTY_X86_FEATURE_1_SHSTK to indicate that sections are
compatible with shadow stack.
A later change should add decoding of the individual properties.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
filter_create_ext() is documented to take a NULL terminated set of
arguments. 0 is promoted to an int so this would fail on 64-bit
systems if the value was not passed in a register. On all currently
supported 64-bit architectures it is.
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
