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.
