3ce04aca markj Jan. 17, 2022, 9:12 p.m.
This provides information about fixed regions of the target process'
user memory map.

Reviewed by:	kib
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33708
cgit
1811c1e9 markj Jan. 17, 2022, 9:12 p.m.
The approach taken by the stack gap implementation was to insert a
random gap between the top of the fixed stack mapping and the true top
of the main process stack.  This approach was chosen so as to avoid
randomizing the previously fixed address of certain process metadata
stored at the top of the stack, but had some shortcomings.  In
particular, mlockall(2) calls would wire the gap, bloating the process'
memory usage, and RLIMIT_STACK included the size of the gap so small
(< several MB) limits could not be used.

There is little value in storing each process' ps_strings at a fixed
location, as only very old programs hard-code this address; consumers
were converted decades ago to use a sysctl-based interface for this
purpose.  Thus, this change re-implements stack address randomization by
simply breaking the convention of storing ps_strings at a fixed
location, and randomizing the location of the entire stack mapping.
This implementation is simpler and avoids the problems mentioned above,
while being unlikely to break compatibility anywhere the default ASLR
settings are used.

The kern.elfN.aslr.stack_gap sysctl is renamed to kern.elfN.aslr.stack,
and is re-enabled by default.

PR:		260303
Reviewed by:	kib
Discussed with:	emaste, mw
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33704
cgit
758d98de markj Jan. 17, 2022, 9:11 p.m.
ASLR stack randomization will reappear in a forthcoming commit.  Rather
than inserting a random gap into the stack mapping, the entire stack
mapping itself will be randomized in the same way that other mappings
are when ASLR is enabled.

No functional change intended, as the stack gap implementation is
currently disabled by default.

Reviewed by:	kib
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33704
cgit
706f4a81 markj Jan. 17, 2022, 9:11 p.m.
Rather than fetching the ps_strings address directly from a process'
sysentvec, use this macro.  With stack address randomization the
ps_strings address is no longer fixed.

Reviewed by:	kib
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33704
cgit
5a8413e7 markj Jan. 17, 2022, 4:42 p.m.
This will not be required with a forthcoming reimplementation of ASLR
stack randomization.  Moreover, this change was not sufficient to enable
the use of a stack size limit smaller than the stack gap itself.

PR:		260303
Reviewed by:	kib
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33704
cgit
3fc21fdd markj Jan. 17, 2022, 4:42 p.m.
The size of the ps_strings structure varies between ABIs, so this is
useful for computing the address of the ps_strings structure relative to
the top of the stack when stack address randomization is enabled.

Reviewed by:	kib
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33704
cgit
1544f5ad markj Jan. 17, 2022, 4:41 p.m.
The current ASLR stack gap feature will be removed, and with that the
need for the kern.stacktop sysctl is gone.  All consumers have been
removed.

This reverts commit a97d697122da2bfb0baae5f0939d118d119dae33.

Reviewed by:	kib
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33704
cgit
f75b1ff6 markj Jan. 17, 2022, 4:41 p.m.
The current ASLR stack gap feature will be removed, and with that the
need for this change, and the kern.stactop sysctl, is gone.  Moreover,
the approach taken in this revision does not provide compatibility for
old copies of libthr.so, and the revision should have also updated
__libc_map_stacks_exec().

This reverts commit 78df56ccfcb40013a3e6904bd6d39836220c3550.

Reviewed by:	kib
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33704
cgit
dc752617 markj Jan. 17, 2022, 1:35 p.m.
PR:		240573
Reviewed by:	kib
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33912
cgit
ad15eeea royger Jan. 17, 2022, 10:06 a.m.
It has been reported that on some AWS instances VCPUOP_send_nmi
returns -38 (ENOSYS). The hypercall is only available for HVM guests
in Xen 4.7 and newer. Add a fallback to use the native NMI sending
procedure when VCPUOP_send_nmi is not available, so that the NMI is
not lost.

Reported and Tested by: avg
MFC after: 1 week
Fixes: b2802351c162 ('xen: fix dispatching of NMIs')
Sponsored by: Citrix Systems R&D
cgit
779fd053 melifaro Jan. 17, 2022, 9:35 a.m.
PR:	261136
Reported by:	Daniel O'Connor
MFC after:	2 weeks
cgit
b1f7154c melifaro Jan. 17, 2022, 9:35 a.m.
Reviewed by:	cem, avg
MFC after:	2 weeks
Differential Revision: https://reviews.freebsd.org/D33794
cgit
1f70a85b melifaro Jan. 17, 2022, 9:35 a.m.
Reviewed by:	kib
MFC after:	2 weeks
Differential Revision: https://reviews.freebsd.org/D33792
cgit
96c524d8 melifaro Jan. 17, 2022, 9:35 a.m.
Reviewed by:	kib
MFC after:	2 weeks
Differential Revision: https://reviews.freebsd.org/D33790
cgit
b896bdb8 trasz Jan. 17, 2022, 8:45 a.m.
From a user point of view, this makes ^T work out of the box.

Reviewed By:	debdrup (man page)
Sponsored By:	EPSRC
Differential Revision:	https://reviews.freebsd.org/D33842
cgit