kern: disallow user scheduling/debugging/signalling of jailed procs
Currently, jails are generally ignored when determining whether the
current process/thread can take action upon another, except to determine
if the target's jail is somewhere in the source's hierarchy. Notably,
uid 1001 in a jail (including prison0) can take action upon a process
run by uid 1001 inside of a subordinate jail by default.
While this could be considered a feature at times, it is a scenario
that really should be deliberately crafted; there is no guarantee that
uid 1001 in the parent jail is at all related to uid 1001 in a
subordinate.
This changes introduces three new privileges that grant a process
this kind of insight into other jails:
- PRIV_DEBUG_DIFFJAIL
- PRIV_SCHED_DIFFJAIl
- PRIV_SIGNAL_DIFFJAIL
[33 lines not shown]
jail: separate "statically valid allow flags" from "prison0 allow flags"
The current setup means that we can't add an allow flag in sys/jail.h
that's disabled by default without removing it from the pr_flags
assignment in kern_jail.c. That's technically fine, but I think it's
better to make it more prevalent at the PR_ALLOW_* definition site so
that it's top-of-mind when adding a new flag.
This is a preparatory change for adding an allow flag that prison0 will
also have disabled by default, but with an allow.* knob and sysctl to
enable it.
Reviewed by: jamie
(cherry picked from commit 58c92776d1580717934e29ca2c0ef9bf2fbb7397)
powerpc/pmap/oea64: Make PV_LOCK superpage sized
HPT superpages are 16MB, not 2MB. Taking 8 locks to lock a super page
almost defeats the purpose of using the super page. Expanding the
PV_LOCK scope to cover 16MB (24 bit shift) reduces this to a single
lock.
MFC after: 3 weeks
powerpc/pmap: Mark more CPUs as lockless TLBIE
Add POWER10 and POWER11 to the list of lockless TLBIE capable CPUs.
According to Linux, anything POWER5 and later should be able to do this,
but that hasn't been tested with FreeBSD. POWER10 and POWER11, being
derived after the POWER9, implicitly have this capability per the ISA
spec.
MFC after: 1 week
uart: fix sleeping while holding mutex in uart_tty_detach()
Move swi_remove() call before acquiring the tty lock. swi_remove() calls
intr_event_remove_handler() which may sleep via msleep(), causing a lock
order violation when called with the tty mutex held.
The software interrupt handler removal operates on the interrupt event
structure independently and does not require the tty lock. This matches
the pattern used in other drivers such as tcp_hpts.c where swi_remove()
is called without holding other locks.
Reviewed by: imp, kevans
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54953
rc: run the zfs rc script before tmp
The tmp rc script has much the same problem that the var does: it wants
to test if /tmp is writable, and mount a tmpfs if it's not. This means
that we actually want our zfs datasets mounted first, because we might
have a /tmp dataset that changes the story.
The ordering problem is particularly noticable with a r/o zfs root,
since the write test will fail and we'll mount a tmpfs that later gets
covered by our /tmp dataset. If that /tmp dataset inherited readonly,
then we're still in trouble.
This also fixes `tmpmfs=yes`, which would again get covered by a zfs
dataset with the existing ordering.
Reviewed by: des
Differential Revision: https://reviews.freebsd.org/D54995
[lldb] Fix variable access in old SBFrames after inferior function calls (#178823)
When a user holds an SBFrame reference and then triggers an inferior
function
call (via expression evaluation or GetExtendedBacktraceThread),
variables in
that frame become inaccessible with "register fp is not available"
errors.
This happens because inferior function calls execute through
ThreadPlanCallFunction, which calls ClearStackFrames() during cleanup to
invalidate the unwinder state. ExecutionContextRef objects in the old
SBFrames
were tracking StackFrameLists via weak_ptr, which became stale when
ClearStackFrames() created new instances.
The fix uses stable StackFrameList identifiers that persist across
ClearStackFrames():
- ID = 0: Normal unwinder frames (constant across all instances)
[35 lines not shown]
Re-introduce kern.sched.topology_spec
Move it back from kern.sched.ule.topology_spec.
Make it scheduler-agnostic.
Provide trivial report for UP kernels.
Apparently the MIB is used by some third-party software. Obviously it
did not worked on UP or 4BSD configs.
PR: 292574
Reviewed by: olce
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D55062
[AMDGPU] Allow hoising of V_READFIRSTLANE_B32 for uniform operand
readfirstlane can be moved across control flow for uniform inputs.
The MachineInstr::NoConvergent attribute allows hoisting
which is otherwise prohibited for a convergent instruction.
pflog: tests: Fix rdr_action_head()
Fix a typo in the rdr_action_head() test.
Fixes: 685fb4253819 ("pf: Log the intended action when a NAT rule matches a packet")
MFC after: 1 week
(cherry picked from commit 964d91ee1d7a1405383aeb4fce72c4e3bc80af35)
[AMDGPU] Return two MMOs for load-to-lds and store-from-lds intrinsics
Accurately represent both the load and the store part of those
intrinsics.
The test changes seem to be mostly fairly insignificant changes caused by
subtly different scheduler behavior.
commit-id:0269189c
[AMDGPU] Add scheduling DAG mutation for hazard latencies (#170075)
Improve waitcnt merging in ML kernel loops by increasing latencies on
VALU writes to SGPRs.
Specifically this helps with the case of V_CMP output feeding V_CNDMASK
instructions.
acpi: add Darwin OSI quirk for Apple Mac hardware
Mac firmware hides the Intel integrated GPU (iGPU) on dual GPU x86
systems, i.e., with AMD/NVIDIA dGPUs, when the Darwin OSI is not
installed via ACPI.
Prior to this change, FreeBSD always used the dGPU. This is fine in
practice, but consumed more power than when the iGPU is used,
resulting in reduced battery life.
Linux handles this in `drivers/acpi/osi.c` by detecting Apple
hardware via DMI, disabling all Windows OSI strings, and
by explicitly installing the Darwin OSI ACPI handler. This change
applies equivalent logic to the acpi(4) driver on FreeBSD.
This feature can be enabled/disabled using the
`hw.acpi.apple_darwin_osi` tunable. Setting this tunable to `0`
restores the previous behavior by explicitly disabling the added
support.
[3 lines not shown]
[CodeGen] Refactor targets to override the new getTgtMemIntrinsic overload (NFC) (#175844)
This is a fairly mechanical change. Instead of returning true/false,
we either keep the Infos vector empty or push one entry.
[BasicBlockUtils] Fix dominator tree update for entry block in splitBlockBefore() (#178895)
06dfbb50d70eea4ae38d655842626a0b9b224d5c fixed dominator update for
entry block in `SplitBlockPredecessors()`, this patch fixes dominator
tree update for entry block in `splitBlockBefore()` with
`UpdateAnalysisInformation()`.
[compiler-rt][common] Don't unmap stacks not mapped by the runtime
When the sanitizer hasn't mapped the alternate signal stack, but the
host program has (like LLVM), the runtime still tries to unilaterally
unmap the alternate stack. Instead, the runtime should just check if
it's actually mmaped the alternate stack, and only unmap it if it has.
