| Age | Commit message (Collapse) | Author |
|---|
|
ok patrick@
|
|
|
|
to fix a regression in floating point operations. Bluhm noticed that
the bc regression test has been failing after the upgrade to 7.0.1
because setting the floating point control register was in some cases
reordered erroneously.
Found and tested by bluhm@
ok bluhm@ kettenis@
|
|
ok hackroom@
|
|
FreeBSD/powerpc. From George Koehler.
ok millert@, deraadt@, visa@
|
|
"where is the kaboom?" deraadt@
|
|
ok dlg@
|
|
are on command-line.
and use a bool type for a boolean in C++.
ok kettenis@ deraadt@
|
|
this is a bit different to gcc as gcc likes to use movs to move
stuff on and off the stack, and directly updates the stack pointers
with add and sub instructions. llvm prefers to use push and pop
instructions, is a lot more careful about keeping track of how
much stuff is currently on the stack, and generally pops the frame
pointer rather than do maths on it.
-msave-args adds a bunch of pushes as the first thing a function
prologue does. to keep the stack aligned, if there's an odd number
of arguments to the function it pushes the first one again to put
the frame back on a 16 byte boundary.
to undo the pushes the frame pointer needs to be updated in function
epilogues. clang emits a series of pops to fix up the registers on
the way out, but popping saved arguments is a waste of time and
harmful to actual data in the function. rather than add an offset
to the stack pointer, -msave-args emits a leaveq operation to fix
up the frame again. leaveq is effectively mov rbp,rsp; pop rbp, and
is a single byte, meaning there's less potential for gadgets compared
to a direct add to rsp, or an explicit mov rbp,rsp.
the only thing missing compared to the gcc implementation is adding
the SUN_amd64_parmdump dwarf flag to affected functions. if someone
can tell me how to add that from the frame lowering code, let me
know.
when enabled in kernel builds again, this will provide useful
arguments in ddb stack traces again.
|
|
"where is the kaboom?" deraadt@
|
|
|
|
ok hackroom@
|
|
Note that this will still produce binaries that have the read-only segment
placed before the executable segment. This means that on machines without
the NX bit, the read-only segment is now executable. However on machines
with an NX bit, the ordering used by lld means the program headers are no
longer executable since they are now part of the read-only segment.
ok deraadt@, naddy@
|
|
|
|
|
|
|
|
With fixes from mortimer@ (thanks!)
Tested by many, especially naddy@ (thanks!)
|
|
|
|
|
|
development effort on OpenBSD/arm64.
|
|
|
|
ok hackroom@
|
|
Without this, values get truncated to 32-bit. Makes a sparc64 kernel
actually work when compiled with clang.
ok pguenther@, visa@
|
|
ok hackroom@
|
|
explicitly in SMALL_KERNEL kernel builds.
tweaks from jsg@ and tb@
ok deraadt@ kettenis@
|
|
ok hackroom@
|
|
there are various %llb formats. Adjust the code to handle the length specifiers
and type check like it is used by the regular case.
OK guenther@
|
|
ok hackroom@
|
|
is referenced from code being linked.
ok deraadt@, naddy@, guenther@
|
|
|
|
From upstream r335090. ok guenther@
|
|
GNU linkers by convention supports both `--foo bar` and `--foo=bar` styles
for all long options that take arguments.
From upstream r326506. ok patrick@ kettenis@
|
|
the section to be at least as large as the entry size of the section.
This causes a later check that validates the alignment to fail if the
entry size isn't a power of two. This happens when building some of the
java support code in ports gcc. Fix this by sticking to the original
alignment if the entry size isn't a power of two.
ok guenther@, naddy@
|
|
Upstream references:
https://reviews.llvm.org/D31557
https://reviews.llvm.org/D48515
OK kettenis@
|
|
|
|
ok hackroom@
|
|
makes no sense. Yes it breaks function address equality and therefore
the expectations of the standard C language. However declaring symbols
with protected visibility isn't standard C in the first place.
Fixes linking non-PIC/PIE code with lld on amd64.
ok millert@
|
|
|
|
tested by naddy@
|
|
ok deraadt@
|
|
|
|
ok hackroom@
|
|
fallthrough. Avoids unnecessary jmp instructions in the middle
of functions and makes disassembly nicer to read.
ok guenther@ mlarkin@ deraadt@
|
|
'.openbsd.randomdata.retguard', to make them easier to work with in the
kernel hibernate code.
ok mortimer@ deraadt@
|
|
section when linking, as we do when using ld from binutils.
ok mortimer@ deraadt@
|
|
profiler(gprof) work properly.
ok mpi
|
|
Spotted by Nan Xiao.
|
|
random cookies to protect access to function return instructions, with the
effect that the integrity of the return address is protected, and function
return instructions are harder to use in ROP gadgets.
On function entry the return address is combined with a per-function random
cookie and stored in the stack frame. The integrity of this value is verified
before function return, and if this check fails, the program aborts. In this way
RETGUARD is an improved stack protector, since the cookies are per-function. The
verification routine is constructed such that the binary space immediately
before each ret instruction is padded with int03 instructions, which makes these
return instructions difficult to use in ROP gadgets. In the kernel, this has the
effect of removing approximately 50% of total ROP gadgets, and 15% of unique
ROP gadgets compared to the 6.3 release kernel. Function epilogues are
essentially gadget free, leaving only the polymorphic gadgets that result from
jumping into the instruction stream partway through other instructions. Work to
remove these gadgets will continue through other mechanisms.
Remaining work includes adding this mechanism to assembly routines, which must
be done by hand. Many thanks to all those who helped test and provide feedback,
especially deaadt, tb, espie and naddy.
ok deraadt@
|
|
|
|
ok hackroom@
|
