| Age | Commit message (Collapse) | Author |
|---|
|
OK deraadt@
|
|
The data are static but they introduce differences between systems.
OK deraadt@
|
|
|
|
/dev/fdt.
ok patrick@, visa@
|
|
bus_space_read_region_n, bus_space_write_region_n and
bus_space_set_region_n functions were all broken.
Same fix as arm64; Thanks to patrick@ for noting that mips64 had the same
code.
ok visa@
|
|
|
|
i was lazy and just put them at the end of the existing set. fyi,
i think major 51 is free on all archs if anyone is looking for
another one.
ok claudio@
|
|
The design is fairly simple: events, in the form of descriptors on a
ring, are being produced in any kernel context and being consumed by
a userland process reading /dev/dt.
Code and hooks are all guarded under '#if NDT > 0' so this commit
shouldn't introduce any change as long as dt(4) is disable in GENERIC.
ok kettenis@, visa@, jasper@, deraadt@
|
|
OK mpi@
|
|
While FIDO/U2F keys were already supported by the generic uhid(4)
driver, this driver adds the first step to tighten the security of
FIDO/U2F access. Specifically, users don't need read/write access to
all USB/HID devices anymore and the driver also improves integration
with pledge(2) and unveil(2): It is pledge-friendly because it doesn't
require any ioctls to discover the device and unveil-friendly because
it uses a single /dev/fido/* directory for its device nodes.
It also allows to support FIDO/U2F in firefox without further
weakening the "sandbox" of the browser. Firefox does not have a
proper privsep design and many operations, such as U2F access, are
handled directly by the main process. This means that the browser's
"fat" main process needs direct read/write access to all USB HID
devices, at least on other operating systems. With fido(4) we can
support security keys in Firefox under OpenBSD without such a
compromise.
With this change, libfido2 stops using the ioctl to query the device
vendor/product and just assumes "OpenBSD" "fido(4)" instead. The
ioctl is still supported but there was no benefit in obtaining the
vendor product or name; it also allows to use libfido2 under pledge.
With feedback from deraadt@ and many others
OK kettenis@ djm@ and jmc@ for the manpage bits
|
|
|
|
inspect the memory layout that the firmware has created. It is
especially useful for UEFI debugging.
OK deraadt@ kettenis@
|
|
and not just ".openbsd.randomdata.retguard". Accept both in the kernel
ldscripts so that they're placed together between the __retguard_{start,end}
symbols.
Similarly, match not just ".openbsd.randomdata" but also
".openbsd.randomdata.*" to pick up other random (pun intended) items.
While here, stub in those retguard bits into all the ldscripts.
ok deraadt@
|
|
retguard and similar when profiling. However, that missed all the .S files,
as ${PROF} wasn't added when ${NORMAL_S} was converted from direct invocation
of ${AS} to instead use ${CC}. Similarly, mcount.o still had retguards
as it cannot be built with -pg. So: pass ${PROF} when compiling .S files,
and compile "no profiling" files with -fno-ret-protector on archs with
retguard.
feedback and ok mpi@ mortimer@
|
|
This network driver covers higher-end models of the OCTEON III family.
They have a modified design whose interface is not compatible with
the lower-end models or earlier chip generations.
The code is still a work in progress. However, it is capable enough
to make the SGMII port functional on the CN7360.
No objection from deraadt@
|
|
it larger than RC4STATE. A long discussion ensued. In conclusion all
entropy inputs are either satisfactory enough, or just as shitty at 512.
|
|
section, which has grown a fair bit with the introduction of retguard.
Mortimer discovered the repeated 512-byte sequence as retguard keys, and
this resolves the issue. (Chacha does not fit on the media, so 1.5K early
drop RC4 is hopefully sufficient in our KARL link universe)
Version crank the bootblocks. sysupgrade -s will install new bootblocks.
ok djm mortimer
|
|
|
|
|
|
|
|
drivers is gross. discussed with visa.
|
|
OK deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
of this piece of code is to facilitate the use of fdt.
|
|
|
|
|
|
|
|
|
|
of soft interrupts are lower than priorities of hard interrupts.
This allows the delivery of hard interrupts while soft interrupts
are masked.
|
|
|
|
|
|
or sending an IPI.
|
|
|
|
approach was not right, and there is still room for improvement.
OK deraadt@
|
|
|
|
were free after the kernel was loaded. The memory occupied by the kernel
image is not included. To let libkvm access the image through /dev/kmem,
return true from is_memory_range() if the physical address is within
the kernel.
|
|
OK deraadt@
|
|
the size of the "boot" file.
OK deraadt@
|
|
in the bootloader.
|
|
kernel handover safer.
|
|
|
|
|
|
|
|
The firmware on OCTEON machines usually does not provide an interface
for accessing devices, which has made it tricky to implement an OpenBSD
bootloader. To solve this device access problem, this new loader has
been built on top of a small kernel. The kernel provides all the
necessary devices drivers, while most of the usual bootloader logic
is in a userspace program in a ramdisk.
The loader program is accompanied by a special device, octboot(4).
The main purpose of this device is to implement a mechanism for
loading and launching kernels. The mechanism has been inspired by Linux'
kexec(2) system call.
The bootloader will be enabled later when it is ready for general use.
Discussed with deraadt@
|
|
|
