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.
When there is a dependency group at the end of a top-level makefile,
this dependency group is not finished properly. This allows to add
further commands to the targets of this dependency group, which was not
intended.
I had expected that using the ::+= modifier instead of the ::= modifier
would work, since the assignment modifier for COUNTER no longer contains
a reference to itself. But instead of ending up at 4, the counter even
goes up to 6.
There had been two separate global variables for the .END node, and in
parallel mode, only the one in jobs.c was initialized.
The code in JobRun heads over to Compat_Make without calling Compat_Run
first, which left the variable ENDNode uninitialized.
This is useful for finding parse errors only. Inspired by some entries
that are obsolete and have more than the "obsolete" flag. There are
only few of these entries though, and they don't seem worth fixing.
This program is much more complicated than sort-list in the same
directory. It takes care of aligning the fields of the lines so that
lines from the same directory are aligned to each other. This reduces
horizontal jumps for the category and flags fields.
This way, the fields 2 and 3 don't jump horizontally as often as before,
which makes the appearance of the whole file as calm and organized as it
should be.
The previous test vectors didn't contain any hash with a leading zero.
This could have been a simple programming mistake by using %8x instead
of the intended %08x. Using snprintf wouldn't have been possible anyway
since the hex digits are printed in little-endian order, but without
reversing the bits of each digit. Kind of unusual, but doesn't affect
the distribution of the hashes.
For a long time, I had assumed that the iteration variables of a .for
loop are just normal global variables. This assumption was wrong but
didn't have any consequences.
The iteration variables of a .for loop can just be accessed like global
variables, therefore it is not obvious that they are implemented in a
completely different way.
There are some edge cases in conditions used inside .for loops, in which
the iteration variables cannot be used like normal variables. An
example is brought up in https://gnats.netbsd.org/47888, which observes
that the defined() and empty() functions in conditions only work with
variables but ignore the iteration "variables", simply because these are
not variables but only expressions.
This occurred in the posix1.mk test, even though it is disabled in
unit-tests. But in tests/usr.bin/make it still runs. There, it should
have produced an "expected failure" but crashed instead.
The archive-suffix test is the stripped-down version of the posix1 test.
Specifically, it cancels out the same entry elsewhere in the set
list, and apparently it is only for twelve files in the entire tree.
Someone^TM should document this more clearly, and/or just get rid of
it because I'm at least the third person to be confused by this
according to the revision history.
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.
The test has been extended by ensuring that the shuffled words are still
the same. Comparing two shuffled lists is probabilistic, but comparing
their sorted results is not, therefore that's completely sensible to do.
When writing this test, by coincidence I discovered how to generate the
"Undefined variable" error message. Unfortunately, the error message is
wrong since the variable NUMBERS is defined at that point. In summary,
that error message is shown when it shouldn't, and when it should it is
not shown. Still, I'm glad that I finally found it.
The test for the different escaping has been adjusted to actually show
the different parsing results in the test output. To do this, it had to
get its own file since it needs the -dv debug flag and specialized
post-processing.
The test names have been derived from the current manual page.
All these tests are dummies right now, and the code from the existing
tests will be moved into the new tests step by step.
This is done to prevent modmisc, escape, varmod-edge and varmisc from
growing without any bounds, and to reduce the side-effects of one test
to the others.
The old boot_ustar had many hard coding and was small(<1KB).
The new xxboot_ustarfs is a part of integrated larger(<8KB) xxboot.
We had to maintain three similar but not the same bootloaders, but
now we have two!
Three ways to call:
getrandom(p, n, 0) Blocks at boot until full entropy.
Returns up to n bytes at p; guarantees
up to 256 bytes even if interrupted
after blocking. getrandom(0,0,0)
serves as an entropy barrier: return
only after system has full entropy.
getrandom(p, n, GRND_INSECURE) Never blocks. Guarantees up to 256
bytes even if interrupted. Equivalent
to /dev/urandom. Safe only after
successful getrandom(...,0),
getrandom(...,GRND_RANDOM), or read
from /dev/random.
getrandom(p, n, GRND_RANDOM) May block at any time. Returns up to n
bytes at p, but no guarantees about how
many -- may return as short as 1 byte.
Equivalent to /dev/random. Legacy.
Provided only for source compatibility
with Linux.
Can also use flags|GRND_NONBLOCK to fail with EWOULDBLOCK/EAGAIN
without producing any output instead of blocking.
- The combination GRND_INSECURE|GRND_NONBLOCK is the same as
GRND_INSECURE, since GRND_INSECURE never blocks anyway.
- The combinations GRND_INSECURE|GRND_RANDOM and
GRND_INSECURE|GRND_RANDOM|GRND_NONBLOCK are nonsensical and fail
with EINVAL.
As proposed on tech-userlevel, tech-crypto, tech-security, and
tech-kern, and subsequently adopted by core (minus the getentropy part
of the proposal, because other operating systems and participants in
the discussion couldn't come to an agreement about getentropy and
blocking semantics):
https://mail-index.netbsd.org/tech-userlevel/2020/05/02/msg012333.html
The comment at DirExpandCurly says something about "recursively", but the
nested braces don't work.
The manual page only mentions that "{} may be used", but it keeps quiet
about the exact meaning and also doesn't mention any nesting.
The whole code in arch.c had been uncovered by tests before.
The code coverage shows that neither the archive name nor the member
contain any $, even though archive.mk looks like it. It could be
necessary to place the variable assignments below the dependency line,
to force late evaluation.
reinstantiate it
header is for use by xentools only, which define domid_t themselves,
so it should not be a problem the header doesn't define it per PR port-xen/52874
that pre-populate parts of the system (e.g. a tmpfs based /var) an
easy place to plug in like:
# REQUIRE: mountcritlocal
# BEFORE: MOUNTCRITLOCAL
This also cleans up the existing special handling a bit by separating it
into new scripts. All later scripts now depend on MOUNTCRITLOCAL.
Discussed on tech-userlevel some time ago.
Adiantum is a wide-block cipher, built out of AES, XChaCha12,
Poly1305, and NH, defined in
Paul Crowley and Eric Biggers, `Adiantum: length-preserving
encryption for entry-level processors', IACR Transactions on
Symmetric Cryptology 2018(4), pp. 39--61.
Adiantum provides better security than a narrow-block cipher with CBC
or XTS, because every bit of each sector affects every other bit,
whereas with CBC each block of plaintext only affects the following
blocks of ciphertext in the disk sector, and with XTS each block of
plaintext only affects its own block of ciphertext and nothing else.
Adiantum generally provides much better performance than
constant-time AES-CBC or AES-XTS software do without hardware
support, and performance comparable to or better than the
variable-time (i.e., leaky) AES-CBC and AES-XTS software we had
before. (Note: Adiantum also uses AES as a subroutine, but only once
per disk sector. It takes only a small fraction of the time spent by
Adiantum, so there's relatively little performance impact to using
constant-time AES software over using variable-time AES software for
it.)
Adiantum naturally scales to essentially arbitrary disk sector sizes;
sizes >=1024-bytes take the most advantage of Adiantum's design for
performance, so 4096-byte sectors would be a natural choice if we
taught cgd to change the disk sector size. (However, it's a
different cipher for each disk sector size, so it _must_ be a cgd
parameter.)
The paper presents a similar construction HPolyC. The salient
difference is that HPolyC uses Poly1305 directly, whereas Adiantum
uses Poly1395(NH(...)). NH is annoying because it requires a
1072-byte key, which means the test vectors are ginormous, and
changing keys is costly; HPolyC avoids these shortcomings by using
Poly1305 directly, but HPolyC is measurably slower, costing about
1.5x what Adiantum costs on 4096-byte sectors.
For the purposes of cgd, we will reuse each key for many messages,
and there will be very few keys in total (one per cgd volume) so --
except for the annoying verbosity of test vectors -- the tradeoff
weighs in the favour of Adiantum, especially if we teach cgd to do
>>512-byte sectors.
For now, everything that Adiantum needs beyond what's already in the
kernel is gathered into a single file, including NH, Poly1305, and
XChaCha12. We can split those out -- and reuse them, and provide MD
tuned implementations, and so on -- as needed; this is just a first
pass to get Adiantum implemented for experimentation.
or a wscons display device using wsfontload(8).
For example, Spleen 16x32 can be loaded and enabled as follow:
wsfontload -N spleen-16x32 -w 16 -h 32 spleen-16x32.fnt
wsconsctl -dw font=spleen-16x32
XXX Please note that there are now TWO tests named t_mbtowc - this one in
XXX tests/lib/libc/stdlib/ and an older one in tests/lib/libc/locale
XXX I don't know if the functionality is duplicated or not.
takes parameters. Based on quick testing, iwn(4) and wm(4) pass, but
urtwn(4) panics. Use at your own risk; in some cases, it may be possible
that horrors are written directly to the hardware.
This test reproduced already at least five unique panics in a few quick runs.
The test is skipped by default as it is not likely safe even without the panics.
