| Age | Commit message (Collapse) | Author |
|---|
|
|
|
ok claudio@ deraadt@
|
|
|
|
|
|
|
|
it in unwindctl status output next to the all time histogram.
|
|
enforce a new policy: system calls must be in pre-registered regions.
We have discussed more strict checks than this, but none satisfy the
cost/benefit based upon our understanding of attack methods, anyways
let's see what the next iteration looks like.
This is intended to harden (translation: attackers must put extra
effort into attacking) against a mixture of W^X failures and JIT bugs
which allow syscall misinterpretation, especially in environments with
polymorphic-instruction/variable-sized instructions. It fits in a bit
with libc/libcrypto/ld.so random relink on boot and no-restart-at-crash
behaviour, particularily for remote problems. Less effective once on-host
since someone the libraries can be read.
For static-executables the kernel registers the main program's
PIE-mapped exec section valid, as well as the randomly-placed sigtramp
page. For dynamic executables ELF ld.so's exec segment is also
labelled valid; ld.so then has enough information to register libc's
exec section as valid via call-once msyscall(2)
For dynamic binaries, we continue to to permit the main program exec
segment because "go" (and potentially a few other applications) have
embedded system calls in the main program. Hopefully at least go gets
fixed soon.
We declare the concept of embedded syscalls a bad idea for numerous
reasons, as we notice the ecosystem has many of
static-syscall-in-base-binary which are dynamically linked against
libraries which in turn use libc, which contains another set of
syscall stubs. We've been concerned about adding even one additional
syscall entry point... but go's approach tends to double the entry-point
attack surface.
This was started at a nano-hackathon in Bob Beck's basement 2 weeks
ago during a long discussion with mortimer trying to hide from the SSL
scream-conversations, and finished in more comfortable circumstances
next to a wood-stove at Elk Lakes cabin with UVM scream-conversations.
ok guenther kettenis mortimer, lots of feedback from others
conversations about go with jsing tb sthen
|
|
|
|
ok "yeeees" claudio@
|
|
s/EXIT_FAILURE/1/
ok claudio@
|
|
s/EXIT_FAILURE/1/
ok claudio@
|
|
s/EXIT_FAILURE/1/
ok claudio@
|
|
s/EXIT_FAILURE/1/
kind of ok claudio@
|
|
s/EXIT_FAILURE/1/
ok claudio@
|
|
ok claudio@ muppets@
|
|
ok claudio@
|
|
ok claudio@
|
|
|
|
the cert can be used to load the correct CRL. This simplifies the code
even further.
OK benno@, beck@ agrees that this is the right way to do it
|
|
If no output file is specified, output to the bgpd/bgpd.conf-compatible
/var/db/rpki-client/roa file.
ok claudio and benno
|
|
this will work better with upcoming privdrop rpki-client and bgpd consumption
ok benno
|
|
|
|
blocks. No longer bubble up the chain in the hope that something is covered.
If this causes issues people need to fix the repository where it causes
errors.
|
|
found by deraadt in most unfunny circumstances.
|
|
After debugging with ori@, it looks like an event ends up on the wrong
libevent queue, and we end continually de-queueing and re-queueing the
event continually. While it's unclear exactly why this happened, a clue
on libevent's github issues page for the same problem pointed us to using
a different event base for the device events. This seems to have unstuck
ori@'s problematic VM, and I have also seen no more hangs after this.
We have not completely separated the queues; ori@ will work on setting
new libevent bases for those later. But those events are pretty
frequency.
with help from and ok ori@
|
|
ok claudio@ deraadt@
|
|
|
|
the parent auth struct is stored as a pointer so walking up the certificate
chain remains simple. Doing this replaces a few slow lookups and speeds up
rpki-client by a factor of 2.
OK benno@
|
|
try to fetch it.
OK benno@ (part of a larger diff)
|
|
work much better with bgpd.conf include automation.
ok claudio benno
|
|
ok claudio@ deraadt@
|
|
benno and stsp stared...
|
|
|
|
ok claudio@
|
|
Replace the hand-written routing with a proper library allowing even more
formats.
Since ldomctl's local util.h conflicts with the now used global util.h from
libutil, rename it to ldom_util.h.
Manual wording from amd64's vm.conf(5).
OK kettenis
|
|
ok claudio@
|
|
"ldomctl console guest01" executes cu(1) on the domain's console.
Now more device minor guessing or copying; behaviour is completely analogue
to vmctl(8) on amd64.
OK kettenis
|
|
The virtual console concentrator port's minor had to be infered from the
guest's internal ID which corresponds to the order of listing.
To lift this implementation detail, simply print the device ready to copy
and use with cu(1).
OK kettenis
|
|
|
|
|
|
Simplifies the code a fair bit.
|
|
|
|
|
|
IP address, port and authentication name.
This makes print_config less awkward and fixes a bug were an
alternative port number was not printed.
|
|
|
|
|
|
against the CA one layer above it. This check just needs to use the
certificate revocation list published by that CA.
Instead of loading all CRLs we find into the trust store, we create a
STACK_OF(X509_CRL), push the onto it and use it with
X509_STORE_CTX_set0_crls(ctx, crls);
The x509_get_crl() function to retrieve a crl path from an X509 object
is written by claudio@.
ok claudio@
|
|
list-io lists available PCIe devices to be used with ldom.conf(5)'s
iodevice parameter.
OK kettenis
|
|
|
|
that represent various header fields. One place where OXMs are used is in
the sef_field action, which contains one OXM representing the header field
to set, followed by padding to align the action in the OpenFlow message to
64 bits. Currently, we assume that a set_field action can contain multiple
OXMs and that they do not need to be padded.
This matches the way we handle OpenFlow messages that contain set_field
actions so that we follow the specs.
OK ori claudio
|
