| Age | Commit message (Collapse) | Author |
|---|
|
and wctrans_t values are locale-specific) so we can simplify our
implementation in libc
ok schwarze@
|
|
This validates the tables used in bn_is_perfect_square() and checks that
for randomly generated numbers the isqrt() is what it is expected to be.
|
|
If neither are found, restrict user actions to printing basic
information on the disk, reading the man page, initializing an
MBR or GPT, or terminating fdisk without changing anything.
Feedback on earlier attempt by miod@ and brynet@.
|
|
In rev 1.90 of rde_decide.c the re->active cache of the best prefix was
replaced with a call to prefix_best(). This introduced a bug because the
nexthop state at that time may have changed already. As a result when
a nexthop became unreachable prefix_evaluate() had oldbest = NULL and
newbest = NULL and did not withdraw the prefix from FIB and Adj-RIB-Out.
To fix this store the nexthop state per prefix and introduce
prefix_evaluate_nexthop() which removes the prefix from the decision list,
updates the nexthop state of the prefix and reinserts the prefix. Doing
this ensures that prefix_best() always reports the same result once the
decison process is done. prefix_best() and prefix_eligible() only depend
on data stored on the prefix itself.
OK tb@
|
|
is reflected in more recent device trees. Adjust the driver accordingly.
ok patrick@
|
|
for the macro generating test functions for other data types.
This makes sense because both are sufficiently different.
It also avoids a large number of false positive compiler warnings
that guenther@ reported.
OK guenther@
|
|
A single "out of order" line is too generic.
OK kettenis
|
|
netlock anymore.
ok bluhm@ yasuoka@
|
|
We don't use "static" keyword for functions declaration to allow ddb(4)
debug. Also, many "Static" functions are called by pppx(4) layer outside
pipex(4) layer.
This is the mostly mechanic diff, except the `pipex_pppoe_padding' which
should be "static const".
ok bluhm@ yasuoka@
|
|
smr_tqh_last is not intended for lockless use with SMR_PTR_GET().
|
|
Let's try this again now that the kernel locking issue in nfsrv_rcv()
has been fixed.
The previous attempt of the conversion triggered hangs on NFS servers.
This was probably caused by the removal of the kernel-locked section
just prior to the socket upcall. The section had masked a locking error
in NFS code.
|
|
|
|
|
|
UNIX System V mention it. Only do so in manual pages with a
pre-existing HISTORY section.
Prompted by the comparison of System V and BSD commands and interfaces
in Sun's "System V Enhancements Overview" document.
checked against manuals on bitsavers, TUHS archive and CSRG archive CDs
ok jmc@ schwarze@
|
|
problem with FreeBSD manual page reported by segaloco on TUHS list
|
|
on most platforms but should prevent warnings in -portable on systems
that don't have 'date %s'.
|
|
shared net lock. ip_deliver() needs exclusive net lock. Instead
of calling ip_deliver() directly, use ip6_ours() to queue the packet.
Move the write lock assertion into ip_deliver() to catch such bugs
earlier.
The assertion was only triggered with IPv6 multicast forwarding or
router alert hop by hop option. Found by regress test.
OK kn@ mvs@
|
|
Do not leak the extension that was deleted from the stack.
via OpenSSL c3efe5c9.
ok jsing
|
|
This was removed shortly after the fork since TS is not 2038-ready
and since there were no consumers of this API. Now there are consumers
and they add it themselves if it's missing from libcrypto. This will no
longer be possible with opaque TS structs, so begrudgingly add it back.
ok jsing kn
|
|
The setters make no sense since they do not free the old members and
return what was passed in instead of returning the old struct member
so that the caller has a chance of freeing them. This has the side
effect that calling a setter a second time will likely result in a leak.
TS_VERIFY_CTX_set_imprint() was "fixed" upstream by adding a free() but
the other three setters were missed since discussing the contributor's
CLA was more important. Also missed was that adding frees will result in
double frees: careful consumers like openssl/ruby have workarounds for
the strange existing semantics.
Add a compat #define for TS_VERIF_CTS_set_certs() that made it into the
public API with a typo.
A good illustration of the amount of thought and care that went into
the OpenSSL 1.1 API by both the implementers and the reviewers.
Amazing job overall.
We will be stuck with this nonsense for a long time.
ok jsing kn
|
|
This adds TS_STATUS_get0_{failure_info,text,status}() as well as
TS_STATUS_INFO_set_status(). These will be needed by Ruby and openssl(1)
when we make the structs in ts.h opaque.
ok kn jsing
|
|
This is Dr Stephen Henson's rewrite avoiding BIGNUM (OpenSSL 54c68d35).
Additionally this pulls in a < vs <= fix by Pauli Dale (OpenSSL 9d868840).
There is also some minor cleanup by myself.
ok jsing
|
|
Pull up clearing of output parameters before first return
(OpenSSL 524fdd51 by Bernd Edlinger), explicit comparisons
against NULL, '\0', etc.
ok jsing
|
|
OpenSSL b709babb by Richard Levitte
ok jsing
|
|
Also switch to heap-allocated HMAC_CTX and clean a few things up
stylistically.
loosely based on OpenSSL f5cee414 by Shane Lontis
ok jsing
|
|
based on OpenSSL 1b8f1937 by Dmitry Belyavskiy
ok jsing
|
|
|
|
The AR9280 half Mini Card (HB92) supports 5GHz as confirmed by athn(4)'s
"The AR9220, AR9223 and AR9280 (codenamed Merlin) ..." paragraph.
pcidevs however wrongly identifies this device as
athn0 at pci2 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 17
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:30:37:de
athn(4) says AR9281 is 2GHz only, so the first line (pcidevs string) does
not match the real information on the second line (from real hardware).
Looking around, the PCI Vendor ID: 168c, Product ID: 002a are described as
* https://pcilookup.com/?ven=168c&dev=002a&action=submit
"AR928X Wireless Network Adapter (PCI-Express)"
* https://pci-ids.ucw.cz/read/PC/168c/002a calls this
"AR928X Wireless Network Adapter (PCI-Express)"
* https://github.com/torvalds/linux/blob/fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4/Documentation/devicetree/bindings/net/wireless/qca%2Cath9k.yaml#L27
says
- pci168c,002a # AR9280 and AR9283
* https://pcisig.com/membership/member-companies?combine=168c
(empty, no result)
* NetBSD pcidevs is like ours
product ATHEROS AR9281 0x002a AR9281
Im summary, "AR928X" seems more appropiate and matches both AR9280 and
AR9281 chipsets, so use that to avoid contradicting dmesg lines:
athn0 at pci2 dev 0 function 0 "Atheros AR928X" rev 0x01: apic 2 int 17
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:30:37:de
stsp confirms how "Atheros naming is very convoluted."
Feedback sthen
OK stsp
|
|
|
|
When used with QUIC, the SSL BIOs are effectively unused, however we still
currently expect them to exist for status (such as SSL_ERROR_WANT_READ and
SSL_ERROR_WANT_WRITE). Set up NULL BIOs if QUIC is in use.
ok tb@
|
|
QUIC uses TLS to complete the handshake, however unlike normal TLS it does
not use the TLS record layer, rather it provides its own transport. This
means that we need to intercept all communication between the TLS handshake
and the record layer. This allows TLS handshake message writes to be
directed to QUIC, likewise for TLS handshake message reads. Alerts also
need to be sent via QUIC, plus it needs to be provided with the traffic
keys that are derived by TLS.
ok tb@
|
|
This is the order that they're called/run in.
|
|
QUIC wants to know what "encryption level" handshake messages should be
sent at. Provide an ssl_encryption_level_t enum (via BoringSSL) that
defines these (of course quictls decided to make this an
OSSL_ENCRYPTION_LEVEL typedef, so provide that as well).
Wire these through to tls13_record_layer_set_{read,write}_traffic_key() so
that they can be used in upcoming commits.
ok tb@
|
|
while here, rework the "set limit" section:
- use a simple list
- add some missing defaults and limit-item
mbuhl helped fill in some of the blanks
ok kn
|
|
Found the hard way by mlarkin@ and deraadt@.
|
|
Instead of setting the alert manually in various parse handlers, we can
make use of the fact that tlsext_parse() sets the alert to decode_error
by default. This simplifies the code quite a bit.
ok jsing
|
|
Move the not yet exposed EssCertIDv2 struct internals to ts_local.h and move
the ASN.1 function prototypes that we don't want to expose with them.
Include ts_local.h where necessary or where it will be needed soon.
ok jsing
|
|
On PowerPC, by design, you cannot mask decrementer (DEC) interrupts
without also masking other interrupts that we want to leave unmasked
at or above IPL_CLOCK. So, currently, the DEC is left unmasked, even
when we're working at IPL_CLOCK or IPL_HIGH. If a DEC interrupt
arrives while we're at those priority levels, the current solution is
to postpone any clock interrupt work until the next hardclock(9) or
statclock tick.
This is a problem for a machine-independent clock interrupt subsystem
because the MD code, e.g. decr_intr(), ideally shouldn't need to know
anything about when the next event is scheduled to occur.
The most obvious solution to this problem that I can think of is to
instead postpone clock interrupt work until the next time our priority
level drops below IPL_CLOCK. This is something we can do from the MD
code without any knowledge of when the next clock interrupt event is
scheduled to occur.
So:
- Add a new boolean, ci_dec_deferred, to the PowerPC cpu_info struct.
- If we reach decr_intr() when the CPU's priority level is too high,
set ci_dec_deferred, clear the DEC exception, and return.
- If we reach decr_intr() and the CPU's priority level is low enough,
clear ci_dec_deferred and do any needed clock interrupt work.
- In splx(9) (there are three different versions we need to update),
check ci_dec_deferred. If it's set and our priority level is
dropping below IPL_CLOCK, raise a DEC exception.
Tested by me on PowerMac7,3 (openpic). Tested by miod@ on PowerMac1,1
(macintr) (`make build` completes). Tested by gkoehler@ on an unknown
PowerMac (probably openpic).
With lots of help from kettenis@.
ok gkoehler@ miod@
|
|
The timecounting subsystem computes elapsed time by scaling (64 bits)
the difference between two counter values (32 bits at most) up into a
struct bintime (128 bits).
Under normal circumstances it is sufficient to do this with 64-bit
multiplication, like this:
struct bintime bt;
bt.sec = 0;
bt.frac = th->tc_scale * tc_delta(th);
However, if tc_delta() exceeds 1 second's worth of counter ticks, that
multiplication overflows. The result is that the monotonic clock appears
to jump backwards.
When can this happen? In practice, I have seen it when trying to
compile LLVM on an EdgeRouter Lite when using an SD card as the
backing disk. The box gets stuck in swap, the hardclock(9) is
delayed, and we appear to "lose time".
To avoid this overflow we need to compute the full 96-bit product of
the delta and the scale.
This commit adds TIMECOUNT_TO_BINTIME(), a function for computing that
full product, to sys/time.h. The patch puts the new function to use
in lib/libc/sys/microtime.c and sys/kern/kern_tc.c.
(The commit also reorganizes some of our high resolution bintime code
so that we always read the timecounter first.)
Doing the full 96-bit multiplication is between 0% and 15% slower than
doing the cheaper 64-bit multiplication on amd64. Measuring a precise
difference is extremely difficult because the computation is already
quite fast.
I would guess that the cost is slightly higher than that on 32-bit
platforms. Nobody ever volunteered to test, so this remains a guess.
Thread: https://marc.info/?l=openbsd-tech&m=163424607918042&w=2
6 month bump: https://marc.info/?l=openbsd-tech&m=165124251401342&w=2
Committed after 9 months without review.
|
|
Apparently, we used to created several kthreads before the kernel
random number generator was up and running. A toggle, "randompid",
was needed to tell allocpid() whether it made sense to attempt to
allocate random PIDs.
However, these days we get e.g. arc4random(9) into a working state
before any kthreads are spawned, so the toggle is no longer needed.
Thread: https://marc.info/?l=openbsd-tech&m=165541052614453&w=2
Very nice historical context provided by miod@.
probably ok miod@ deraadt@
|
|
OK kn
|
|
Simplify the logic and adjust kroute_match() which makes the code
easier to understand.
OK tb@
|
|
interface.
This works around a problem where the kernel always deletes
the first default route if there are multiple present
with the same gateway.
This only fixes the problem when running ifconfig inet -autoconf.
There are other cases where we call configure_rotures(RTM_DELETE), for
example when setting ignore routes in dhcpleased.conf and issuing a
reload. To fix that we either need help from the kernel to distinguish
routes by IFP or track priorities and hope they are unique.
Problem reported by mbuhl.
OK claudio
|
|
to the same gateway.
Unfortunately this doesn't help with deleting the correct route when
issuing ifconfig inet -autoconf, the kernel always deletes the first
route. This is the one with the lowest priority if the routes have
different priorities.
What does work is identifying routes by priority but dhcpleased(8)
doesn't set the priority so that the kernel choses the right one
when adding a route and it doesn't yet track the priority the
kernel set.
Another issue is that we might end up with routes having the same
gateway and same priority pointing out of different interfaces. For
example when two ethernet interfaces are set to autoconf and they are
connected to the layer 2 network. This seems like a bad idea but it is
something that could be configured.
Problem reported by mbuhl, claudio suggested to try to send an IFP.
Even though it doesn't work, it seems worthwhile to send the IFP for
when the kernel gains the ability to distinguish routes by IFP.
|
|
This brings it in line with dhcpleased(8) as well as what we do for
the default route and DNS proposals.
I missed this when I rewrote the state machine to match
dhcpleased(8).
|
|
From a previous diff that was reverted because of a different issue.
was OK tb@
|
|
|
|
prevent cursor jumps when using the trackpoint on some lenovo laptops.
Known affected models:
- Lenovo Thinkpad X13 Gen1
- Lenovo Thinkpad T14(s)
- Lenovo Thinkpad E15 Gen3
- Lenovo A475
With help from stsp@
OK stsp@ miod@ deraadt@ bru@
|
|
PMKIDs are present. Same error as found by Mikhail for ciphers and AKMs.
|
|
Also, pretty-print SAE (used by WPA3) if found in AKMs.
Errors introduced by me in CVS commit hgtOdzeJfB27Yyq0 / r1.40.
Patch by Mikhail
|
