When filtering Ethernet packets allow rules to specify a mac address
with a mask. This indicates which bits of the specified address are
significant. This allows users to do things like filter based on device
manufacturer.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Allow packets to be tagged with dummynet information. Note that we do
not apply dummynet shaping on the L2 traffic, but instead mark it for
dummynet processing in the L3 code. This is the same approach as we take
for ALTQ.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32222
If we're not filtering on a specific MAC address don't print it at all,
rather than showing an all-zero address.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31749
Extent pfctl to be able to read configured Ethernet filtering rules from
the kernel and print them.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31738
The LibUSB v1.0 emulation layer uses pipes internally to signal between
threads. When USB devices are reset, as part of loading firmware, SIGPIPE
may happen, and that is expected and should be ignored.
PR: 261891
MFC after: 1 week
Sponsored by: NVIDIA Networking
Helper routine to call the kernel to get a path to the named device.
Different path enumeration methods (called locators) can be used
for different path types depending on what the kernel implements.
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D32746
The gunion(8) utility is used to track changes to a read-only disk on
a writable disk. Logically, a writable disk is placed over a read-only
disk. Write requests are intercepted and stored on the writable
disk. Read requests are first checked to see if they have been
written on the top (writable disk) and if found are returned. If
they have not been written on the top disk, then they are read from
the lower disk.
The gunion(8) utility can be especially useful if you have a large
disk with a corrupted filesystem that you are unsure of how to
repair. You can use gunion(8) to place another disk over the corrupted
disk and then attempt to repair the filesystem. If the repair fails,
you can revert all the changes in the upper disk and be back to the
unchanged state of the lower disk thus allowing you to try another
approach to repairing it. If the repair is successful you can commit
all the writes recorded on the top disk to the lower disk.
Another use of the gunion(8) utility is to try out upgrades to your
system. Place the upper disk over the disk holding your filesystem
that is to be upgraded and then run the upgrade on it. If it works,
commit it; if it fails, revert the upgrade.
Further details can be found in the gunion(8) manual page.
Reviewed by: Chuck Silvers, kib (earlier version)
tested by: Peter Holm
Differential Revision: https://reviews.freebsd.org/D32697
During distributeworld we call distribute on subdirectories, which in
turn calls installconfig. However, this recursive installconfig call
appends the distribution name (in these cases, "base") to DESTDIR. For
install(1) this works fine as its -D argument comes from the top-level
Makefile.inc1, which passes the original DESTDIR, thereby resulting in
the METALOG entry having the distribution name as a prefix representing
its true installed path relative to the root, but for the hand-rolled
entries they do not use install(1) and thus do not have access to what
the original DESTDIR was, resulting in the METALOG missing this prefix.
Thus, pass down the name of the distribution via a new variable DISTBASE
(chosen as Makefile.inc1 already uses that to convey this exact same
information to etc's distrib-dirs during distributeworld) and prepend
this to the handful of manually-generated METALOG entries. For the
installworld case this variable will be empty and so this behaves as
before.
Note that we need to be careful to avoid double slashes in the METALOG;
distributeworld uses find | awk to split the single METALOG up into
multiple dist.meta files, and this relies on the paths in the METALOG
having the exact prefix ./dist (or ./dist/usr/lib/debug).
Reviewed by: brooks, emaste
Differential Revision: https://reviews.freebsd.org/D33997
Apply uncrustify changes to .c/.h files.
Reduce the diffs with EDK2 to aid with future merges. The
unconventional way we've imported this code makes using a vendor branch
to manage it at the very least tricky. Update FreeBSD-update to reflect
the slight shift in advise.
Reviewed by: imp
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Obtained from: 2f88bd3a12
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
Text format for AcpiEx device path in UEFI Spec:
AcpiEx(HID,CID,UID,HIDSTR,CIDSTR,UIDSTR)
AcpiEx(HID|HIDSTR,(CID|CIDSTR,UID|UIDSTR))(Display Only)
When convert device path to text for AcpiEx device path,
current code check AllowShortcuts parameter to convert
the device path to DisplayOnly text format(shorter text
representation) by mistake.
It should check DisplayOnly parameter.
This commit is to fix this issue.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1312
Obtained from: e9ab1635a2
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
AcpiExp text device path: AcpiExp(HID,CID,UIDSTR)
And according to UEFI spec, the CID parameter is optional
and has a default value of 0. But current implementation
miss to check following cases for the AcpiExp.
FromText: when text device is AcpiExp(HID,,UIDSTR)/AcpiExp(HID,0,UIDSTR)
ToText: when the CID is 0 in the node structure
This commit is to do the enhancement.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1243
Obtained from: a8b5750901
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
According to UEFI spec,
for the Messaging Device Path with USB Class SubType, some paras
are optional in the text device path.
Take UsbClass(VID,PID,Class,SubClass,Protocol) for example,
The VID is an integer between 0 and 65535 and is optional. The
default value is 0xFFFF.
The PID is an integer between 0 and 65535 and is optional. The
default value is 0xFFFF.
The Class is an integer between 0 and 255 and is optional. The
default value is 0xFF.
The SubClass is an integer between 0 and 255 and is optional. The
default value is 0xFF.
The Protocol is an integer between 0 and 255 and is optional. The
default value is 0xFF.
So if any the optional para is not specified in the text device,
we should set related para in the node structure to default value.
This commit is to do the enhancement for USB Class device path
when optional para is not specified.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1243
Obtained from: 3874108034
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
When converting DebugPort device path from text,
current code use VENDOR_DEFINED_MESSAGING_DEVICE_PATH structure
for Debug port device node.
typedef struct {
EFI_DEVICE_PATH_PROTOCOL Header;
EFI_GUID Guid;
UINT8 VendorDefinedData[1];
} VENDOR_DEFINED_MESSAGING_DEVICE_PATH;
And Debugport Device Path is a vendor-defined messaging
device path with no data, only a GUID. So it's better to
use VENDOR_DEVICE_PATH to create the Debug port device node.
typedef struct {
EFI_DEVICE_PATH_PROTOCOL Header;
EFI_GUID Guid;
} VENDOR_DEVICE_PATH;
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1229
Obtained from: 9343d0a1cd
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
According to UEFI spec,for ACPI Expanded Device Path
when HID=PNP0A03 or CID=PNP0A03 and HID != PNP0A08,
the device path node can be displayed as: PciRoot(UID|UIDSTR)
When HID=PNP0A08 or CID=PNP0A08, the device path node can be
displayed as: PcieRoot(UID|UIDSTR). But current code miss the
code logic.
This commit is to do the enhancement.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1228
Obtained from: 78af0984b4
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
According to UEFI Spec, for ACPI Expanded Device Path,
when HIDSTR=empty, CIDSTR=empty, UID STR!=empty,
the ACPI Expanded Device Path node can be displayed as
AcpiExp(HID,CID,UIDSTR) format.
And if UID is 0 and UIDSTR is empty, then use AcpiEx format.
This patch is to correct the condition check to follow UEFI
Spec when convert the device path node to the AcpiExp text
format.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1226
Obtained from: fb4bea551e
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
1. Do not use tab characters
2. No trailing white space in one line
3. All files must end with CRLF
Adapted according to FreeBSD-update instructions, with the sole purpose
of reducing the differences with upstream sources.
Obtained from: 9095d37b8f
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
Per UEFI spec, iSCSI.Lun is a 8-byte array with byte #0 in the left.
It means "0102030405060708" should be converted to:
UINT8[8] = {01, 02, 03, 04, 05, 06, 07, 08}
or UINT64 = {0807060504030201}
Today's implementation wrongly uses the reversed order.
Obtained from: d0196be1e3
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
For the following two functions:
DevPathFromTextBluetooth()
DevPathToTextBluetooth()
The Bluetooth device address "UINT8 Address[6]" is displayed with the
order from Address[5] to Address[0]. This commit reverses the order.
Obtained from: 4fc8277133
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
For current iSCSI protocol parsing, UINT16 truncation may be happened. Since
the Spec already have declaimed that 0 is TCP Protocol and 1+ is reserved, the
parsing can be refined as below:
if (StrCmp (ProtocolStr, L"TCP") == 0) {
ISCSIDevPath->NetworkProtocol = 0;
} else {
//
// Undefined and reserved.
//
ISCSIDevPath->NetworkProtocol = 1;
}
Obtained from: 7571a1c191
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
UefiDevicePathLibConvertTextToDevicePath correctly detects when it
has hit a ',' splicing together multiple paths. However, the code
that tries to cope with it:
{code}
if (IsInstanceEnd) {
DeviceNode = (EFI_DEVICE_PATH_PROTOCOL *) AllocatePool (
END_DEVICE_PATH_LENGTH);
ASSERT (DeviceNode != NULL);
SetDevicePathEndNode (DeviceNode);
NewDevicePath = AppendDevicePathNode (DevicePath, DeviceNode);
FreePool (DevicePath);
FreePool (DeviceNode);
DevicePath = NewDevicePath;
}
{code}
causes a problem. The END node that's appended it the node for the
entire list. So when the node is appended in AppendDevicePathNode,
it winds up disappearing. This leads to the path
'PciRoot(0x0),PciRoot(0x0)' parsing as if 'PciRoot(0x0)/PciRoot(0x0)'
were specified. These are two very different things.
NOTE:
This fix was already committed. It has been included with the sole
intention of reducing diffs with upstream.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=419
Obtained from: 647636e175
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
Network interface type should be checked before the conversion between
text device path node and MAC device path. Otherwise, the MAC text string
can't be converted to the representation of a device node, which leads to
the series failure of network HII configuration(e.g. IP, VLAN, HTTP Boot
configuration in Network Device List).
Obtained from: 2d67f2bae3
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
Add per-Session configurable ping (SCSI NOP) and login timeouts.
Remove the torn down, old iSCSI session quickly, when performing a reconnect.
Reviewed By: trasz
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D34198
Require the newly opened file descriptor to be good, instead of
re-requiring the one that was required three lines earlier.
Thankfully, opening /dev/null is really unlikely to fail.
Reported by: Coverity
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Summary:
Use initial-exec, like other architectures.
While here, switch MACHINE_ARCH in lib/libc/Makefile to LIBC_ARCH and consistently use powerpc.
Subscribers: imp, #contributor_reviews_base
Differential Revision: https://reviews.freebsd.org/D34315
Reviewed by: luporl
MFC after: 2 weeks
This is useful for processors where we don't have an event table; in
those cases we default to a Cortex A8 (armv7) or Cortex A53 (arm64) in
order to attempt to provide something useful, but you're then limited to
the counters in those tables, some of which may also not be implemented
(e.g. LD/ST_RETIRED are no longer implemented in more recent cores,
replaced by LD/ST_SPEC).
Adding the raw EVENT_xxH event lists to each table ensures that you can
always request the exact events you want, regardless of what has been
detected or is known.
Reviewed by: mhorne
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D33805
When a thread exits, _Unwind_ForcedUnwind() is used to walk up stack
frames executing pending cleanups pushed by pthread_cleanup_push().
The cleanups are popped by thread_unwind_stop() which is passed as a
callback function to _Unwind_ForcedUnwind().
LLVM's libunwind uses a different function type for the callback on
32-bit ARM relative to all other platforms. The previous unwind.h
header (as well as the unwind.h from libcxxrt) use the non-ARM type on
all platforms, so this has likely been broken on 32-bit arm since it
switched to using LLVM's libunwind.
For now, just disable stack unwinding on 32-bit arm to unbreak the
build until a proper fix is tested.
Install headers from LLVM's libunwind in place of the headers from
libcxxrt and allow C applications to use the library.
As part of this, remove include/unwind.h and switch libthr over to
using the installed unwind.h.
Reviewed by: dim, emaste
MFC after: 10 days
Differential Revision: https://reviews.freebsd.org/D34065
Libarchive 3.6.0
New features:
PR #1614: tar: new option "--no-read-sparse"
PR #1503: RAR reader: filter support
PR #1585: RAR5 reader: self-extracting archive support
New features (not used in FreeBSD base):
PR #1567: tar: threads support for zstd (#1567)
PR #1518: ZIP reader: zstd decompression support
Security Fixes:
PR #1491, #1492, #1493, CVE-2021-36976:
fix invalid memory access and out of bounds read in RAR5 reader
PR #1566, #1618, CVE-2021-31566:
extended fix for following symlinks when processing the fixup list
Other notable bugfixes and improvements:
PR #1620: tar: respect "--ignore-zeros" in c, r and u modes
PR #1625: reduced size of application binaries
MFC after: 2 weeks
Relnotes: yes
The optimization of sysctlbyname() in commit d05b53e0ba had the
side-effect of not going through the fix-up for the user.* variables
in the previously called sysctl() function.
This lead to 0 or an empty strings being returned by sysctlbyname()
for all user.* variables.
An alternate implementation would store the user variables in the
kernel during system start-up. That would allow to remove the fix-up
code in the C library that is currently required to provide the actual
values.
This update restores the previous code path for the user.* variables
and keeps the performance optimization intact for all other variables.
Approved by: mjg
Reviewed by: kaktus
Differential Revision: https://reviews.freebsd.org/D34171
Parts of zstd, used in openzfs and other places, trigger a new clang 14
-Werror warning:
```
sys/contrib/zstd/lib/decompress/huf_decompress.c:889:25: error: use of bitwise '&' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
(BIT_reloadDStreamFast(&bitD1) == BIT_DStream_unfinished)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
While the warning is benign, it should ideally be fixed upstream and
then vendor-imported, but for now silence it selectively.
MFC after: 3 days
- Add a starting index to 'struct vmstats' and change the
VM_STATS ioctl to fetch the 64 stats starting at that index.
A compat shim for <= 13 continues to fetch only the first 64
stats.
- Extend vm_get_stats() in libvmmapi to use a loop and a static
thread local buffer which grows to hold the stats needed.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D27463
Testing had revealed that trying to retrieve the user.localbase
variable into to small a buffer would return the correct error code,
but would not fill the available buffer space with a partial result.
A partial result is of no use, but this is still a violation of the
documented behavior, which has been fixed in the previous commit to
this function.
I just checked the code for "user.cs_path" and found that it had the
same issue.
Instead of fixing the logic for each user.* sysctl string variable
individually, this commit adds a helper function set_user_str() that
implements the semantics specified in the sysctl() man page.
It is currently only used for "user.cs_path" and "user.localbase",
but it will offer a significant simplification when further such
variables will be added (as I intend to do).
MFC after: 3 days
Testing of a new feature revealed that calling sysctl() to retrieve
the value of the user.localbase variable passing too low a buffer size
could leave the result buffer unchanged.
The behavior in the normal case of a sufficiently large buffer was
correct.
All known callers pass a sufficiently large buffer and have thus not
been affected by this issue. If a non-default value had been assigned
to this variable, the result was as documented, too.
Fix the function to fill the buffer with a partial result, if the
passed in buffer size is too low to hold the full result.
MFC after: 3 days
