ian [Sat, 12 Dec 2020 18:34:15 +0000 (18:34 +0000)]
Provide userland notification of gpio pin changes ("userland gpio interrupts").
This is an import of the Google Summer of Code 2018 project completed by
Christian Kramer (and, sadly, ignored by us for two years now). The goals
stated for that project were:
FreeBSD already has support for interrupts implemented in the GPIO
controller drivers of several SoCs, but there are no interfaces to take
advantage of them out of user space yet. The goal of this work is to
implement such an interface by providing descriptors which integrate
with the common I/O system calls and multiplexing mechanisms.
The initial imported code supports the following functionality:
- A kernel driver that provides an interface to the user space; the
existing gpioc(4) driver was enhanced with this functionality.
- Implement support for the most common I/O system calls / multiplexing
mechanisms:
- read() Places the pin number on which the interrupt occurred in the
buffer. Blocking and non-blocking behaviour supported.
- poll()/select()
- kqueue()
- signal driven I/O. Posting SIGIO when the O_ASYNC was set.
- Many-to-many relationship between pins and file descriptors.
- A file descriptor can monitor several GPIO pins.
- A GPIO pin can be monitored by multiple file descriptors.
- Integration with gpioctl and libgpio.
I added some fixes (mostly to locking) and feature enhancements on top of
the original gsoc code. The feature ehancements allow the user to choose
between detailed and summary event reporting. Detailed reporting provides
a record describing each pin change event. Summary reporting provides the
time of the first and last change of each pin, and a count of how many times
it changed state since the last read(2) call. Another enhancement allows
the recording of multiple state change events on multiple pins between each
call to read(2) (the original code would track only a single event at a time).
The phabricator review for these changes timed out without approval, but I
cite it below anyway, because the review contains a series of diffs that
show how I evolved the code from its original state in Christian's github
repo for the gsoc project to what is being commited here. (In effect,
the phab review extends the VC history back to the original code.)
Submitted by: Christian Kramer
Obtained from: https://github.com/ckraemer/freebsd/tree/gsoc2018
Differential Revision: https://reviews.freebsd.org/D27398
se [Sat, 12 Dec 2020 11:23:52 +0000 (11:23 +0000)]
Change getlocalbase() to not allocate any heap memory
After the commit of the current version, Scott Long pointed out, that an
attacker might be able to cause a use-after-free access if this function
returned the value of the sysctl variable "user.localbase" by freeing
the allocated memory without the cached address being cleared in the
library function.
To resolve this issue, I have proposed the originally suggested version
with a statically allocated buffer in a review (D27370). There was no
feedback on this review and after waiting for more than 2 weeks, the
potential security issue is fixed by this commit. (There was no security
risk in practice, since none of the programs converted to use this
function attempted to free the buffer. The address could only have
pointed into the heap if user.localbase was set to a non-default value,
into r/o data or the environment, else.)
This version uses a static buffer of size LOCALBASE_CTL_LEN, which
defaults to MAXPATHLEN. This does not increase the memory footprint
of the library at this time, since its data segment grows from less
than 7 KB to less than 8 KB, i.e. it will get two 4 KB pages on typical
architectures, anyway.
Compiling with LOCALBASE_CTL_LEN defined as 0 will remove the code
that accesses the sysctl variable, values between 1 and MAXPATHLEN-1
will limit the maximum size of the prefix. When built with such a
value and if too large a value has been configured in user.localbase,
the value defined as ILLEGAL_PREFIX will be returned to cause any
file operations on that result to fail. (Default value is "/dev/null/",
the review contained "/\177", but I assume that "/dev/null" exists and
can not be accessed as a directory. Any other string that can be assumed
not be a valid path prefix could be used.)
I do suggest to use LOCALBASE_CTL_LEN to size the in-kernel buffer for
the user.localbase variable, too. Doing this would guarantee that the
result always fit into the buffer in this library function (unless run
on a kernel built with a different buffer size.)
The function always returns a valid string, and only in case it is built
with a small static buffer and run on a system with too large a value in
user.localbase, the ILLEGAL_PREFIX will be returned, effectively causing
the created path to be non-existent.
kevans [Sat, 12 Dec 2020 05:57:42 +0000 (05:57 +0000)]
lualoader: provide module-manipulation commands
Specifically, we have:
- enable-module
- disable-module
- toggle-module
These can be used to add/remove modules to be loaded or force modules to be
loaded in spite of modules_blacklist. In the typical case, a user is
expected to use them to recover an issue happening due to a module directive
they've added to their loader.conf or because they discover that they've
under-specified what to load.
brooks [Fri, 11 Dec 2020 21:51:50 +0000 (21:51 +0000)]
ndis(4): expand deprecation to the whole driver
nids(4) was a clever idea in the early 2000's when the market was
flooded with 10/100 NICs with Windows-only drivers, but that hasn't been
the case for ages and the driver has had no meaningful maintenance in
ages. It only supports Windows-XP era drivers.
brooks [Fri, 11 Dec 2020 21:40:38 +0000 (21:40 +0000)]
hme(4): Remove as previous announced
The hme (Happy Meal Ethernet) driver was the onboard NIC in most
supported sparc64 platforms. A few PCI NICs do exist, but we have seen
no evidence of use on non-sparc systems.
mhorne [Fri, 11 Dec 2020 20:01:45 +0000 (20:01 +0000)]
riscv: small counter(9) improvements
Prefer atomics to critical section. This reduces the cost of the
increment operation and removes the possibility of it being interrupted
by counter_u64_zero().
Use CPU_FOREACH() macro to skip absent CPUs.
Replace hand-rolled address calculation with zpcpu_get().
brooks [Fri, 11 Dec 2020 01:00:07 +0000 (01:00 +0000)]
style(9): Correct whitespace in struct definitions
struct ifconf and struct ifreq use the odd style "struct<tab>foo".
struct ifdrv seems to have tried to follow this but was committed with
spaces in place of most tabs resulting in "struct<space><space>ifdrv".
ngie [Fri, 11 Dec 2020 00:26:49 +0000 (00:26 +0000)]
cap_enter(2): fix CAVEATS section
The CAVEATS section was misspelled as "CAVEAT" before this change. Fix the
spelling to identify issues related to the section.
Furthermore, given that the section order was incorrect, move the CAVEATS
section down to the bottom of the manpage, per the conventional section
order.
ngie [Fri, 11 Dec 2020 00:20:04 +0000 (00:20 +0000)]
posix_spawn(3): fix section that references `vfork`
`vfork(2)` should be referenced in paragraphs as `.Fn vfork`, not `vfork()`.
This change switches the reference to use `.Fn`, which in turn makes the
manpage `make manlint` clean.
bdrewery [Thu, 10 Dec 2020 20:44:29 +0000 (20:44 +0000)]
contig allocs: Don't retry forever on M_WAITOK.
This restores behavior from before domain iterators were added in
r327895 and r327896.
The vm_domainset_iter_policy() will do a vm_wait_doms() and then
restart its iterator when M_WAITOK is set. It will also force
the containing loop to have M_NOWAIT. So we get an unbounded
retry loop rather than the intended bounded retries that
kmem_alloc_contig_pages() already handles.
This also restores M_WAITOK to the vmem_alloc() call in
kmem_alloc_attr_domain() and kmem_alloc_contig_domain().
tuexen [Thu, 10 Dec 2020 19:36:33 +0000 (19:36 +0000)]
Fix the TFTP client when performing a RRQ for files smaller than 512 bytes
and the server not sending an OACK:
* Close the file.
* Report the correct the number of received blocks.
mjg [Thu, 10 Dec 2020 17:17:22 +0000 (17:17 +0000)]
fd: make serialization in fdescfree_fds conditional on hold count
p_fd nullification in fdescfree serializes against new threads transitioning
the count 1 -> 2, meaning that fdescfree_fds observing the count of 1 can
safely assume there is nobody else using the table. Losing the race and
observing > 1 is harmless.
bhughes [Thu, 10 Dec 2020 13:11:52 +0000 (13:11 +0000)]
hyperv/vmbus: avoid crash, panic if vbe fb info is missing
Do not assume that VBE framebuffer metadata can be used. Like with the
EFI fb metadata, it may be null, so we should take care not to
dereference the null vbefb pointer. This avoids a panic when booting
-CURRENT on a gen1 VM in Azure.
Approved by: tsoome
Sponsored by: Miles AS
Differential Revision: https://reviews.freebsd.org/D27533
se [Thu, 10 Dec 2020 09:31:05 +0000 (09:31 +0000)]
Lift scope of buf[] to make it extend to a potential access via *basename
It can be assumed that the contents of the buffer was still allocated and
valid at the point of the out-of-scope access, so there was no security
issue in practice.
Reported by: Coverity Scan CID 1437697
MFC after: 3 days
tmunro [Thu, 10 Dec 2020 07:13:15 +0000 (07:13 +0000)]
truss: Add AIO syscalls.
Display the arguments of aio_read(2), aio_write(2), aio_suspend(2),
aio_error(2), aio_return(2), aio_cancel(2), aio_fsync(2), aio_mlock(2),
aio_waitcomplete(2) and lio_listio(2) in human-readable form.
hselasky [Wed, 9 Dec 2020 20:13:12 +0000 (20:13 +0000)]
Fix bug in ifconfig preventing proper VLAN creation.
Detection of interface type by filter must happen before detection of
interface type by prefix. Else the following sequence of commands will
try to create a LAGG interface instead of a VLAN interface, which
accidentially worked previously, because the date pointed to by the
ifr_data pointer was not parsed by VLAN create ioctl(2). This is a
regression after r368229, because the VLAN creation now parses the
ifr_data field.
How to reproduce:
# ifconfig lagg0 create
# ifconfig lagg0.256 create
rlibby [Wed, 9 Dec 2020 18:43:58 +0000 (18:43 +0000)]
dmar: reserve memory windows of PCIe root port
PCI memory address space is shared between memory-mapped devices (MMIO)
and host memory (which may be remapped by an IOMMU). Device accesses to
an address within a memory aperture in a PCIe root port will be treated
as peer-to-peer and not forwarded to an IOMMU. To avoid this, reserve
the address space of the root port's memory apertures in the address
space used by the IOMMU for remapping.
Reviewed by: kib, tychon
Discussed with: Anton Rang <rang@acm.org>
Tested by: tychon
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D27503
kevans [Wed, 9 Dec 2020 15:28:56 +0000 (15:28 +0000)]
netgraph: macfilter: small fixes
Two issues:
- The DEBUG macro defined is in direct conflict with the DEBUG kernel
option, which broke the -LINT build[0]
- Building with NG_MACFILTER_DEBUG did not compile on LP64 systems due to
using %d for sizeof().
markj [Wed, 9 Dec 2020 14:05:08 +0000 (14:05 +0000)]
Plug a race between fd table teardown and several loops
To export information from fd tables we have several loops which do
this:
FILDESC_SLOCK(fdp);
for (i = 0; fdp->fd_refcount > 0 && i <= lastfile; i++)
<export info for fd i>;
FILDESC_SUNLOCK(fdp);
Before r367777, fdescfree() acquired the fd table exclusive lock between
decrementing fdp->fd_refcount and freeing table entries. This
serialized with the loop above, so the file at descriptor i would remain
valid until the lock is dropped. Now there is no serialization, so the
loops may race with teardown of file descriptor tables.
Acquire the exclusive fdtable lock after releasing the final table
reference to provide a barrier synchronizing with these loops.
Reported by: pho
Reviewed by: kib (previous version), mjg
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27513
jhibbits [Wed, 9 Dec 2020 02:07:01 +0000 (02:07 +0000)]
dev/mfi: Make a seemingly bogus conditional unconditional
Summary:
r358689 attempted to fix a clang warning/error by inferring the intent
of the condition "(cdb[0] != 0x28 || cdb[0] != 0x2A)". Unfortunately, it looks
like this broke things. Instead, fix this by making this path unconditional,
effectively reverting to the previous state.
bdrewery [Tue, 8 Dec 2020 23:38:26 +0000 (23:38 +0000)]
fts_read: Handle error from a NULL return better.
This is addressing cases such as fts_read(3) encountering an [EIO]
from fchdir(2) when FTS_NOCHDIR is not set. That would otherwise be
seen as a successful traversal in some of these cases while silently
discarding expected work.
As noted in r264201, fts_read() does not set errno to 0 on a successful
EOF so it needs to be set before calling it. Otherwise we might see
a random error from one of the iterations.
gzip is ignoring most errors and could be improved separately.
kevans [Tue, 8 Dec 2020 18:47:22 +0000 (18:47 +0000)]
cpuset_set{affinity,domain}: do not allow empty masks
cpuset_modify() would not currently catch this, because it only checks that
the new mask is a subset of the root set and circumvents the EDEADLK check
in cpuset_testupdate().
This change both directly validates the mask coming in since we can
trivially detect an empty mask, and it updates cpuset_testupdate to catch
stuff like this going forward by always ensuring we don't end up with an
empty mask.
The check_mask argument has been renamed because the 'check' verbiage does
not imply to me that it's actually doing a different operation. We're either
augmenting the existing mask, or we are replacing it entirely.
kevans [Tue, 8 Dec 2020 18:45:47 +0000 (18:45 +0000)]
kern: cpuset: resolve race between cpuset_lookup/cpuset_rel
The race plays out like so between threads A and B:
1. A ref's cpuset 10
2. B does a lookup of cpuset 10, grabs the cpuset lock and searches
cpuset_ids
3. A rel's cpuset 10 and observes the last ref, waits on the cpuset lock
while B is still searching and not yet ref'd
4. B ref's cpuset 10 and drops the cpuset lock
5. A proceeds to free the cpuset out from underneath B
Resolve the race by only releasing the last reference under the cpuset lock.
Thread A now picks up the spinlock and observes that the cpuset has been
revived, returning immediately for B to deal with later.
kevans [Tue, 8 Dec 2020 18:44:06 +0000 (18:44 +0000)]
kern: cpuset: plug a unr leak
cpuset_rel_defer() is supposed to be functionally equivalent to
cpuset_rel() but with anything that might sleep deferred until
cpuset_rel_complete -- this setup is used specifically for cpuset_setproc.
Add in the missing unr free to match cpuset_rel. This fixes a leak that
was observed when I wrote a small userland application to try and debug
another issue, which effectively did:
cpuset(&newid);
cpuset(&scratch);
newid gets leaked when scratch is created; it's off the list, so there's
no mechanism for anything else to relinquish it. A more realistic reproducer
would likely be a process that inherits some cpuset that it's the only ref
for, but it creates a new one to modify. Alternatively, administratively
reassigning a process' cpuset that it's the last ref for will have the same
effect.
mhorne [Tue, 8 Dec 2020 18:24:33 +0000 (18:24 +0000)]
arm64: fix struct l_sigaction_t layout
The definition was copied from amd64, but the layout of the struct
differs slightly between these platforms. This fixes spurious
`unsupported sigaction flag 0xXXXXXXXX` messages when executing some
Linux binaries on arm64.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27460
jhb [Tue, 8 Dec 2020 18:00:58 +0000 (18:00 +0000)]
Check that the frame pointer is within the current stack.
This same check is used on other architectures. Previously this would
permit a stack frame to unwind into any arbitrary kernel address
(including unmapped addresses).
adrian [Tue, 8 Dec 2020 17:25:59 +0000 (17:25 +0000)]
[ath] replace the hard-coded magic values in if_athioctl.h with constant defines
Replace some hard-coded magic values in the ioctl stats struct with
#defines. I'm going to follow up with some more sanity checking in
the receive path that also use these values so we don't do bad
things if the hardware is (more) confused.
glebius [Tue, 8 Dec 2020 16:46:00 +0000 (16:46 +0000)]
The list of ports in configuration path shall be protected by locks,
epoch shall be used only for fast path. Thus use LAGG_XLOCK() in
lagg_[un]register_vlan. This fixes sleeping in epoch panic.
emaste [Tue, 8 Dec 2020 14:56:15 +0000 (14:56 +0000)]
Default to WITHOUT_GDB (GDB 6.1.1) for FreeBSD 13
As discussed on -current, -stable, -toolchain, and with jhb@ and imp@,
disable the obsolete in-tree GDB 6.1.1 by default. This was kept only
to provide kgdb for the crashinfo tool, but is long-obsolete, does not
support all architectures that FreeBSD does, and held back other work
(such as forcing the use of DWARF2 for kernel debug).
Crashinfo will use kgdb from the gdb package or devel/gdb port, and will
privde a message referencing those if no kgdb is found.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
kevans [Tue, 8 Dec 2020 14:05:25 +0000 (14:05 +0000)]
src.opts.mk: switch to bsdgrep as /usr/bin/grep
This has been years in the making, and we all knew it was bound to happen
some day. Switch to the BSDL grep implementation now that it's been a
little more thoroughly tested and theoretically supports all of the
extensions that gnugrep in base had with our libregex(3).
Folks shouldn't really notice much from this update; bsdgrep is slower than
gnugrep, but this is currently the price to pay for fewer bugs. Those
dissatisfied with the speed of grep and in need of a faster implementation
should check out what textproc/ripgrep and textproc/the_silver_searcher
can do for them.
I have some WIP to make bsdgrep faster, but do not consider it a blocker
when compared to the pros of switching now (aforementioned bugs, licensing).
ngie [Tue, 8 Dec 2020 04:18:16 +0000 (04:18 +0000)]
extattr_get_file(20: bump .Dd
This is being done for the formatting and context changes. While the net content
hasn't been changed, the content/context changes were sufficient to warrant the
date bump.
ngie [Tue, 8 Dec 2020 04:16:05 +0000 (04:16 +0000)]
extattr_get_file(2): clarify RETURN VALUES
While some of the syscalls' behavior were documented and implied in the
RETURN VALUES section by earlier, e.g., the DESCRIPTION sections, as having
behavior of the other calls (`*_fd` vs `*_file` vs `*_link`), there was a lot
of implied return value behavior in the section prior to this change.
Explicitly document the syscall behavior per the current implementation in
sys/kern/vfs_extattr.c so others can better develop based on its explicit
documented behavior instead of having to digest the context of the manpage to
understand the appropriate behavior.
ngie [Tue, 8 Dec 2020 04:01:03 +0000 (04:01 +0000)]
extattr_get_file(2): sort syscalls alphabetically
Although some sections of the manpage sort the syscalls alphabetically, many
core areas of the manpage do not. Sort the syscalls so it is easier to pick out
functional changes and to improve manpage readability.
This formatting change is also being done to make future functional changes
easier to spot.