| Age | Commit message (Collapse) | Author |
|---|
|
this will be required by future chromium releases
From ee0f8c4010309a25c95115a9f727a02741e2de48 Mon Sep 17 00:00:00 2001
From: Nikolas Klauser <nikolasklauser@berlin.de>
Date: Sat, 12 Mar 2022 01:45:35 +0100
Subject: [PATCH] [libc++][ranges] Implement ranges::find{, _if, _if_not}
ok tb@
|
|
|
|
ok kettenis@
|
|
default on OpenBSD this will give us IBT support by default. Fixes
indirect function calls for functions in shared libraries.
This doesn't fix retpoline+znow PLTs yet; a fix for that will follow.
ok miod@, guenther@
|
|
ok hackroom
tested by plenty
|
|
clflushopt, clwb, ptwrite, rdpid, serialize, WAITPKG, and vmfunc
extensions, as well as part of TSX. tpause and umonitor addr size
handling isn't 100% correct, but good enough to get the instruction
boundary.
Correct decoding of rex64 {fxsave,fxrstor,xsave,xrstor,xsaveopt}
to instead use a '64' suffix, ala "fxsave64".
"good enough" ok kettenis@ deraadt@ mlarkin@
|
|
ok jsg@
|
|
ok hackroom
tested by plenty
|
|
we effectively enable -mbranch-protection=standard on arm64 now.
ok deraadt@
|
|
OK deraadt@
|
|
table variations (calculate address into %rax, jmp %rax) which is not
compatible with IBT endbr64. The specific generated code sequence was
found inside clang, which made the debugging experience pretty miserable.
So we will have to disable jump tables by default.
ok kettenis
|
|
-fcf-protection=branch is the default). All binaries grow slightly, but
we can slowly move towards greater IBT enforcement in userland.
4th or 5th variation of this diff, with mortimer
ok kettenis
|
|
upstream. Fixes several issues including problems with ld.bfd when it
sees such a .plt in an object file that is getting linked into a binary.
ok deraadt@
|
|
ok hackroom
tested by plenty
|
|
the -z nobtcfi option.
ok deraadt@
|
|
ok deraadt@
|
|
ok deraadt@, mortimer@
this is backport of the following upstream commit:
commit 5fbe21a7748f91adbd1b16c95bbfe180642320a3
Author: Nathan Sidwell <nathan@acm.org>
Date: Wed Jun 16 10:43:43 2021 -0700
[clang] p2085 out-of-class comparison operator defaulting
This implements p2085, allowing out-of-class defaulting of comparison
operators, primarily so they need not be inline, IIUC intent. this was
mostly straigh forward, but required reimplementing
Sema::CheckExplicitlyDefaultedComparison, as now there's a case where
we have no a priori clue as to what class a defaulted comparison may
be for. We have to inspect the parameter types to find out. Eg:
class X { ... };
bool operator==(X, X) = default;
Thus reimplemented the parameter type checking, and added 'is this a
friend' functionality for the above case.
|
|
ok hackroom
tested by plenty
|
|
|
|
(the mips64 default is still ld.bfd)
|
|
ok miod
|
|
This is upstream PR 28103 https://github.com/Perl/perl5/pull/20813
Requested by stsp@ for quality of life improvments for Game of Trees users.
|
|
It's from a test file and should never have been installed.
Noticed by xse in #openbsd on libera.chat
|
|
OK bluhm@
a good time naddy@
|
|
OK bluhm@
a good time naddy@
|
|
OK bluhm@
a good time naddy@
|
|
OK bluhm@
a good time naddy@
|
|
looking good sthen@, Great! bluhm@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
before .text.
ok deraadt@
|
|
ok deraadt@
|
|
Note this doesn't actually work yet for anything big -- some unknown
stuff needs to be fixed. Also ld.lld isn't the default sparc64 ld yet.
But at least having this available during normal builds, to test iterate
upon, will speed up either of those desireable outcomes.
ok claudio
|
|
ok gkoehler
|
|
instructions always fetch a 32-bit word when operand is a memory address.
This works unless the address is within the last 3 bytes of a page, with
the next page being invalid, something which can happen with small malloc'ed
structures (I'm looking at you, perl).
Work around the problem by requiring a register operand in all cases; the
register load will be a zero-extension load of the right width.
This is my entry into the "fix a 30-year old bug" contest of 2023.
|
|
Adjust how gcc3 handles the "missing braces around initializer" warning.
In c99 any value can be initalised using a { 0 } constructor independent
of the type. Now if a struct's first member is another struct then gcc4
issues the above warning but it should not do that.
Move the warning check from push_init_level() to pop_init_level() and
check if either { 0 } or { } was used. If additional implicit braces
were added surpress the warning.
Inspired by gcc PR#64709
light testing by me, serious testing by aoyama@
|
|
ok deraadt
|
|
but it isn't the default yet
|
|
I wonder if we should allow --exec-only option on all architectures
(but not as default), because this pre-check list now covers all
architectures, and we haven't seen a ld.lld problem. We only switch
an architecture to --exec-only default when other aspects (mostly
compiler or .S files), that is a seperate switch block.
Even though i386 has no mmu means to enforce xonly, uvm will fail a
memcpy read of region which hasn't been previously faulted (by
executing code in the region). This definately blocks reads of
"contigious entire libc text", because very few programs "execute code
in all libc code pages", even with uvm_fault's behaviour of wide
faulting a 32K region. The random relinking also means an attacker
cannot know what subset of libc text can be read because pre-faulted
chunks are unknown, but now they can't copy it all (if they could find
the location and bounds). This neat behaviour applies to all
architectures. It seems we should try to always hint text segment
permission as PROT_EXEC-only to the kernel and be happy that blocks a
read, even if that blocking isn't 100% reliable.
note: unfortunately binutils --exec-only isn't bug-free yet on most
architectures, taking the same approach there will take longer.
|
|
alphabetical order while I'm there.
ok deraadt@
|
|
ok naddy@, sthen@
|
|
to compose the offset to the PLT instead of having a constant pool in .text.
Make --execute-only work on powerpc64.
ok miod@
|
|
ok hackroom
tested by plenty
|
