Message 189 would have applied to traditional C and was supposed to
detect assignments between struct and union types. The corresponding
check had never been implemented though.
Traditional C has been superseded for 30 years now, therefore there is no
point in adding this check retroactively.
Since rt is an alias for rn->tn_type->t_tspec, it cannot be PTR and VOID
at the same time. This makes the condition unsatisfiable. Removing
that part of the code didn't show any change in behavior, as expected.
It may even be that fixing this obvious bug doesn't show any change in
behavior since that function is only used in a single place and
check_pointer_comparison performs its own checks before issuing any
warning.
At least the test cases added to msg_124.c all run as expected.
There are 2 remaining expressions:
In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.
In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.
There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.
In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.
Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.
The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.
Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.
Seen in usr.bin/make/meta.c:1670: FD_ZERO(&readfds). These macros
cannot be fixed since system headers must not include <stdbool.h>.
Therefore INT constants should be accepted as controlling expressions as
well.
At that stage of analysis, the ampersand is no longer ambiguous, it has
already been resolved as the address-of operator, instead of the
bitwise-and operator.
Previously, lint1 allowed integer constants such as 0 and 1 to be used
as bool constants. This was only half-baked since after fixing all
error messages from that strict mode, there may still be integer
literals in the code that should be replaced with true or false. This
would stop a migration from int to bool in the middle, leaving
inconsistent code around.
To find the remaining type inconsistencies, treat integers and bool as
completely incompatible, even for compile time constants.
Currently, strict bool mode still allows integer constant expressions to
be converted implicitly to bool. This is something that other languages
such as Go, Java, C#, Pascal don't allow.
By providing a custom implementation of <stdbool.h> that defines false
and true to custom bool constant identifiers, lint will cover these
cases as well.
To prepare for this, reword the rules and restructure the tests in
d_c99_bool_strict.c.
Before December 2020, it was cumbersome to add type information to a
message since the caller had to explicitly allocate buffers for the type
names. That's probably the reason why this crucial detail had been left
out of the warning.
In strict bool mode, bool is considered incompatible with all other
scalar types, just as in Java, C#, Pascal.
The controlling expressions in if statements, while loops, for loops and
the '?:' operator must be of type bool. The logical operators work on
bool instead of int, the bitwise operators accept both integer and bool.
The arithmetic operators don't accept bool.
Since <stdbool.h> implements bool using C preprocessor macros instead of
predefining the identifiers "true" and "false", the integer constants 0
and 1 may be used in all contexts that require a bool expression.
Except from these, no implicit conversion between bool and scalar types
is allowed.
See usr.bin/tests/xlint/lint1/d_c99_bool_strict.c for more details.
The command line option -T has been chosen because all obvious choices
(-b or -B for bool, -s or -S for strict) are already in use. The -T may
stand for "types are checked strictly".
The default behavior of lint doesn't change. The strict bool check is
purely optional.
An example program for strict bool mode is usr.bin/make, which has been
using explicit comparisons such as p != NULL, ch != '\0' or n > 0 in
most places for a long time now, even before the refactoring in 2020.
It's GXemul that has the bug! Unfortunately, there's no way (currently) to
detect if we're running under GXemul emulation, so disable for all mips
for now. Hopefully, GXemul will get fixed soon.
There is no danger in allowing (flags & FLAG) as a controlling
expression, provided that it is immediately compared to zero, such as in
an if statement or as the operand of a logical operator.
This strict mode is not yet implemented. The plan is to use it for
usr.bin/make, to get rid of the many possible variants of defining the
Boolean type in make.h. These variants did find some bugs, but not
reliably so. Using static analysis seems more promising for this.
In an early stage of developing this test, lint1 crashed in the enum
definition in line 213, where the node for the '?:' had been NULL. This
can happen in other situations as well, such as with syntax errors, but
these should be rare, as lint is usually only run if the compiler has
accepted the source code. Still, there should not be any assertion
failures while running lint1.
Several of the tests only need to add the -p flag. Mentioning the
(current) default flags in each of these tests is redundant. Therefore,
allow them to specify "lint1-extra-flags: -p" instead of the current
"lint1-flags: -g -S -w -p".
It's perfectly valid to directly use a function name as the controlling
expression of an if statement. That function name is converted
implicitly to a pointer to that function, and that is a scalar value
then.
Spotted by christos in lib/libpthread/pthread.c:634.
In func.c 1.39 from 2020-12-31 18:51:28, the check that controlling
expressions are indeed scalar was extended from while and for loops to
if statements as well. It just seemed to have been an oversight.
This revealed a bug in lint, which didn't accept the following valid
code snippet from lib/libpthread/pthread.c:634:
void _malloc_thread_cleanup(void) __weak;
...
if (_malloc_thread_cleanup)
_malloc_thread_cleanup();
Testing a function (instead of a function pointer) for truthiness is
probably rare since most functions are defined unconditionally. For
weak functions it comes in handy though.
Clang-Tidy suggests to prefix the function with '&' to silence its
warning. Doing that revealed a non-obvious behavior in build_ampersand,
which does not add the AMPER node to the expression even though it is
clearly mentioned in the code. That is left for further research.
Once the original bug is fixed, it probably doesn't matter whether the
AMPER is discarded or retained since check_controlling_expression would
add it back. There's probably a reason though to sometimes discard the
AMPER and sometimes retain it.
- add fudge mode which gives a slightly slower hash function, but works
almost always in the first iteration by avoiding degenerate edges
- avoid keeping incidence lists around reducing the memory foot print by
30%
- split edge processing from hashing as in the non-fudge case it is a
reasonable costly part that often gets thrown away
- merge graph2 and graph3 routines now that they are mostly the same
i386 is an ILP32 platform (arch/i386/targparam.h). On these platforms,
int and long have the same size, and even with the -p option for
portability checks, INT_RSIZE in inittyp.c is defined to 4, not 3.
Because of this, in check_integer_conversion, psize(nt) was not greater
than psize(ot), and the warning was not issued.
To make the test behave the same on all platforms, changed the long
variables to long long, since long long is 64-bit on all platforms, and
int is 32-bit.
These symbolic names for INCBEF, INCAFT, DECBEF and DECAFT were
non-standard and thus confusing. All other operators were as expected.
Now that the operator names from ops.def are very similar, there is no
need to keep to almost identical lists around.
No change to the user-visible messages since the only place where these
operator names were used was in 324, and that message was restricted to
PLUS, MINUS, MULT and SHL.
Including the "p" in the symbolic operator names was questionable, for
several reasons:
1. The "p" could be taken to mean an actual variable name, which is
confusing if the function doesn't have such a variable, or even more
so if the line contains an unrelated variable called "p".
2. For the binary operators, having the "p" mentioned on both sides of
the operator (such as in "p + p") wrongly suggested that both
operands of the expression were the same.
3. The name "p" often stands for a pointer. Most of the operators
don't accept pointers, therefore the name was misleading.
For these reasons, the "p" was removed from the symbolic name of all
operators. This makes several pairs of operators indistinguishable:
INCBEF == INCAFT
DECBEF == DECAFT
UPLUS == PLUS
UMINUS == MINUS
STAR == MULT
AMPER == AND
This is not expected to create any confusion since C programmers are
expected to know these double meanings.
The symbolic names for SHLASS and SHRASS were missing the '=' before.
This was added since omitting it was probably an oversight.
This warning is the only one that calls print_tnode, which in turn uses
the redundant operator names in str_op_t.
There is another list of operator names in ops.c, but those names
include more clutter, for example "p + p" instead of a simple "+".
Using those operator names would therefore rather be confusing. These
two lists should be merged, to remove unnecessary redundancy.
It took quite a while to get to the correct interpretation of this small
piece of code and to draw the right conclusions from it. Now the bug is
finally ready to be fixed, as already announced in the test.
The message may be correct, but it is not helpful in any way. There are
just too many function pointers that may differ in a very small detail.
Before tyname.c 1.20 from 2021-01-02, the string representation of type
names was often limited to only 63 characters. Because of this, it made
sense to omit any detail that could need more space than this. Now that
this limitation is gone, it's reasonable to add more detail to the type
information, especially since that information is readily available.
The body of an ATF test must never return 1 but instead report failure
via atf_fail. Otherwise the following error message appears:
Failed: Test case body returned a non-ok exit code, but this is
not allowed
The test program t_integration intentionally bypasses the official ATF
API for performance reasons. But even then, it should stick to the API
as close as possible.
Bug: _Bool is not accepted as a bit-field, but it should be.
Bug: lint aborts in a controlled manner with message "common/tyname.c,
190: tspec_name(0)" when it sees a declaration of a _Complex bit-field.
(Not that a _Complex bit-field would make any sense.)
Since main1.c from 2014-04-18, running lint in -t mode produces strange
warnings in lines 1 to 3 of no file at all.
This is caused by the builtins that are parsed in main(). These
builtins are incompatible with traditional mode because they use long
double, which had not been known at that time.
Having a test for each message ensures that upcoming refactorings don't
break the basic functionality. Adding the tests will also discover
previously unknown bugs in lint.
The tests ensure that every lint message can actually be triggered, and
they demonstrate how to do so. Having a separate file for each test
leaves enough space for documenting historical anecdotes, rationale or
edge cases, keeping them away from the source code.
The interesting details of this commit are in Makefile and
t_integration.sh. All other files are just auto-generated.
When running the tests as part of ATF, they are packed together as a
single test case. Conceptually, it would have been better to have each
test as a separate test case, but ATF quickly becomes very slow as soon
as a test program defines too many test cases, and 50 is already too
many. The time complexity is O(n^2), not O(n) as one would expect.
It's the same problem as in tests/usr.bin/make, which has over 300 test
cases as well.
The variable namemem is supposed to be a circular list, which is
"documented" implicitly in push_member.
The implementation was buggy though. In pop_member, the circular list
was destroyed though. Given the list (capital, major, favorite_color,
green), removing capital made major point to itself in the forward
direction, even though it should not have been modified at all.
In the test, I had been too optimistic to quickly understand the code
around variable initialization. I was wrong though, so I had to adjust
the comments there to reality.
Whether a test is supposed to produce lint warnings is determined by the
corresponding .exp file. There is no need to encode this information
redundantly in the test driver.
This test had never been enabled. In t_integration.sh 1.3 from
2014-04-17 it was supposed to be enabled, but due to a line continuation
backslash, the words "test_case check_valid" ended up as the description
of the previous test, cvt_in_ternary.
While here, add the expected test output for d_struct_init_nested to
FILES.
since there are already tests for audio this is focused on making
sure the ioctls translate properly and implement the necessary OSS
compat quirks.
right now this only covers the dsp ioctls, it should also cover the
mixer ioctls, although that's significantly harder.
---
date: 2020-07-27 09:57:44 -0700; author: gson; state: Exp; lines: +6 -1; commitid: m3HouRBlhyJQVJhC;
Skip the repeated_link_addr test by default as it causes the
evbarm-aarch64 testbed to hang (PR port-evbarm/55521), and will not be
safe to run by default even after that bug is fixed, for similar
reasons as t_repeated_updown.
---
t_repeated_mtu.sh changes the MTU, which may cause NFS to fail.
if you have NFS root, this is system killing.
t_repeated_scan.sh kills and restarts both hostapd and
wpa_supplicant.
sure we own the guard page before we set its protection to none. This fixes
random SEGVs where the page we set protection to none probably belonged to
the dynamic linker. Reported by gson@
(if date fails, because of bad or out of range input
to parsedate, it cannot be expected to output the
expected result).
Remove the atf-expect-fail now that parsedate() should
detect overflows, and fail, causing date to fail, rather
than simply producing bogus results.
When calling FXSAVE, XSAVE, FXRSTOR, ... for 64-bit programs on amd64
use the 64-suffixed variant in order to include the complete FIP/FDP
registers in the x87 area.
The difference between the two variants is that the FXSAVE64 (new)
variant represents FIP/FDP as 64-bit fields (union fp_addr.fa_64),
while the legacy FXSAVE variant uses split fields: 32-bit offset,
16-bit segment and 16-bit reserved field (union fp_addr.fa_32).
The latter implies that the actual addresses are truncated to 32 bits
which is insufficient in modern programs.
The change is applied only to 64-bit programs on amd64. Plain i386
and compat32 continue using plain FXSAVE. Similarly, NVMM is not
changed as I am not familiar with that code.
This is a potentially breaking change. However, I don't think it likely
to actually break anything because the data provided by the old variant
were not meaningful (because of the truncated pointer).
The code in suff.c is already hard to understand, and so were the tests
in suffixes.mk since several independent topics were merged into a
single test.
Splitting this test into a separate test per issue allows to document
the expected and actual behavior in more detail. That's complicated
enough already.
PR bin/49086
http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libc/sys/t_ptrace_core_wait.h#rev1.2
> For powerpc, program counter is not automatically incremented by trap
> instruction. We cannot increment PC in the trap handler, which breaks
> applications depending on this behavior, e.g., GDB.
This statement is true for aarch64 and arm.
Also, use PTRACE_BREAKPOINT_SIZE instead of hard-coded 4 to address
instruction next to PC.
OK ryo
Fix the code reconstructing s87_tw (full tag word) from fx_sw (abridged
tag word) to correctly represent all register states. The previous code
only distinguished between empty/non-empty registers, and assigned
'regular value' to all non-empty registers. The new code explicitly
distinguishes the two other tag word values: empty and special.
Rename the MM_REG macro to ST_MAN, to make it clearer that it gets
mantissa of ST registers which overlaps with MM registers but can be
also used to read ST registers (to be used in the next commit). Extend
it to cover the difference between GETFPREGS and GETXSTATE,
and therefore avoid additional condition on i386.
Reviewed by kamil.
requirements (correct sh variable/function name syntax). Use a sh
loop instead, and save one fork() one vfork() and one exec of tr for
each test case (many of which don't need anything done to them at all).
This might partially mitigate PR misc/55595
right now. new address-of-packed-member and format-overflow
warnings have new GCC_NO_ADDR_OF_PACKED_MEMBER amd
GCC_NO_FORMAT_OVERFLOW variables to remove these warnings.
apply to a bunch of the tree. mostly, these are real bugs that
should be fixed, but in many cases, only by removing the 'packed'
attribute from some structure that doesn't really need it. (i
looked at many different ones, and while perhaps 60-80% were
already properly aligned, it wasn't clear to me that the uses
were always coming from sane data vs network alignment, so it
doesn't seem safe to remove packed without careful research for
each affect struct.) clang already warned (and was not erroring)
for many of these cases, but gcc picked up dozens more.
Reproducer:
A: for (;;) { mkdir("c", 0600); mkdir("c/d", 0600); mkdir("c/d/e", 0600);
rmdir("c/d/e"); rmdir("c/d"); }
B: for (;;) { mkdir("c", 0600); mkdir("c/d", 0600); mkdir("c/d/e", 0600);
rename("c", "c/d/e"); }
C: for (;;) { mkdir("c", 0600); mkdir("c/d", 0600); mkdir("c/d/e", 0600);
rename("c/d/e", "c"); }
Deadlock:
- A holds c and wants to lock d; and either
- B holds . and d and wants to lock c, or
- C holds . and d and wants to lock c.
The problem with these is that genfs_rename_enter_separate in B or C
tried lock order .->d->c->e (in A/B, fdvp->tdvp->fvp->tvp; in A/C,
tdvp->fdvp->tvp->fvp) which violates the ancestor->descendant order
.->c->d->e.
The resolution is to change B to do fdvp->fvp->tdvp->tvp and C to do
tdvp->tvp->fdvp->fvp. But there's an edge case: tvp and fvp might be
the same (hard links), and we can't detect that until after we've
looked them both up -- and in some file systems (I'm looking at you,
ufs), there is no mere lookup operation, only lookup-and-lock, so we
can't even hold the lock on one of tvp or fvp when we look up the
other one if there's a chance they might be the same.
Fortunately the cases
(a) tvp = fvp
(b) tvp or fvp is a directory
are mutually exclusive as long as directories cannot be hard-linked.
In case (a) we can just defer locking {tvp, fvp} until the end, because
it can't possibly have {fdvp or fvp, tdvp or tvp} as descendants. In
case (b) we can just lock them in the order fdvp->fvp->tdvp->tvp or
tdvp->tvp->fdvp->fvp if the first one of {fvp, tvp} is a directory,
because it can't possibly coincide with the second one of {fvp, tvp}.
With this change, we can now prove that the locking order is consistent
with the ancestor->descendant partial ordering. Where two nodes are
incommensurate under that partial ordering, they are only ever locked
by rename and there is only ever one rename at a time.
Proof:
- For same-directory renames, genfs_rename_enter_common locks the
directory first and then the children. The order
directory->child[i] is consistent with ancestor->descendant and
child[0]/child[1] are incommensurate.
- For cross-directory renames:
. While a rename is in progress and the fs-wide rename lock is held,
directories can be created or removed but not changed, so the
outcome of gro_genealogy -- which, given fdvp and tdvp, returns
the node N relating fdvp/N/.../tdvp or null if there is none --
can only transition from finding N to not finding N, if one of
the directories is removed while any of the vnodes are unlocked.
Merely creating directories cannot change the ancestry of tdvp,
and concurrent renames are not possible.
Thus, if a gro_genealogy determined the operation to have the
form fdvp/N/.../tdvp, then it might cease to have that form, but
only because tdvp was removed which will harmlessly cause the
rename to fail later on. Similarly, if gro_genealogy determined
the operation _not_ to have the form fdvp/N/.../tdvp then it
can't begin to have that form until after the rename has
completed.
The lock order is,
=> for fdvp/.../tdvp:
1. lock fdvp
2. lookup(/lock/unlock) fvp (consistent with fdvp->fvp)
3. lock fvp if a directory (consistent with fdvp->fvp)
4. lock tdvp (consistent with fdvp->tdvp and possibly fvp->tdvp)
5. lookup(/lock/unlock) tvp (consistent with tdvp->tvp)
6. lock fvp if a nondirectory (fvp->t* or fvp->fdvp is impossible)
7. lock tvp if not fvp (tvp->f* is impossible unless tvp=fvp)
=> for incommensurate fdvp & tdvp, or for tdvp/.../fdvp:
1. lock tdvp
2. lookup(/lock/unlock) tvp (consistent with tdvp->tvp)
3. lock tvp if a directory (consistent with tdvp->tvp)
4. lock fdvp (either incommensurate with tdvp and/or tvp, or
consistent with tdvp(->tvp)->fdvp)
5. lookup(/lock/unlock) fvp (consistent with fdvp->fvp)
6. lock tvp if a nondirectory (tvp->f* or tvp->tdvp is impossible)
7. lock fvp if not tvp (fvp->t* is impossible unless fvp=tvp)
Deadlocks found by hannken@; resolution worked out with dholland@.
XXX I think we could improve concurrency somewhat -- with a likely
big win for applications like tar and rsync that create many files
with temporary names and then rename them to the permanent one in the
same directory -- by making vfs_renamelock a reader/writer lock: any
number of same-directory renames, or exactly one cross-directory
rename, at any one time.
drwx------ so when we change to a different user, we can't find the socket
we created.
Make a directory and put the socket in there. Of course now atf can't
record its results as a different user, but that is not fatal.
tc-se:FATAL ERROR: Cannot create results file '/tmp/atf-run.9vOjFd/tcr': \
Permission denied
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.
Use sigaction() without SA_RESTART -- signal() implies SA_RESTART so
we never got the EINTR.
While here, reduce the timeout to something more reasonable so we
don't waste 20min of testbed time if anything goes wrong and the
one-second alarm doesn't fire.
It had no effect because RUMP_SOCKETS_LIST is not set in the shell
running the cleanup phase. Even if RUMP_SOCKETS_LIST had been set,
the code would still not have worked correctly because it ran
rump.halt via "atf_check -s exit:1", which would cause the first
successful halting of a rump processes to be treated as a failure
and abort the cleanup without halting any other rump processes still
running.
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
cgd performance is not as good as I was hoping (~4% improvement over
chacha_ref.c) but it should improve substantially more if we let the
cgd worker thread keep fpu state so we don't have to pay the cost of
isb and zero-the-fpu on every 512-byte cgd block.
The 4-blocks-at-a-time assembly helper is disabled for now; adapting
it to armv7 is going to be a little annoying with only 16 128-bit
vector registers.
(Should also do a fifth block in the integer registers for 320 bytes
at a time.)
evbarm-aarch64 testbed to hang (PR port-evbarm/55521), and will not be
safe to run by default even after that bug is fixed, for similar
reasons as t_repeated_updown.
repeated_updown test case unless explicitly enabled with "atf-run -v
run_unsafe=yes". Gratuitously configuring interfaces "up" is no more
safe than gratuitously configuring them "down"; for example, it could
lead to accidentally connecting to an insecure network or diverting
traffic from the desired route.
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.
In a private email, Miloslav had agreed that if they had written the
test, then it can be licensed bsd-2-clause. I am going to assume this
is true as the file names Miloslav as the author.
This test was likely sent to tcsh (not netbsd) that had changed bug
report systems since.
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.
Setting queue size by TIOCSQSIZE ioctl does not guarantee that data of
that size can be read by single shot of read(2).
Remove assertion based on this assertion, while total amount of data
read from child process is still checked appropriately.
stalled indefinitely in trap instruction even after PT_CONTINUE.
For powerpc, program counter is not automatically incremented by trap
instruction. We cannot increment PC in the trap handler, which breaks
applications depending on this behavior, e.g., GDB.
Therefore, we need to pass (PC + 4) instead of (void *)1 (== PC) to
PT_CONTINUE when child process traps itself.
division by zero is not correctly trapped for i386 and amd64:
https://bugs.launchpad.net/qemu/+bug/1668041
Make trigger_fpe() cause integer division by zero for x86, and
floating-point one for other architectures. Also, assertions for
si_code in *_crash_fpe tests are commented out for now. They
should be cleaned up after the bug is fixed.
Now, *_crash_fpe tests are working also on powerpc.
Suggested by kamil.
until QEMU bug #1668041 is fixed:
https://bugs.launchpad.net/qemu/+bug/1668041
by which floating-point division by zero is not trapped correctly
both on amd64 and i386.
Skip *_crash_fpe tests on powerpc, where integer division by zero
is never trapped.
t_cabsl source is in t_cabsl.cxx not t_cabsl.cc - the latter
is what bsd.tests.mk defaults to.
This only broke after my commit of share/mk/bsd.dep.mk rev 1.85
but I don't know why it didn't cause a problem previously.
When conversion specifier is not a derivative form of "%s", retrieve
input as 32bit integer, and then convert to string literal. Then we
can avoid interpretation from ASCII code to integer, which is
apparently byte-order depended.
integer one, which is not trapped for powerpc and aarch64.
Note that it is checked in lib/libc/gen/t_siginfo whether integer divide by
zero is interpreted as SIGFPE or not.
Now, all *_crash_fpe tests pass for powerpc, and nothing changes for amd64
at least.
This is much better handled by a user-land tool.
Proposed on tech-net here:
https://mail-index.netbsd.org/tech-net/2020/04/22/msg007766.html
Note that the ioctl SIOCGIFINFO_IN6 no longer sets flags. That now
needs to be done using the pre-existing SIOCSIFINFO_FLAGS ioctl.
Compat is fully provided where it makes sense, but trying to turn on
RA handling will obviously throw an error as it no longer exists.
Note that if you use IPv6 temporary addresses, this now needs to be
turned on in dhcpcd.conf(5) rather than in sysctl.conf(5).
New tests:
- fork_setpgid
- vfork_setpgid
- posix_spawn_setpgid
- unrelated_tracer_fork_setpgid
- unrelated_tracer_vfork_setpgid
- unrelated_tracer_posix_spawn_setpgid
These tests trigger a kernel assert for pg_jobc going negative.
The tests are temporarily skipped.
The two files include-sub.mk and include-subsub.mk were never intended to
be test cases on their own. They belong to include-main.mk.
Fixes PR bin/55360.
This logic correctly uses strncpy(3) to fully initialize a fixed-width field, and also ensures
NUL-termination on the next line as other users of the field expect.
Add -Werror=stringop-truncation to prevent build failure, when run with MKSANITIZER=yes.
Error was reported when build.sh was run with MKSANITIZER=yes flag.
Reviewed by: kamil@
==> Provide a much more complete set of setters and getters for different
value types in the prop_array_util(3) and prop_dictionary_util(3)
functions.
==> Overhaul the prop_data(3), prop_number(3), and prop_string(3) APIs
to be easier to use and less awkwardly named, Deprecate the old
awkward names, and produce link-time warnings when they are referenced.
==> Deprecate mutable prop_data(3) and prop_string(3) objects. The old
APIs that support them still exist, but will now produce link-time
warnings when used.
==> When the new prop_string(3) API is used, strings are internally
de-duplicated as a memory footprint optimization.
==> Provide a rich set of bounds-checked gettter functions in and a
corresponding set of convenience setters in the prop_number(3) API.
==> Add a new prop_bool_value(3) function that is equivalent to
prop_bool_true(3), but aligned with the new "value" routines in
prop_data(3), prop_string(3), and prop_number(3).
Set SIGPASS for SIGCHLD for the traced child in the following tests:
- unrelated_tracer_fork*
- unrelated_tracer_vfork*
- unrelated_tracer_posix_spawn*
There is a race that SIGCHLD might be blocked during forking and dropped.
PR/55241 by Andreas Gustafsson
Set SIGPASS for SIGCHLD for the traced child in the following tests:
- posix_spawn_singalmasked
- posix_spawn_singalignored
- fork_singalmasked
- fork_singalignored
- vfork_singalmasked
- vfork_singalignored
- vforkdone_singalmasked
- vforkdone_singalignored
There is a race that SIGCHLD might be blocked during forking and dropped.
PR/55241 by Andreas Gustafsson
fifo_vnodeop_opv_desc symbols.
Many filesystems ffs, lfs, ulfs, chfs, ext2fs etc. use fifofs
internally for their fifo vnops. NFS does too, but it also needs
networking anyway. Unfortunately fifofs brings in a lot of the
networking code so that the rumpkernel is not well partition. In
addition the fifo code is rarely used.
The existing hack depended on duplicating the above symbols and
adding minimal functionality for the majority of the the tests
(except the ffs and the puffs one). In these two cases both symbols
were loaded and the symbol sizes clashed which broke the sanitizers.
While this can be fixed with weak symbols and other kinds of
indirection, it is more straight forward to select between the
minimal and the full fifofs implementation by introducing a new
shared library librumpvfs_nofifofs.
SIGCHLD once blocked is discarded by the kernel as it has the
SA_IGNORE property. During the fork(2) operation all signals can be
shortly blocked and missed (unless there is a registered signal
handler in the traced child). This leads to a race in this test if
there would be an intention to catch SIGCHLD.
Fixes PR lib/55241 by Andreas Gustafsson
Instead of comparing old and new signal mask, just after the cloning
operation, check whether the expected signal is still masked and in
another test whether it is still ignored.
Catch up after t_ptrace_fork_wait.h r. 1.2.
ELF RTLD after rtld.c r. 1.204 introduced locking that wraps the fork
syscall. This locking changes signal mask of the calling process during
the forking process.
Instead of comparing old and new signal mask, just after the forking
operation, check whether the expected signal is still masked and in
another test whether it is still ignored.
- kqueue_mode_{RDONLY,RDWR}_READ: Fix expected value.
This is rest of rev1.9.
- AUDIO_SETINFO_params_simul: Fix condition.
This happens on full-duplex, not bi-directional.
These affect only standalone test, not atf.
- In uvm_voaddr_release(), if the anon ref count drops to 0, call
uvm_anfree() rather than uvm_anon_release(). Unconditionally drop
the anon lock, and release the extra hold on the anon lock obj.
Fixes a panic that occurs if the backing store for a futex backed by
an anon memory location is unmapped while a thread is waiting in the
futex.
Add a test case that reproduced the panic to verify that it's fixed.
Compensate for that by adding an explicit test to a command so
-e will not kill the shell when the command (expectedly) fails.
Previously this was saved by /bin/sh disabling -e in command subs.
