The vether interface simulates a normal Ethernet interface by encapsulating
standard network frames with an Ethernet header, specifically for use as
a member in a bridge(4).
To use vether the administrator needs to configure an address onto the
interface so that packets can be routed to it. An Ethernet header will
be prepended and, if the vether interface is a member of a bridge(4),
the frame will show up there.
Taken from OpenBSD.
Allow multiple concurrent waits at a time, and allow enqueueing work
at the same time (as long as it's not the work we're waiting for).
This way multiple users can use a shared global workqueue and safely
wait for individual work items concurrently, while the workqueue is
still in use for other items (e.g., wg(4) peers).
This has the side effect of taking away a diagnostic measure, but I
think allowing the diagnostic's false positives instead of rejecting
them is worth it. We could cheaply add it back with some false
negatives if it's important.
Unclear why this was set; setting it seems to have required a kludge
in netinet/in.c that broke ipsec tunnels. Clearing it makes wg work
again after that kludge was reverted.
- Fix typo: hmap -> thmap
- Reduce excessive indentation.
- Specify largest entry width for flag name table.
- Include parameter names in function descriptions for easier
reference.
Still planning to replace wgconfig(8) and wg-keygen(8) by one wg(8)
tool compatible with wireguard-tools; update wg(4) for the minor
changes from the 2018-06-30 spec to the 2020-06-01 spec; &c. This just
clarifies the current state of affairs as it exists in the development
tree for now.
Mark the man page EXPERIMENTAL for extra clarity.
- Highlight security model at top.
- Add adiantum and aes-xts.
- Split ciphers into `ciphers' and `obsolete ciphers'.
- Specify the parameters to the ciphers: tweak, CBC IV.
- Relegate obsolete `IV method' concept to a much shorter section.
- Add references.
Arranges kthread_fpu_enter/exit around calls to the worker. Saves
cost over explicit calls to kthread_fpu_enter/exit in the worker by
only doing it once, since there's often a high cost to flushing the
icache and zeroing the fpu registers.
As proposed on tech-kern:
https://mail-index.netbsd.org/tech-kern/2020/06/20/msg026524.html
The MI definitions don't do anything but maintain a flag, but MD code
can define kthread_fpu_enter/exit_md to actually enable/disable the
FPU. (These are almost pcu_load/discard on systems that use pcu(9),
except they apply to all PCUs.)
Discussed on tech-kern:
https://mail-index.netbsd.org/tech-kern/2020/06/20/msg026524.html
The proposed kthread flag KTHREAD_FPU is not included because I
couldn't find any particular need for it that would not be covered by
just calling kthread_fpu_enter/exit in the kthread function.
Previously, the best reference was pckbd.4. This does not make much
sense to read if you are on, say, an evbarm device with only USB.
wsconsctl.8 contained a vaguer description of supported language names,
which isn't very useful because you can't pass full language names
to the command. Point readers to wskbd.4 instead.
Note in the wskbd.4 page that while all layouts are generally supported
by pckbd(4) and ukbd(4), older keyboard interfaces might only support
a subset.
All outstanding allocations MUST have been performed with vmem_xalloc() or
else the behavior is undefined. (This also implies that the arena must also
not have a quantum cache; note this in the documentation.)
Once BIOCLOCK is executed, the device becomes locked which prevents the
execution of ioctl(2) commands which can change the underlying parameters
of the bpf(4) device. An example might be the setting of bpf(4) filter
programs or attaching to different network interfaces.
BIOCSETWF can be used to set write filters for outgoing packets.
Currently if a bpf(4) consumer is compromised, the bpf(4) descriptor can
essentially be used as a raw socket, regardless of consumer's UID.
Write filters give users the ability to constrain which packets can be sent
through the bpf(4) descriptor.
Taken from OpenBSD.
also remove M_PCB - while it is used by SCTP, it's actually not defined
anywhere
in fact add new NOTES section explaining that the malloc types are
actually not used on NetBSD
And the associated ezload EZ-USB code, which is only used by uyap.
It could theoretically be used by other drivers, but none of them are
in tree.
I suspect that this device isn't in use, as phone technology has improved
a lot since 2001 when uyap(4) was added to the tree.
Proposed with no objections on netbsd-users on 13 April 2020
It is simpler if there is only one place we check the condition.
That said, there are cases where the caller needs to re-check before
choosing to fail (e.g., futex_wait in kern/sys_futex.c, which must
verify the condition before taking destructive steps to abort the
wait). But it's not clear that that's the norm.
Previously, a negative timeout was forbidden (kassert), a zero or
maybe even just a sufficiently small timeout would block forever, and
we would subtract the time elapsed -- possibly longer than the
timeout, leading to a negative updated timeout, which would trip the
kassert the next time around if used as advertised. DERP.
Now negative timeouts are still forbidden in order to detect usage
mistakes, but a zero timeout fails immediately and we clamp the
subtracted time to be at least zero so you can always safely call
cv_timedwaitbt in a loop.
(An alternative would be to fail immediately for all nonpositive
timeouts, and to leave in the timespec the negative time we overshot,
but it's not clear this would be useful.)
This way the first two paragraphs have parallel structure:
- _Applications_ should read from /dev/urandom or sysctl kern.arandom...
- _Systems_ should be engineered to read once from /dev/random...
Primary goals:
1. Use cryptography primitives designed and vetted by cryptographers.
2. Be honest about entropy estimation.
3. Propagate full entropy as soon as possible.
4. Simplify the APIs.
5. Reduce overhead of rnd_add_data and cprng_strong.
6. Reduce side channels of HWRNG data and human input sources.
7. Improve visibility of operation with sysctl and event counters.
Caveat: rngtest is no longer used generically for RND_TYPE_RNG
rndsources. Hardware RNG devices should have hardware-specific
health tests. For example, checking for two repeated 256-bit outputs
works to detect AMD's 2019 RDRAND bug. Not all hardware RNGs are
necessarily designed to produce exactly uniform output.
ENTROPY POOL
- A Keccak sponge, with test vectors, replaces the old LFSR/SHA-1
kludge as the cryptographic primitive.
- `Entropy depletion' is available for testing purposes with a sysctl
knob kern.entropy.depletion; otherwise it is disabled, and once the
system reaches full entropy it is assumed to stay there as far as
modern cryptography is concerned.
- No `entropy estimation' based on sample values. Such `entropy
estimation' is a contradiction in terms, dishonest to users, and a
potential source of side channels. It is the responsibility of the
driver author to study the entropy of the process that generates
the samples.
- Per-CPU gathering pools avoid contention on a global queue.
- Entropy is occasionally consolidated into global pool -- as soon as
it's ready, if we've never reached full entropy, and with a rate
limit afterward. Operators can force consolidation now by running
sysctl -w kern.entropy.consolidate=1.
- rndsink(9) API has been replaced by an epoch counter which changes
whenever entropy is consolidated into the global pool.
. Usage: Cache entropy_epoch() when you seed. If entropy_epoch()
has changed when you're about to use whatever you seeded, reseed.
. Epoch is never zero, so initialize cache to 0 if you want to reseed
on first use.
. Epoch is -1 iff we have never reached full entropy -- in other
words, the old rnd_initial_entropy is (entropy_epoch() != -1) --
but it is better if you check for changes rather than for -1, so
that if the system estimated its own entropy incorrectly, entropy
consolidation has the opportunity to prevent future compromise.
- Sysctls and event counters provide operator visibility into what's
happening:
. kern.entropy.needed - bits of entropy short of full entropy
. kern.entropy.pending - bits known to be pending in per-CPU pools,
can be consolidated with sysctl -w kern.entropy.consolidate=1
. kern.entropy.epoch - number of times consolidation has happened,
never 0, and -1 iff we have never reached full entropy
CPRNG_STRONG
- A cprng_strong instance is now a collection of per-CPU NIST
Hash_DRBGs. There are only two in the system: user_cprng for
/dev/urandom and sysctl kern.?random, and kern_cprng for kernel
users which may need to operate in interrupt context up to IPL_VM.
(Calling cprng_strong in interrupt context does not strike me as a
particularly good idea, so I added an event counter to see whether
anything actually does.)
- Event counters provide operator visibility into when reseeding
happens.
INTEL RDRAND/RDSEED, VIA C3 RNG (CPU_RNG)
- Unwired for now; will be rewired in a subsequent commit.
Addresses PR misc/52607. (I suppose something about this could also be
added to the man pages for the mount commands for each applicable file
system, but I think this should suffice.)
and pool_prime() (and their pool_cache_* counterparts):
- the pool_set*wat() APIs are supposed to specify thresholds for the count of
free items in the pool before pool pages are automatically allocated or freed
during pool_get() / pool_put(), whereas pool_sethardlimit() and pool_prime()
are supposed to specify minimum and maximum numbers of total items
in the pool (both free and allocated). these were somewhat conflated
in the existing code, so separate them as they were intended.
- change pool_prime() to take an absolute number of items to preallocate
rather than an increment over whatever was done before, and wait for
any memory allocations to succeed. since pool_prime() can no longer fail
after this, change its return value to void and adjust all callers.
- pool_setlowat() is documented as not immediately attempting to allocate
any memory, but it was changed some time ago to immediately try to allocate
up to the lowat level, so just fix the manpage to describe the current
behaviour.
- add a pool_cache_prime() to complete the API set.
on the OpenBSD single-port XR21V1410 uxrcom driver, but adds support
for multi-port chipsets and uses the common umodem framework instead of
being a standalone driver.
Thanks to skrll@ for much USB clue and mrg@ for financing the
development of this driver.
again after wakeup. Previously it could panic because cv_signal() could
be called by cv_wait_sig() + others:
cv_broadcast(cv);
cv_destroy(cv);
- In support of the above, if an LWP doing a timed wait is awoken by
cv_broadcast() or cv_signal(), don't return an error if the timer
fires after the fact, i.e. either succeed or fail, not both.
- Remove LOCKDEBUG code for CVs which never worked properly and is of
questionable use.
When a mono recording device is set to use 1 channel, the kernel will
correct the number of channels back down to 1. This information can be
obtained with AUDIO_GETINFO...
It doesn't work properly, but this turns out to not be a problem in most
code (code where it is generally uses threads)...
Don't provide misleading information about using it, or programmers
might start wondering why their code doesn't work.
Noted by Yorick Hardy on current-users
true, all mappings have been removed, the pmap is totally cleared out, and
UVM can then avoid doing the work to call pmap_remove() for each map entry.
If false, either nothing has been done, or some helpful arch-specific voodoo
has taken place.
On devices such as the Thinkpad X250, the clickpad can be pressed
to generate mouse button events 1 and 2. There are also additional
physical buttons which the pms(4) driver recognizes as "up/down" buttons
(mouse buttons 3 and 4). Allow these to be remapped to buttons 1 and 2
and used like normal touchpad buttons with the following sysctl:
# sysctl -w hw.synaptics.up_down_emulation=3
While here, adjust the existing "middle button emulation"
(hw.synaptics.up_down_emulation=1) so it works with single-button
clickpads.
XXX: 3 may be a more useful default than the current default,
depending on hardware availability of touchpads with "up/down buttons".
Update the documentation accordingly.
TFTPROOT does *not* require MEMORY_DISK_IS_ROOT. In fact, it doesn't
work at all when MEMORY_DISK_IS_ROOT is set, because then setroot()
tries to perform dhcp on md0 instead of the network card.
These are currently listed in order of uid because I went through
src/etc/group and src/etc/master.passwd line by line, and sorting any
other way after the fact -- like lexicographically, how it should be
-- was kinda inconvenient.
Feel free to sort, add information, add historical references,
correct any mistakes, &c., so that these remain living documents
describing NetBSD's standard users and groups and practices around
them.
roy