Add a guard that expects a failure of the test on aarch64.
Reviewed by: emaste
Fixes: df1ea58873 ("tests: Test libexecinfo backtrace call througth signal trampoline")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54675
Reviewed by: markj
Fixes: ea675a43f0 ("libexec/kgdb: Add new modules and install them together with debug info")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54680
PF configuration files can contains many things.
Using the new page characters (i.e. ^L, \014) to mark the beginning
of parts is useful because many editors such as emacs and vim has
facilities to jump next/previous ones.
PR: 86635
MFC after: 2 weeks
Submitted by: MOROHOSHI Akihiko <moro@remus.dti.ne.jp>
Submitted by: Simon Wollwage <rootnode+freebsd@wollwage.com>
Sponsored by: Rubicon Communications, LLC ("Netgate")
When printing source limiters use the same keywords as we accept on
input, that is use 'entries' for the entries value (not 'limit') and
'limit' for the limit value (and not 'states').
Update the test case to match.
Sponsored by: Rubicon Communications, LLC ("Netgate")
This change extends pf(4) limiters so administrator
can specify action the rule executes when limit is
reached. By default when limit is reached the limiter
overrides action specified by rule to no-match.
If administrator wants to block packet instead then
rule with limiter should be changed to:
pass in from any to any state limiter test (block)
OK dlg@
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, 04394254d9
Sponsored by: Rubicon Communications, LLC ("Netgate")
the code that unwinds state creation when something fails needed
the pf_source variable at the function scope to be set, but this
was masked by a declaration in the scope that sets up the source
limiting. this results in a NULL deref in the unwind code when it
needs to clean up the accounting for a source limiter.
i found it funny that i left this comment for myself in the unwinding
code:
/* who needs KASSERTS when we have NULL derefs */
ok jmatthew@
Obtained from: OpenBSD, dlg <dlg@openbsd.org>, fc9311361f
Sponsored by: Rubicon Communications, LLC ("Netgate")
linked with the plural from other text, and
matches "Source Limiters. From Atanas Vladimirov.
Obtained from: OpenBSD, sthen <sthen@openbsd.org>, d4acfc5766
Sponsored by: Rubicon Communications, LLC ("Netgate")
pfctl_parser.c, ifa_load() should distinguish between broadcast
and PPP peer address when it populates interface table for rule
parser.
OK @claudio, OK @dlg
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, 2e871bec67
Sponsored by: Rubicon Communications, LLC ("Netgate")
The current ifa_load() is not paranoid enough when it deals with
information which comes from kernel. The function just ignores
sa_len member in socket address returned getifaddrs().
The issue has been reported by anton@. The idea for fix here comes
fromy claudio@.
OK @claudio, @deraadt
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, a48d060175
Sponsored by: Rubicon Communications, LLC ("Netgate")
Those finishing touches were supposed to land
with source/state limiter changes. I failed to
spot them during code review.
OK dlg@
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, 098c19176b
Sponsored by: Rubicon Communications, LLC ("Netgate")
the range checks are not needed because both members
(statelim and sourcelim) are uint8_t, they implicitly
fit desired range <0, 255>. Unbreaks gcc build.
Pointed out by deraadt@
OK deraadt@
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, 3a7be1e428
Sponsored by: Rubicon Communications, LLC ("Netgate")
Deviate a little from the OpenBSD code, to avoid unexpected output
changes.
Don't print limiter information when we show the rules (or labels).
Do include the source and state limiters in the 'all' (pfctl -sa) output
and give them their own titles.
Sponsored by: Rubicon Communications, LLC ("Netgate")
The 'introduce source and state limiters' commit added source and state
limiters, and used Stlimiters and Srclimiters as show options. However,
FreeBSD had 'Sources' as a show option already. This means that
'pfctl -sS' would now be ambiguous. Avoid this by renaming the new
options.
Sponsored by: Rubicon Communications, LLC ("Netgate")
both source and state limiters can provide constraints on the number
of states that a set of rules can create, and optionally the rate
at which they are created. state limiters have a single limit, but
source limiters apply limits against a source address (or network).
the source address entries are dynamically created and destroyed,
and are also limited.
this started out because i was struggling to understand the source and
state tracking options in pf.conf, and looking at the code made it
worse. it looked like some functionality was missing, and the code also
did some things that surprised me. taking a step back from it, even it
if did work, what is described doesn't work well outside very simple
environments.
the functionality i'm talking about is most of the stuff in the
Stateful Tracking Options section of pf.conf(4).
some of the problems are illustrated one of the simplest options:
the "max number" option that limits the number of states that a
rule is allowed to create:
- wiring limits up to rules is a problem because when you load a
new ruleset the limit is reset, allowing more states to be created
than you intended.
- a single "rule" in pf.conf can expand to multiple rules in the
kernel thanks to things like macro expansion for multiple ports.
"max 1000" on a line in pf.conf could end up being many times
that in effect.
- when a state limit on a rule is reached, the packet is dropped.
this makes it difficult to do other things with the packet, such a
redirect it to a tarpit or another server that replies with an
outage notices or such.
a state limiter solves these problems. the example from the pf.conf.5
change demonstrates this:
An example use case for a state limiter is to restrict the number of
connections allowed to a service that is accessible via multiple
protocols, e.g. a DNS server that can be accessed by both TCP and UDP on
port 53, DNS-over-TLS on TCP port 853, and DNS-over-HTTPS on TCP port 443
can be limited to 1000 concurrent connections:
state limiter "dns-server" id 1 limit 1000
pass in proto { tcp udp } to port domain state limiter "dns-server"
pass in proto tcp to port { 853 443 } state limiter "dns-server"
a single limit across all these protocols can't be implemented with
per rule state limits, and any limits that were applied are reset
if the ruleset is reloaded.
the existing source-track implementation appears to be incomplete,
i could only see code for "source-track global", but not "source-track
rule". source-track global is too heavy and unweildy a hammer, and
source-track rule would suffer the same issues around rule lifetimes
and expansions that the "max number" state tracking config above has.
a slightly expanded example from the pf.conf.5 change for source limiters:
An example use for a source limiter is the mitigation of denial of
service caused by the exhaustion of firewall resources by network or port
scans from outside the network. The states created by any one scanner
from any one source address can be limited to avoid impacting other
sources. Below, up to 10000 IPv4 hosts and IPv6 /64 networks from the
external network are each limited to a maximum of 1000 connections, and
are rate limited to creating 100 states over a 10 second interval:
source limiter "internet" id 1 entries 10000 \
limit 1000 rate 100/10 \
inet6 mask 64
block in on egress
pass in quick on egress source limiter "internet"
pass in on egress proto tcp probability 20% rdr-to $tarpit
the extra bit is if the source limiter doesn't have "space" for the
state, the rule doesn't match and you can fall through to tarpitting
20% of the tcp connections for fun.
i've been using this in anger in production for over 3 years now.
sashan@ has been poking me along (slowly) to get it in a good enough
shape for the tree for a long time. it's been one of those years.
bluhm@ says this doesnt break the regress tests.
ok sashan@
Obtained from: OpenBSD, dlg <dlg@openbsd.org>, 8463cae72e
Sponsored by: Rubicon Communications, LLC ("Netgate")
Add support for the MacBookPro11,5 (Mid 2015, 15-inch with AMD Radeon R9 M370X GPU)
to the Apple SMC driver.
Debug testing revealed this model lacks several SMC keys present on MacBookPro11,4
(IBLC, ICMC, IC2C), that model-specific sensor definitions.
Differential Revision: https://reviews.freebsd.org/D54665
Reviewed by: adrian
The mtw(4) driver works correctly on initial boot, but fails to initialize
the MT7601U WiFi adapter after a warm reboot.
Users must either physically unplug and replug the USB adapter, or perform a
full power cycle to restore functionality, if usb power is always powered
(only a replug works)
The root cause is that warm reboot does not power-cycle USB devices,
leaving the MT7601U in a stale state from the previous session.
The MCU retains its ready flag and the device ignores initialization
commands, resulting in timeout waiting for MCU to initialize errors.
At the OS Level, pinging 1.1.1.1 will work, but the speed will be very
slow. In addition in debug mode, we see thousand of error logs.
This patch addresses the issue by:
* Performing USB re-enumeration on attach to reset the device state
* Detecting when the MCU is already marked ready (stale from previous
session) and forcing a reset of the MCU before loading firmware
* Increasing the firmware load timeout from 3s to 10s to accommodate
slower initialization after reset
* Increasing MCU ready poll attempts from 100 to 300 with longer delays
to handle devices that take longer to become ready after reset
Note: The increase was random, lower value might work.
Test Plan:
Tested on MacBook Pro (late-2015) and a MacMini with MediaTek MT7601U
USB adapter across multiple warm reboot cycles.
With the mac-mini and a another desktop, the issue happens only if
connected via an always powered usb hub port in the monitor.
The laptop don't power cycle it power.
Differential Revision: https://reviews.freebsd.org/D54659
Reviewed by: adrian
VT_SETMODE ioctl currently checks the provided signal numbers with its
own ISSIGVALID macro that uses NSIG (32) as a maximum, although the code
that will actually send the signal in sys/kern/kern_sig.c uses
_SIG_VALID which allows up to _SIG_MAXSIG (128).
This change aligns the vt code with the kernel internals and enables the
use of higher signal numbers so that applications are not limited to
SIGUSR1 and SIGUSR2 for vt release and acquire signals.
Signed-off-by: Quentin Thébault <quentin.thebault@defenso.fr>
Reviewed by: emaste, imp, kevans
Differential Revision: https://reviews.freebsd.org/D53615
Implement STYPE_SUSPEND_TO_IDLE sleep type added in c43473dc9b
("sys/power: Generic sleep types").
This is a prerequisite for the firmware to enter the S0ix states. When
suspending to idle, the system stays in an ACPI S0 state, but the CPUs
are idled and devices are suspended/resumed before and after this as
they would be when entering any other sleep type (except for AWAKE and
POWEROFF).
Factor out do_standby, do_sleep, and add a new do_idle function for
idling the CPU (a future patch will make this an idle loop and not just
a simple cpu_idle() call). In do_idle, SCIs (interrupt 9) are enabled to
allow wake events to break the CPU out of idle.
Record all the steps made instead of just the last one in slp_state,
which allows for more flexible unwinding (will be useful to not have to
goto breakout if the SPMC entry call fails when that is committed).
A lot of this borrows from Ben Widawsky's patch: D17675. The main
functional difference with that patch is that suspend-to-idle is a
wholly separate sleep type in this one as opposed to being an
alternative implementation for s2mem (S3).
Reviewed by: emaste, olce
Approved by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48734
Function to enable specific IRQ source.
This will be used by the s2idle code to enable just SCIs on x86 to break
the CPU out of idle.
Reviewed by: olce
Approved by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48734
Creation of enc0 before SI_SUB_PROTO_MC mangles the MLD list as well as
encounters IGMP mutex not initialized yet.
Reported & tested by: mjg
NB: the enc(4) is not a true interface indeed. In a perfect world the
module shall not create a cloner, shall not enter if_attach(), shall not
trigger ifnet_arrival_event, neither shall have any protocol attached to
it. The enc0 exists for two purposes: 1) create a bpf(9) tap; 2) to allow
injection packets in the middle of ipsec(4) processing temporarily
rewriting m_pkthdr.rcvif to point at enc0. While the problem 1 is already
solved with a recent divorce between bpf(9) and ifnet(9), the problem 2 is
harder to solve without breaking packet filter rules that use "via enc0".
This is supposed to be a dtrace_id_t, which is a uint32_t, while id_t is
a uint64_t. sdt.h avoids depending on dtrace.h so we can't use
dtrace_id_t directly.
Bump __FreeBSD_version since the layout of structures in the SDT probe
linker set has changed.
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Detect presence of FEAT_MOPS, and enable instruction set and set HWCAP2 flag
if present.
Add handler for MOE exceptions.
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D54558
Jose Luis Duran