signals. This introduces a new kernel and userland NVMM version indicating
this support.
Patch by Kamil Rytarowski <kamil@netbsd.org> and committed on his request.
From the previous commit, there was an off-by-one error left, which was
due to the interaction between designation_add_subscript and
extend_if_array_of_unknown_size.
The other crucial point was to call initstack_pop_nobrace before
accessing the "current initialization stack element". Without this
call, in msg_168.c the "current element" would point to the initializer
level for 'const char *' instead of the one for 'array of const char *'.
One more step towards supporting C99.
Initialization is still buggy but better than before. The remaining bug
is that only the first designator determines the array size, and after
that, the array is no longer considered of unknown size. This
contradicts C99. More improvements to come.
One of the latest "refactorings" introduced a small and practically
unimportant memory leak. If the last initializer in an initialization
had a designator, that designator was not freed.
When the "current initialization" was still a global variable with
unlimited lifetime, it was freed at the beginning of the next
initialization. After the refactorings, this "next initialization"
could no longer see anything from the previous initialization since all
references have been cleaned up at that point. Freeing the memory so
late and in an almost totally unrelated place was a bad idea anyway.
There are far too many places that modify the top element of the
initializer stack. Each of these places should get its own logging, as
long as the code is still complicated. These places are now clearly
marked with initstk_lvalue.
No functional change.
This makes it possible to accurately model C99 initializers, including
their optional designators. Previously, array subscripts had not been
modeled at all.
In the previous commit, debug_designation crashed immediately since I
had not run the code in debug mode even once. The condition 'name !=
head' was a left-over from the old times where the designator was still
a circular list.
No functional change outside debug mode.
Following discussions on current-users@, it seems many rely on ZFS to
store data, and there are not particularly large issues with ZFS. ATF
tests with /tmp as tmpfs, ffs2, and zfs are similar, with only a
slight increase in failures under zfs.
(This commit should probably NOT be pulled up to 9.)
Fixed a problem with verifying a certificate chain when using the
X509_V_FLAG_X509_STRICT flag. This flag enables additional security
checks of the certificates present in a certificate chain. It is
not set by default.
Starting from OpenSSL version 1.1.1h a check to disallow certificates
in the chain that have explicitly encoded elliptic curve parameters
was added as an additional strict check.
An error in the implementation of this check meant that the result
of a previous check to confirm that certificates in the chain are
valid CA certificates was overwritten. This effectively bypasses
the check that non-CA certificates must not be able to issue other
certificates.
If a "purpose" has been configured then there is a subsequent
opportunity for checks that the certificate is a valid CA. All of
the named "purpose" values implemented in libcrypto perform this
check. Therefore, where a purpose is set the certificate chain will
still be rejected even when the strict flag has been used. A purpose
is set by default in libssl client and server certificate verification
routines, but it can be overridden or removed by an application.
In order to be affected, an application must explicitly set the
X509_V_FLAG_X509_STRICT verification flag and either not set a
purpose for the certificate verification or, in the case of TLS
client or server applications, override the default purpose.
([CVE-2021-3450])
Tomasz Mraz
Fixed an issue where an OpenSSL TLS server may crash if sent a
maliciously crafted renegotiation ClientHello message from a client.
If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms
extension (where it was present in the initial ClientHello), but
includes a signature_algorithms_cert extension then a NULL pointer
dereference will result, leading to a crash and a denial of service
attack.
A server is only vulnerable if it has TLSv1.2 and renegotiation
enabled (which is the default configuration). OpenSSL TLS clients
are not impacted by this issue. ([CVE-2021-3449])
Peter Kaestle and Samuel Sapalski
ETXRDY interrupts are sometimes (once per a few hours?) lost; TX stalls
until next RX arrives.
Since interrupt-based I/O works just fine for other devices, I believe
this problem is due to UART and not to PIC or its driver.
In order to work around this bug, enable COM_HW_BROKEN_ETXRDY bit, as
well as carry out polling once per 10 sec or 1k tics (arbitrary, but
1 min seems too long).
XXX
Apply this for other MPC824x-based boards?
possible in comintr() even if IIR_NOPEND is asserted.
Combined with sc_poll_ticks, this flag works around HW bug, by which
ETXRDY interrupts are (sometimes) lost.
Polling is scheduled at every sc_poll_ticks ticks.
This is useful to work around H/W bug, by which interrupts are lost
*sometimes*; interrupt-based I/O mostly works and no need for polling
every counter ticks.
When sending frame shorter than 60 octets, we add trailing \0's to
payload to construct 60-octet frame.
rge.c rev 1.4--1.7 did this tail-padding on buffer provided by caller,
which results in memory corruption if buffer is shorter than 60 bytes.
Instead, allocate temporary buffer on stack, and work on it.
This bug affects tftp_getnextblock() compiled by GCC8 and later, by
which stack layout has drastically changed. However, even with GCC7,
if tftp.c is compiled with -O0, the bug becomes tangible.
This has been a long-standing limitation of lint. Now it is almost
ready for C99, see the list of "major changes" in the foreword of C99.
One known remaining bug in the area of initialization is designators
with several levels, such as '.member[2].member.member'. Oh, and
designators for arrays are only supported in the parser but not in the
type checker. There's still some work to do.
Missing braces after 'if', since init.c 1.68 from 2021-02-20.
GCC 10 doesn't complain about this even with -Wmisleading-indentation
since at least one of the involved lines is a macro invocation (in this
case both lines). GCC 11 will warn about this.
Clang warns about this, but the regular Clang build currently fails for
other reasons, so this problem didn't show up there either.
- add LDSTATIC to all the LINK rules, replacing CPPFLAGS which should not be
used
- create new COMPILE_LINK rules that are like LINK rules but have CPPFLAGS
where appropriate
