FreeBSD's mkstemp sets the temporary file's permissions to 600, and has ever
since mkstemp was added in 1987. Coverity's warning is still relevant for
portable programs since OpenGroup does not require that behavior, and POSIX
didn't until 2008. But none of these programs are portable.
umask(2) should always be used prior to mkstemp(3) so the temporary file
won't be created with insecure permissions.
Reported by: Coverity
CID: 1331605 1347173 1375366 1339800 1331604 1296056 1296060
CID: 1296057 1296062
MFC after: 2 weeks
A follow-up to r337812 to catch a couple more memory leaks that should
have been included in that change.
Reported by: Coverity
CID: 1296064, 1296067 (for real this time)
MFC after: 3 days
X-MFC-with: r337812
Sponsored by: Dell EMC
The libkqueue tests have several places that leak memory by using an
idiom like:
puts(kevent_to_str(kevp));
Rework to save the pointer returned from kevent_to_str() and then
free() it after it has been used.
Reported by: asomers (pointer to Coverity), Coverity
CID: 1296063, 1296064, 1296065, 1296066, 1296067, 1350287, 1394960
Sponsored by: Dell EMC
- Add some more cases to the truncation test.
- Remove the "expect fail" annotations.
PR: 131876
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D16562
With r337328, the test hangs becase the sendmsg() call will block until
the receive buffer is at least partially drained. Fix the problem by
using a non-blocking socket and allowing short writes. Also assert
that a SCM_CREDS message was received if one was expected.
PR: 181741
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D16516
Enable the LOCAL_PEERCRED socket option for unix domain stream sockets
created with socketpair(2). Previously, it only worked with unix domain
stream sockets created with socket(2)/listen(2)/connect(2)/accept(2).
PR: 176419
Reported by: Nicholas Wilson <nicholas@nicholaswilson.me.uk>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D16350
- Remove return statements in functions with a void return type.
- Allocate enough space for the SCM_CREDS and SCM_RIGHTS messages
received in the rights_creds_payload test.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
If an error occurs while copying a SCM_RIGHTS message to userspace,
we free the mbuf containing externalized rights, leaking them.
PR: 131876
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
ian@ pointed out that in the test_abstime() function time(NULL) is
used twice; once in an "if" test and again in the enclosed error
message. If the true branch was taken and the process got preempted
before the second time(NULL) call, by the time the error message was
generated enough time could have elapsed that the message could claim
that the event came "too early" but print an event time that was after
the expected timeout. Correct by making the time(NULL) call only once
and using that returned time in both the "if" test and the error
message.
Reported by: ian@
MFC after: 4 days
X-MFC-with: r336761, r336781, r336802
Sponsored by: Dell EMC
Another cast for printing an intmax_t was needed in a kqueue test for
some arches.
Pointy-hat: me (twice)
MFC after: 1 week
X-MFC-with: r336761, r336781
Sponsored by: Dell EMC
If a timer is updated (re-added) with a different time period
(specified in the .data field of the kevent), the new time period has
no effect; the timer will not expire until the original time has
elapsed. This violates the documented behavior as the kqueue(2) man
page says (in part) "Re-adding an existing event will modify the
parameters of the original event, and not result in a duplicate
entry."
This modification, adapted from a patch submitted by cem@ to PR214987,
fixes the kqueue system to allow updating a timer entry. The
kevent timer behavior is changed to:
* When a timer is re-added, update the timer parameters to and
re-start the timer using the new parameters.
* Allow updating both active and already expired timers.
* When the timer has already expired, dequeue any undelivered events
and clear the count of expirations.
All of these changes address the original PR and also bring the
FreeBSD and macOS kevent timer behaviors into agreement.
A few other changes were made along the way:
* Update the kqueue(2) man page to reflect the new timer behavior.
* Fix man page style issues in kqueue(2) diagnosed by igor.
* Update the timer libkqueue system test to test for the updated
timer behavior.
* Fix the (test) libkqueue common.h file so that it includes
config.h which defines various HAVE_* feature defines, before the
#if tests for such variables in common.h. This enables the use of
the actual err(3) family of functions.
* Fix the usages of the err(3) functions in the tests for incorrect
type of variables. Those were formerly undiagnosed due to the
disablement of the err(3) functions (see previous bullet point).
PR: 214987
Reported by: Brian Wellington <bwelling@xbill.org>
Reviewed by: kib
MFC after: 1 week
Relnotes: yes
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15778
These syscalls were always supposed to have been auditted, but due to
oversights never were.
PR: 228374
Reported by: aniketp
Reviewed by: aniketp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D16388
In r321967 ngie "fixed" these tests by changing their expectations to match
the device numbers produced by the new ino64 code. But it wasn't the tests
that were broken, it was the kernel. bde fixed the kernel in r335053.
Reported by: Jenkins
MFC after: Never (only applies to >= 12)
These three syscalls aren't currently audited correctly, so the tests are
marked as expected failures.
PR: 228374
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D16379
auditon(2) is an ioctl-like syscall with several different variants, each of
which has a distinct audit event. This commit tests the remaining variants
that weren't tested in r336564.
Submitted by: aniketp
MFC after: 2 weeks
X-MFC-With: 336564
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D16381
auditon(2) is an ioctl-like syscall with several different variants, each of
which has a distinct audit event. Write separate audit(4) tests for each
variant.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D16255
Also, fix a bug in common code that could cause other tests to fail: using
ppoll(2) in combination with buffered I/O for /dev/auditpipe. Fix it by
disabling buffering.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D16099
Includes ntp_adjtime, auditctl, acct, auditon, and clock_settime. Includes
quotactl, mount, nmount, swapon, and swapoff in failure mode only. Success
tests for those syscalls will follow. Also includes reboot(2) in failure
mode only. That one can't be tested in success mode.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15898
Tested syscalls include rfork(2), chdir(2), fchdir(2), chroot(2),
getresuid(2), getresgid(2), setpriority(2), setgroups(2), setpgrp(2),
setrlimit(2), setlogin(2), mlock(2), munlock(2), minherit(2), rtprio(2),
profil(2), ktrace(2), ptrace(2), fork(2), umask(2), setuid(2), setgid(2),
seteuid(2), and setegid(2). The last six are only tested in the success
case, either because they're infalliable or a failure is difficult to cause
on-demand.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15966
Includes utimes(2), futimes(2), lutimes(2), futimesat(2), mprotect(2), and
undelete(2). undelete, for now, is tested only in failure mode.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15893
This was correct in the final version on Phabricator, but somehow I screwed
up applying the patch locally.
Reported by: linimon
Pointy-hat-to: asomers
MFC after: 2 weeks
X-MFC-With: 335307
The ad audit class is for administrative commands. This commit adds test
for settimeofday, adjtime, and getfh.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15861
This commit includes extattr_{get_file, get_fd, get_link, list_file,
list_fd, list_link}. It does not include any syscalls that modify, set, or
delete extended attributes, as those are in a different audit class.
Submitted by: aniketpt
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15859
This revision adds auditability tests for stat, lstat, fstat, and fstatat,
all from the fa audit class. More tests from that audit class will follow.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15709
These syscalls are atypical, because each one corresponds to several
different audit events, and they each pass several different audit class
filters.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15657
The only syscalls in this class are close, closefrom, munmap, and revoke.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15650
The only syscalls in this class are rmdir, unlink, unlinkat, rename, and
renameat. Also, set is_exclusive for all audit(4) tests, because they can
start and stop auditd.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15647
truncate and ftruncate are the only syscalls in this class, apart from
certain variations of open and openat, which will be handled in a different
file.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15640
readlink and readlinkat are the only syscalls in this class. open and
openat are as well, but they'll be handled in a different file. Also, tidy
up the copyright headers of recently added files in this area.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15636
This change includes the framework for testing the auditability of various
syscalls, and includes changes for the first 12. The tests will start
auditd(8) if needed, though they'll be much faster if it's already running.
The syscalls tested in this commit include mkdir(2), mkdirat(2), mknod(2),
mknodat(2), mkfifo(2), mkfifoat(2), link(2), linkat(2), symlink(2),
symlinkat(2), rename(2), and renameat(2).
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15286
Previously it was possible to connect a socket (which had the
CAP_CONNECT right) by calling "connectat(AT_FDCWD, ...)" even in
capabilties mode. This combination should be treated the same as a call
to connect (i.e. forbidden in capabilities mode). Similarly for bindat.
Disable connectat/bindat with AT_FDCWD in capabilities mode, fix up the
documentation and add tests.
PR: 222632
Submitted by: Jan Kokemüller <jan.kokemueller@gmail.com>
Reviewed by: Domagoj Stolfa
MFC after: 1 week
Relnotes: Yes
Differential Revision: https://reviews.freebsd.org/D15221
A pipe was was left over from a development version of pdeathsig.c and
is not needed.
Process C waits for a signal that'll be generated when process B
exists. Process B waits for process D to send it a byte via pipe_db
before it exits. Process D sends the byte after it has started
ptrace()ing process C. The point of the test is to show that process C
receives the signal because process B exited, even though C has been
reparented to process D. The pipe pipe_cd isn't doing anything useful
(though in an earlier version of the patch it did). Clean that up by
removing the useless pipe.
Submitted by: Thomas Munro
MFC after: 6 days
Differential revision: https://reviews.freebsd.org/D15214
- ptrace__breakpoint_siginfo tests that a SIGTRAP for a software breakpoint
in userland triggers a SIGTRAP with a signal code of TRAP_BRKPT.
- ptrace__step_siginfo tests that a SIGTRAP reported for a step after
stepping via PT_STEP or PT_SETSTEP has a signal code of TRAP_TRACE.
- Use a single list of platforms to define HAVE_BREAKPOINT for platforms
that expose a functional breakpoint() inline to userland. Replace
existing lists of platform tests with HAVE_BREAKPOINT instead.
- Add support for advancing PC past a breakpoint inserted via breakpoint()
to support the existing ptrace__PT_CONTINUE_different_thread test on
non-x86 platforms (x86 advances the PC past the breakpoint instruction,
but other platforms do not). This is implemented by defining a new
SKIP_BREAK macro which accepts a pointer to a 'struct reg' as its sole
argument and modifies the contents to advance the PC. The intention is
to use it in between PT_GETREGS and PT_SETREGS.
Tested on: amd64, i386, mips (after adding a breakpoint() to mips)
MFC after: 1 month
-> PROC_PDEATHSIG_STATUS for consistency with other procctl(2)
operations names.
Requested by: emaste
Sponsored by: The FreeBSD Foundation
MFC after: 13 days
Allow processes to request the delivery of a signal upon death of
their parent process. Supposed consumer of the feature is PostgreSQL.
Submitted by: Thomas Munro
Reviewed by: jilles, mjg
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D15106
fget_cap() tries to do a cheaper snapshot of a file descriptor without
holding the file descriptor lock. This snapshot does not do a deep
copy of the ioctls capability array, but instead uses a different
return value to inform the caller to retry the copy with the lock
held. However, filecaps_copy() was returning 1 to indicate that a
retry was required, and fget_cap() was checking for 0 (actually
'!filecaps_copy()'). As a result, fget_cap() did not do a deep copy
of the ioctls array and just reused the original pointer. This cause
multiple file descriptor entries to think they owned the same pointer
and eventually resulted in duplicate frees.
The only code path that I'm aware of that triggers this is to create a
listen socket that has a restricted list of ioctls and then call
accept() which calls fget_cap() with a valid filecaps structure from
getsock_cap().
To fix, change the return value of filecaps_copy() to return true if
it succeeds in copying the caps and false if it fails because the lock
is required. I find this more intuitive than fixing the caller in
this case. While here, change the return type from 'int' to 'bool'.
Finally, make filecaps_copy() more robust in the failure case by not
copying any of the source filecaps structure over. This avoids the
possibility of leaking a pointer into a structure if a similar future
caller doesn't properly handle the return value from filecaps_copy()
at the expense of one more branch.
I also added a test case that panics before this change and now passes.
Reviewed by: kib
Discussed with: mjg (not a fan of the extra branch)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D15047
This behavior is already documented by the man page, and suggested by POSIX.
Reviewed by: jhb
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D15099
Do not build or install pf tests if WITHOUT_PF is set. This fixes the build
failure with WITHOUT_PF=yes.
Reported by: Vladimir Zakharov <zakharov.vv@gmail.com>
There was a memory leak in the DIOCRADDTABLES ioctl() code which could
be triggered by trying to add tables with the same name.
Try to provoke this memory leak. It was fixed in r331225.
MFC after: 1 week
Validate the DIOCRGETTABLES, DIOCRGETTSTATS, DIOCRCLRTSTATS and
DIOCRSETTFLAGS ioctls with invalid values. These may succeed (because
the kernel uses the minimally required size, not the specified size),
but should not trigger kernel panics.
MFC after: 1 week
The upstream repository is on github BLAKE2/libb2. Files landed in
sys/contrib/libb2 are the unmodified upstream files, except for one
difference: secure_zero_memory's contents have been replaced with
explicit_bzero() only because the previous implementation broke powerpc
link. Preferential use of explicit_bzero() is in progress upstream, so
it is anticipated we will be able to drop this diff in the future.
sys/crypto/blake2 contains the source files needed to port libb2 to our
build system, a wrapped (limited) variant of the algorithm to match the API
of our auth_transform softcrypto abstraction, incorporation into the Open
Crypto Framework (OCF) cryptosoft(4) driver, as well as an x86 SSE/AVX
accelerated OCF driver, blake2(4).
Optimized variants of blake2 are compiled for a number of x86 machines
(anything from SSE2 to AVX + XOP). On those machines, FPU context will need
to be explicitly saved before using blake2(4)-provided algorithms directly.
Use via cryptodev / OCF saves FPU state automatically, and use via the
auth_transform softcrypto abstraction does not use FPU.
The intent of the OCF driver is mostly to enable testing in userspace via
/dev/crypto. ATF tests are added with published KAT test vectors to
validate correctness.
Reviewed by: jhb, markj
Obtained from: github BLAKE2/libb2
Differential Revision: https://reviews.freebsd.org/D14662
It mistakenly believes the 'static' keyword must come first. Fix PPC,
Sparc64, and maybe MIPS world. Fallout from r331279.
Reported by: tinderbox (results come slowly)
The general idea here is to provide userspace programs with well-defined
sources of entropy, in a fashion that doesn't require opening a new file
descriptor (ulimits) or accessing paths (/dev/urandom may be restricted
by chroot or capsicum).
getrandom(2) is the more general API, and comes from the Linux world.
Since our urandom and random devices are identical, the GRND_RANDOM flag
is ignored.
getentropy(3) is added as a compatibility shim for the OpenBSD API.
truss(1) support is included.
Tests for both system calls are provided. Coverage is believed to be at
least as comprehensive as LTP getrandom(2) test coverage. Additionally,
instructions for running the LTP tests directly against FreeBSD are provided
in the "Test Plan" section of the Differential revision linked below. (They
pass, of course.)
PR: 194204
Reported by: David CARLIER <david.carlier AT hardenedbsd.org>
Discussed with: cperciva, delphij, jhb, markj
Relnotes: maybe
Differential Revision: https://reviews.freebsd.org/D14500
The 'physio' fast-path used by AIO requests on md(4) devices, is not
gated on the unsafe_aio knob. Prior to r327755, some AIO requests could
fail the fast-path and fall back to the slow-path (requests for devices
not supporting unmapped I/O and requests which failed with EFAULT during
the fast-path). However, those cases now return a suitable error rather
than using the slow-path.
PR: 217261
Reviewed by: asomers
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D14742
The code assumed that disks (devices) used for testing are always named
like /dev/foo, but there is no reason for that restriction and we can
easily support paths like /dev/stripe/bar.
The change is to account for a different order in which the recursive
destroy may be attempted. If we first try a dataset that can be destroyed
then it will be destroyed, but if we first try a dataset that cannot be
destroyed then we will not attempt to destroy the other dataset.
It was originally written by Sun as part of the STF (Solaris test framework).
They open sourced it in OpenSolaris, then HighCloud partially ported it to
FreeBSD, and Spectra Logic finished the port. We also added many testcases,
fixed many broken ones, and converted them all to the ATF framework. We've had
help along the way from avg, araujo, smh, and brd.
By default most of the tests are disabled. Set the disks Kyua variable to
enable them.
Submitted by: asomers, will, justing, ken, brd, avg, araujo, smh
Sponsored by: Spectra Logic Corp, HighCloud
If the underlying provider's physical path is null, then the gpart device's
physical path will be, too. Otherwise, it will append the partition name,
such as "/p1" or "/s1/a". This will make gpart work better with zfsd(8).
PR: 224965
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D14010
If the underlying provider's physical path is null, then the geli device's
physical path will be, too. Otherwise, it will append "/eli". This will make
geli work better with zfsd(8).
PR: 224962
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D13979
Don't declare some types that FreeBSD incorrectly declares.
Fix an incorrect call to open() (missing mode).
ANSIfy prototypes.
Enable SysV message queue, semaphore, and shared memory tests.
With exception of the workaround for union semun, these fixes have been
committed to NetBSD.
Reviewed by: asomers
Approved by: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D13471
* Registers TRNG source for random(4)
* Finds available queues, LSBs; allocates static objects
* Allocates a shared MSI-X for all queues. The hardware does not have
separate interrupts per queue. Working interrupt mode driver.
* Computes SHA hashes, HMAC. Passes cryptotest.py, cryptocheck tests.
* Does AES-CBC, CTR mode, and XTS. cryptotest.py and cryptocheck pass.
* Support for "authenc" (AES + HMAC). (SHA1 seems to result in
"unaligned" cleartext inputs from cryptocheck -- which the engine
cannot handle. SHA2 seems to work fine.)
* GCM passes for block-multiple AAD, input lengths
Largely based on ccr(4), part of cxgbe(4).
Rough performance averages on AMD Ryzen 1950X (4kB buffer):
aesni: SHA1: ~8300 Mb/s SHA256: ~8000 Mb/s
ccp: ~630 Mb/s SHA256: ~660 Mb/s SHA512: ~700 Mb/s
cryptosoft: ~1800 Mb/s SHA256: ~1800 Mb/s SHA512: ~2700 Mb/s
As you can see, performance is poor in comparison to aesni(4) and even
cryptosoft (due to high setup cost). At a larger buffer size (128kB),
throughput is a little better (but still worse than aesni(4)):
aesni: SHA1:~10400 Mb/s SHA256: ~9950 Mb/s
ccp: ~2200 Mb/s SHA256: ~2600 Mb/s SHA512: ~3800 Mb/s
cryptosoft: ~1750 Mb/s SHA256: ~1800 Mb/s SHA512: ~2700 Mb/s
AES performance has a similar story:
aesni: 4kB: ~11250 Mb/s 128kB: ~11250 Mb/s
ccp: ~350 Mb/s 128kB: ~4600 Mb/s
cryptosoft: ~1750 Mb/s 128kB: ~1700 Mb/s
This driver is EXPERIMENTAL. You should verify cryptographic results on
typical and corner case inputs from your application against a known- good
implementation.
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12723
Scapy requires the Raw payload to be a string, which was not the case. This
caused the pft_ping.py script to fail, which in turn caused the test to fail.
Reduce the geli tests' runtime by about a third:
* In integrity_test:copy, use a file-backed md(4) device instead of a
malloc'd one. That way we can corrupt the underlying storage without
needing to detach and reattach the geli device.
* In integrity_test:{copy, hmac, data} and onetime_test:{onetime,
onetime_a}, move reads of /dev/random out of the loop.
MFC after: 2 weeks
The trick is not to destroy an md(4) device during a test. That can create
a "double-free" situation, because we also destroy md devices during test
cleanup.
MFC after: 2 weeks
I'm leaving readonly_test and nokey_test alone for now. In a future commit
they should be broken up into several smaller test cases and distributed
between multiple files.
Reviewed by: ngie
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13717
The resize test used bsdlabel(8), which is not available on all
architectures. Change it to use gpart(8) instead, which should be available
everywhere.
PR: 221763
Reported by: andrew
MFC after: 2 weeks
This change mostly reverts r293436, which introduced the bug due to a belief
that geli(8) would allocate md(4) devices by itself. However, that belief is
incorrect. Instead of using linear probing to find available md(4) numbers,
it's best to use the existing attach_md function.
Reviewed by: ngie
MFC after: 2 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13666
Some of the ptrace tests need to wait for a child process to become a
zombie before preceding. The parent process polls the child process
via the kern.proc.pid sysctl to wait for it to become a zombie.
Previously the code polled until the sysctl failed with ESRCH. Now it
will poll until either the sysctl fails with ESRCH (for compatiblity
with older kernels) or returns a kinfo_proc structure with the ki_stat
field set to SZOMB.
Reported by: Jenkins
Tested by: markj
Discussed with: mjg
MFC after: 1 week
We can't kldunload in the test head as Kyua interprets any output from
them. This would lead to syntax errors and skipping the entire file.
Move the kld commands into the test case bodies.
Pointed out by: asomers@
Some IPSec in tunnel mode allowing to test multiple IPSec
configurations. These tests are reusing the jail/vnet scripts from pf
tests for generating complex network.
Submitted by: olivier@
Differential Revision: https://reviews.freebsd.org/D13017
Previously, symlinks in FreeBSD were artificially limited to PATH_MAX-2.
Add a short test case to verify the change.
Submitted by: Gaurav Gangalwar <ggangalwar AT isilon.com>
Reviewed by: kib
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12589
tests/sys/aio/aio_kqueue_test.c
Instead of using a hard-coded queue depth, use
vfs.aio.max_aio_queue_per_proc
tests/sys/aio/lio_kqueue_test.c
The old, small limit on lio_listio's operation count was lifted by
change 324941. Raise the operation count as high as possible without
exceeding the process's operation limit.
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
When multiple threads wish to report a tracing event to a debugger,
both threads call ptracestop() and one thread will win the race to be
the reporting thread (p->p_xthread). The debugger uses PT_LWPINFO
with the process ID to determine which thread / LWP is reporting an
event and the details of that event. This event is cleared as a side
effect of the subsequent ptrace event that resumed the process
(PT_CONTINUE, PT_STEP, etc.). However, ptrace() was clearing the
event identified by the LWP ID passed to the resume request even if
that wasn't the 'p_xthread'. This could result in clearing an event
that had not yet been observed by the debugger and leaving the
existing event for 'p_thread' pending so that it was reported a second
time.
Specifically, if the debugger stopped due to a software breakpoint in
one thread, but then switched to another thread that was used to
resume (e.g. if the user switched to a different thread and issued a
step), the resume request (PT_STEP) cleared a pending event (if any)
for the thread being stepped. However, the process immediately
stopped and the first thread reported it's breakpoint event a second
time. The debugger decremented the PC for "both" breakpoint events
which resulted in the PC now pointing into the middle of an
instruction (on x86) and a SIGILL fault when the process was resumed a
second time.
To fix, always clear the pending event for 'p_xthread' when resuming a
process. ptrace() still honors the requested LWP ID when enabling
single-stepping (PT_STEP) or setting a different PC (PT_CONTINUE).
Reported by: GDB testsuite (gdb.threads/continue-pending-status.exp)
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D12794
Test fragmentation handling (i.e. scrub fragment reassemble) code for
IPv6.
Two simple tests: Ping a host (jail) and test forwarding of fragmented
packets.
When cleaning up we must destroy the jails before we destroy the interfaces.
Otherwise we might try to destroy interfaces that belong to a jail, which won't
work and fail to completely clean up.
Pass/block packets in the forwarding path with pf.
Introduce the pft_set_rules() helper function, because we need to
remember to flush states between individual tests. If not we can get
packets passing despite rules blocking them because they match states
created in a previous test.
Extend pft_ping.py to be able to send IPv6 echo requests.
