Rework how rtables are allocated and reduce use of RT_TABLEID_MAX
Currently rtables use multiple arrays to do lookups and the reallocation
logic is complex and not race free. Replace all of this with a much
simpler lookup that is inspired by the if_idxmap used to map interfaces.
Use a single SMR backed object that contains the size and the array
of rtable pointers. This array can only grow and objects referenced
from the array are never freed. So the life-cycle becomes much simpler.
To make this work struct rtable needs to include all information
contained in a rtable / rdomain. This includes the sourceaddr per table,
the loopback interface index, the rtable to rdomain mapping and in the
future also the multicast router data. Once a struct rtable is allocated
it is never freed.
At the same time reduce the usage of RT_TABLEID_MAX and have rtable_exists
do the check against the real limit. In general code like SIOCSLIFPHYRTABLE
only need to verify that the rdomainid is non-negative and the upper limit
[3 lines not shown]
During DVACT_SUSPEND, after ensuring the soft state was good, this
would try to reset the chip, then keep trying to restart it, pretty
much iteratively, and would reach into sleeping logic. This is obviously
incorrect and not neccessary. Unfortunately this diff is since noone
has showed up with one of these devices in years.
Do not compile helper functions only used by the regress test, or by the
hibernate code, unless we are building the regress test, or a kernel with
option HIBERNATE.
rpki-client: disallow certs with zero serialNumber
Consistency is hard:
RFC 5280 (eid3200 clarifies) and RFC 6487 disallow a zero serialNumber.
For extra fun, CRLNumber and manifestNumber are defined via ASN.1
explicitly allowing zero. So we need some extra dances.
Arguably eid3200 was resolved the wrong way.
Serial number issue pointed out by the rpki-rp-benchmark.
ok claudio
rpki-client: split some helpers out of cms.c
There are a bunch of helper functions that are not really CMS specific
that will be shared by several signed object parsers. Implementations
go into rpki-der.c and they are prototyped in rpki-der.h. The latter
should eventually replace rpki-asn1.h.
ok claudio
Directly dispatch the files referenced by a mft in the parser.
There is no need to circle back to the parent process to schedule more work.
This is the minimal way to handle this and should allow us to further improve
the MFT handling.
The work items enqueued by an MFT are put on the global entity queue but
only after the mft message was enqueued into the output queue.
OK tb@
rpki-client: use strncmp() after x509_location()
Now that the protocol (always expected to be https:// or rsync://) is
normalized, we can do a simpler check.
Prompted by a report by Ties de Kock
ok claudio
rpki-client: reject short URIs in x509_location()
Reject URIs not long enough to hold https:// or rsync://. While "a:///b/c"
is in principle legal, this isn't plausibly a valid URI that should occur
in the wild. Reject certs containing this.
pointed out by/ok claudio
rpki-client: normalize known URI schemes in x509_location()
RFC 3986 was written under full influence of the robustness principle,
necessarily making all code handling URIs complicated and fragile. This
is further exacerbated by RFC 5280 explicitly mentioning that scheme and
host part of a URI are case-insensitive (for SAN, not explicitly for a
URI accessLocation, but that seems implied).
The schemes explicitly specified by RFC 6487 and friends are rsync and
https and that's the only ones the callers do anything with. Normalize
these to be lower case and accept other schemes (and currently no scheme)
for simplicity. This avoids hitting an errx() in queue_add_from_cert().
Reported by Ties de Kock
ok claudio
Convert some assert() to simple http request failures with warn message.
In theory the asserts placed should never be hit since for example at the
end of a request no outstanding data should be left in the buffers. In
practice those asserts did trigger too often. Bad servers could remotly
trigger them and so it is clear that these failures are not assertions.
Triggered by a report by Ties de Kock
OK tb@
Reject receive transfers whose descriptor frame length exceeds the data
actually transferred. The descriptor carries a 12-bit frame length and
the chip accepts frames up to 4095 bytes, but a receive transfer only has
MCLBYTES minus the descriptor for frame data.
Trusting the descriptor produced an mbuf extending past its cluster.
A fragmented IPv4 datagram then carried it into m_cat(), where a default
kernel panics on a DIAGNOSTIC assertion.
Report and diff from Acts1631.
ok miod@ claudio@ kettenis@
Remove support for "fpu disabled" traps in the kernel. This used to be needed
to allow VIS instructions to be used in the kernel, but the last use of them
was removed in 2003.
ok claudio@
fix comment in uhid_xb360gp_report_descr, erroneously stating REPORT SIZE when it is REPORT COUNT. from Lucas de Sena ( lucas () seninha ! org ). No functional change.
uhidev_intr: reject payloads that exceed their declared input report
sizes. Lower priority bug where a malicious/compromised USB device can
overwrite memory.
Report and diff from Acts1631. ok deraadt@
Sometimes a specific address family will be broken or have sub-optimal
connectivity, and require manual overrides.
Allow -4 and -6 to specify using IPv4 or IPv6. Defaults don't change and
use whatever your system is configured to use first.
OK sthen@ kn@
