| Age | Commit message (Collapse) | Author |
|---|
|
We toggle the interrupt "line" on the vcpu when we assert or deassert
irq on the pic in either the vcpu thread (emulating some devices)
or on the device event thread (mostly handling reading available
data). Having it in the vcpu run loop here just results in another
ioctl(2) call before the one for re-entering the guest cpu.
Removing it shows no noticeable behavioral change in existing guests.
ok mlarkin@
|
|
speaking this is not necessary as all used bits of the uint32_t are
zeroed.
ok mlarkin
|
|
|
|
The initial mmio support for vmd adds support for only specific MOV
and MOVZX instructions. Plan is to begin iterating in-tree on other
missing pieces. All functionality is gated behind an #if for now.
Only change to vmm(4) is reordering register #define's in vmmvar.h.
ok mlarkin@
|
|
parseextcommunity but used afterwards.
Found by codechecker.
OK claudio
|
|
|
|
initialization.
OK tb
|
|
ok tb
|
|
location header was received.
OK deraadt
|
|
or write in send_command failed.
Found by codechecker.
OK deraadt
|
|
The ASN.1 profile in draft-ietf-sidrops-rfc6482bis section 4 specifies
that there must not be more than 2 ipAddrBlocks (one for IPv4, and one
for IPv6). Compatible with all published ROAs.
OK tb@
|
|
It has been annoying me for too long that fully specififed GUAs
(2001:0db8:3333:4444:5555:6666:7777:8888) mess up alignment.
systat(1)'s netstat is the only view that has a big enough limit and thus
never misaligns.
Unify ndp(8), route(8) and netstat(1) views to always align nicely.
Feedback OK claudio
|
|
large part of the code.
Issue reported and fix tested by Bars Bars tutbaranov (at) gmail.com
OK tb@
|
|
L3VPN NLRI have different encoding for updates and withdraws. The withdraw
carries one dummy MPLS label that needs to be skipped. The code doing that
did adjust the lenght but did not skip the the label in the buffer and so
the parsed prefix was off by 3 bytes.
OK tb@
|
|
OK tb@
|
|
|
|
|
|
Logging the presence of a keydisk the same way offline data chunks are
logged seems unjustified:
Offline data chunks mean the softraid volume is degraded and installboot(8)
should be rerun when they're online.
Offline keydisks just means the user unplugged their USB key or so and
installboot must never touch them anyway, so the absence of keydisks is
meaningless to installboot -- it should never touch them.
So a) drop the "is keydisk - skipping" message and b) hoist the keydisk
check before the offline check so as to avoid "not online - skipping"
messages for offline keydisks.
|
|
|
|
The Oracle OpenBoot 4.x Administration Guide[0] documents a few useful
options for network boot.
Basically, either
{ok} setenv network-boot-arguments tftp-retries=0
{ok} boot net ...
or
{ok} boot net:tftp-retries=0 ...
Newer machines like the T4-2 using OpenBoot 4.38.16 also support BOOTP/DHCP
besides RARP: "dhcp,hostname=puffy" works as expected on my
T4-2, but "boot-filename" and "boot-retries" remain unsupported on this
particular machine despite being documented in the guide.
0: https://docs.oracle.com/cd/E63648_01/html/E63649/gpvll.html#scrolltoc
OK miod
|
|
On EFI platforms, 'installboot -p' on a softraid volume will only prepare
the filesysem inside the volume and leave physical softraid chunks untouched
which leaves you with unbootable chunks.
The current workaround is to prepare chunks manually (see regress).
Fix it in the same spirit the actual "install" already works in softraid.c.
This is what mlarkin has already been tested in a combined diff with the
MD -> MI softraid merge bits from the previous commit.
Works fine on amd64, arm64 and sparc64 upgrades and installations.
OK jsing
|
|
|
|
ctx is leaked in case of an allocation in prefix_dump_new,
prefix_dump_subtree, rib_dump_new, or rib_dump_subtree fails.
Found by CodeChecker.
OK claudio@
|
|
bgpd and ldpd.
Found by CodeChecker.
OK claudio@
|
|
with and OK tb@
|
|
It does not have the prettiest signature, but nicely folds identical copies
into softraid.c, which then allows us to reuse sr_open_chunk() yet again in
an upcoming diff to make -p softraid aware (fixes arm64 installations).
Regress keeps passing.
Works fine on amd64, arm64 and sparc64.
"looks fine" mlarkin for whom this unbreaks a fresh arm64 softraid install
|
|
OK claudio@
|
|
OK tb@
|
|
ok beck@
|
|
Instead of ignoring all non-signedObject accessMethods, we can be stricter
and only allow rpkiNotify (for now) and error on anything else. Also make
sure we properly clean up behind ourselves on error.
With and ok job
|
|
ok kn@
|
|
No functional change.
|
|
|
|
|
|
innocent -n;
noticed by indivc on misc@
|
|
The spec allows multiple accessMethod entries, ordered by preference.
While an rsync URI must be present, others are allowed. Do not fail
in that situation and pick the first rsync URI encountered. The logic
is very similar to the one in x509_get_crl().
ok job
|
|
While RFC 6487, 4.8.2.2 is very explicit about allowing id-ad-signedObject
as the only accessMethod, the clear language was lost during the RFC 8182
editing process. APNIC, TWNIC and JPNIC and a few others are currently
known to have an id-ad-rpkiNotify. The verbose logging allows us to check
the ecosystem while waiting for the point in time where we can turn this
into an error. See also https://www.rfc-editor.org/errata/eid7239.
ok job
|
|
OK tb@ claudio@
|
|
to be used later once it's in snaps.
|
|
ok claudio
|
|
|
|
This improves the hard-to-read error:
rpki-client: .rrdp/59B96A4C078FDCEDBB776D5BE8DF45EAC0149157547270EA7D4647A76611E145/rpki-rsync.us-east-2.amazonaws.com/volume/220c3ec2-ccf9-4b8a-bf61-fd4d1e151271/LAXNBPgDnLLjagP8++RFIoaMCGo.mft: RFC 6487 section 4.8.6: CRL: bad CRL distribution point extension
rpki-client: rpki-rsync.us-east-2.amazonaws.com/volume/220c3ec2-ccf9-4b8a-bf61-fd4d1e151271/LAXNBPgDnLLjagP8++RFIoaMCGo.mft: no valid mft available
to:
rpki-client: rpki.ripe.net/repository/DEFAULT/ZMvVW3ZpjFaCVe2TtDEqMlyFk3E.cer: SIA: rpkiManifest filename contains invalid characters
OK tb@
|
|
OK tb@
|
|
Unfortunately we can't yet error out when accessMethods other than
signedObject are encountered in the SubjectInformationAccess extension
because there is pollution in the ecosystem.
OK tb@
|
|
|
|
RFC 6487 section 4.8.4 restricts the KeyUsage extension on EE
certificates to only be digitalSignature.
RFC 6487 section 4.8.5 forbids the ExtendedKeyUsage extension from
appearing on CA certificates. However, this may change in the future
through the standardisation process.
OK tb@
|
|
|
|
|
|
OK tb@
|
|
OK tb@
|
