| Age | Commit message (Collapse) | Author |
|---|
|
and with the random-order kernel we shouldn't be doing that anyway.
ok kettenis@
|
|
SIGILL, SIGBUS, SIGSEGV signals. Make such memory violations visible
in lastcomm(1). This also works if a programm tries to hide them
with a signal handler. Manual kill -SEGV does not generate false
positives.
OK deraadt@
|
|
The same notification is already present in ARP.
From Jan Klemkow, ok bluhm@
|
|
|
|
|
|
run so that this locore0.o is always at the start of the executable.
But randomize the link order of all other .o files in the kernel, so
that their exec/rodata/data/bss segments land all over the place.
Late during kernel boot, smash the startup code with traps so that
it does not point to the other randomly placed code. It has be smashed,
because sgi runs in the kseg0 or xkphys space.
As a result, the internal layout of every newly build bsd kernel is
different from past kernels. Internal relative offsets are not known
to an outside attacker.
Ramdisk kernels cannot be compiled like this, because they are gzip'd.
When the internal pointer references change, the compression dictionary
bloats and results in poorer compression.
|
|
run so that this locore0.o is always at the start of the executable.
But randomize the link order of all other .o files in the kernel, so
that their exec/rodata/data/bss segments land all over the place.
Late during kernel boot, smash the startup code with traps so that
it does not point to the other randomly placed code. It has be smashed,
because loongson runs in the kseg0 space.
As a result, the internal layout of every newly build bsd kernel is
different from past kernels. Internal relative offsets are not known
to an outside attacker.
Ramdisk kernels cannot be compiled like this, because they are gzip'd.
When the internal pointer references change, the compression dictionary
bloats and results in poorer compression.
|
|
run so that this locore0.o is always at the start of the executable.
But randomize the link order of all other .o files in the kernel, so
that their exec/rodata/data/bss segments land all over the place.
I haven't worked on the unmap/smashing of the startup code yet.
|
|
|
|
maybe this will help prevent misassignment in the future.
|
|
this removes the need for sys/param.h. this code can be built with
only sys/tree.h, which in turn only needs sys/_null.h.
|
|
this are provided so an RBT and it's topology can be copied without
having to reinsert the copied nodes into a new tree.
there are two reasons RBT_LEFT/RIGHT/PARENT macros cant be used like
RB_LEFT/RIGHT/PARENT for this. firstly, RBT_LEFT and co are functions that
return a pointer value, they dont provide access to the pointer
itself for use as an lvalue that you can assign to. secondly, RBT
entries dont store pointers to other nodes, they point to the
RBT_ENTRY structures inside other nodes. this means that RBT_SET_LEFT
and co have to get an offset from the node to the RBT_ENTRY and
store that.
|
|
this mostly follows the pattern in ifq.h
ok jmatthew@
|
|
when something went wrong. This allows to monitor whether the
system is under attack and that the attack has been prevented by
OpenBSD pledge(2).
OK deraadt@ millert@ jmc@
|
|
and remove some leftover assertions.
|
|
pfkey and unix sockets.
ok claudio@
|
|
and free(9).
The exception is at early boot when only one CPU is running since we
grab the KERNL_LOCK() relatively late in main().
ok kettenis@
|
|
aren't protected by the NET_LOCK().
While here change lock assertions in rt_{set,put}gwroute(), the NET_LOCK()
is enough.
Tested by Hrvoje Popovski.
ok jmatthew@, claudio@
|
|
|
|
Although several codepaths in the kernel such as coredump
and buffercache read-ahead feature assume that underlying
hardware is capable of handling 64kb transfers without any
issues, xbf was setup to rely on a single descriptor per
transfer which limited the maximum size of an individual
transfer to 11 4k segments amounting to 44k bytes.
To avoid overbooking, a metadata object is allocated for
each transfer to keep track of associated descriptors
limiting the maximum amount of outstanding transfers to
half the ring size.
The issue was reported by Dan Cross <crossd at gmail.com>,
thanks!
|
|
|
|
|
|
softraid volume and backing disk when i/o errors occur.
Original issue reported by Paul de Weerd.
Suggestions from jsing@.
ok deraadt@ mikeb@
|
|
|
|
under arch/mips64 once loongson and sgi have gap.o.
Discussed with deraadt@
|
|
|
|
Fix build without PF, PIPEX nor IPSEC.
|
|
|
|
from deraadt@
|
|
|
|
ok stsp@
|
|
to enable PF_LOCK(), you must add 'option WITH_PF_LOCK' to your kernel
configuration. The code does not do much currently it's just the very
small step towards MP.
O.K. henning@, mikeb@, mpi@
|
|
run so that this locore0.o is always at the start of the executable.
But randomize the link order of all other .o files in the kernel, so
that their exec/rodata/data/bss segments land all over the place.
The bootstrap code will need smashing because it is mapped by BLTB,
but this is a bit involved so not done yet.
As a result, the internal layout of every newly build bsd kernel is
different from past kernels. Internal relative offsets are not known
to an outside attacker. The only known offsets are in the startup code
(which will be gone when it is smashed).
Ramdisk kernels cannot be compiled like this, because they are gzip'd.
When the internal pointer references change, the compression dictionary
bloats and results in poorer compression.
|
|
This seems to satisfy the BTLB granularity. Good enough for now.
ok kettenis
|
|
run so that this locore0.o is always at the start of the executable.
But randomize the link order of all other .o files in the kernel, so
that their exec/rodata/data/bss segments land all over the place.
Late during kernel boot, smash the startup code with traps so that
it does not point to the other randomly placed code. It has be smashed,
because alpha (insecurely in my view) runs in the KSEG0 space.
As a result, the internal layout of every newly build bsd kernel is
different from past kernels. Internal relative offsets are not known
to an outside attacker. The only known offsets are in the startup code,
which is gone.
Ramdisk kernels cannot be compiled like this, because they are gzip'd.
When the internal pointer references change, the compression dictionary
bloats and results in poorer compression.
|
|
|
|
|
|
|
|
Unlike on some other architectures, it is not possible to unmap
the early boot code. Instead, the code is smashed during boot.
Input from deraadt@
|
|
And anyways, everything is ELF now.
|
|
directories. Copy it in the same way on other architectures, for the same
effect. Something upcoming will want that file there anyways.
|
|
shrinks the code a bit on sparc64.
ok jmatthew@
|
|
Generating mixed 16-bit/32-bit/64-bit code with clang's integrated
assembler is a bit tricky. It supports the .code16, .code32 and
.code64 directives. But it doesn't know about the data16/data32 and
addr16/addr32 instruction prefixes. Instead it tries to determine
those from the instruction opcode. It mostly succeeds, but there are
a couple of corner cases where clang will generate the "addr32" form
where gas generates the "addr16" form in .code16 segments. That
should be no problem (and just waste a couple of bytes), but it makes
comparing the generated code a bit difficult.
Allow the trampoline code to be compiled with both. For clang #define
away the addr32 prefix and avoid using the data32 prefix by using a
mnemonic that explicitly encodes the size of the operand. Add a few
addr32 prefixes in .code16 blocks to reduce the differences between
code generated by clang and gas.
ok deraadt@
|
|
|
|
|
|
make release work without prior cleanup.
discussed with deraadt
|
|
ok jsg@
|
|
bootloader anymore, so it doesn't matter where it is stored. While
there do some whitespace cleanup.
|
|
run so that this locore0.o is always at the start of the executable.
But randomize the link order of all other .o files in the kernel, so
that their exec/rodata/data/bss segments land all over the place.
Late during kernel boot, unmap the early startup code.
As a result, the internal layout of every newly build bsd kernel is
different from past kernels. Internal relative offsets are not known
to an outside attacker. The only known offsets are in the startup code,
which has been unmapped.
Ramdisk kernels cannot be compiled like this, because they are gzip'd.
When the internal pointer references change, the compression dictionary
bloats and results in poorer compression.
With guidance and ok deraadt@
|
|
ok jsg@
|
