| Age | Commit message (Collapse) | Author |
|---|
|
an "unpriviliged" load/store instruction. This makes sure we catch
PAN violations and might even catch some incorrect user-space access
cases on systems without PAN.
ok drahn@, jsg@
|
|
ok kettenis@, patrick@
|
|
have stored the struct cpu_info * in the wrapper around the interrupt
handler cookie, but since we can have a few layers inbetween, this does
not seem very nice. Instead have each and every interrupt controller
provide a barrier function. This means that intr_barrier(9) will in the
end be executed by the interrupt controller that actually wired the pin
to a core. And that's the only place where the information is stored.
ok kettenis@
|
|
already assume every cookie is wrapped and simply retrieve the pointer
from it. It's a bit of a layer violation though, since only the intc
should actually store that kind of information. This is good enough for
now, but I'm already cooking up a diff to resolve this.
ok dlg@
|
|
somehow gain access to the struct cpu_info * used to establish the
interrupt. One possibility is to store the pointer in the cookie
returned by the establish methods. A better way would be to ask
the interrupt controller directly to do barrier.
This means that all external facing interrupt establish functions
need to wrap the cookie in a common way. We already do this for
FDT-based interrupts. Also most PCI controllers already return
the cookie from the FDT API, which is already wrapped. So arm64's
acpi_intr_establish() and acpipci(4) now need to explicitly wrap
it, since they call ic->ic_establish directly, which does not wrap.
ok dlg@
|
|
a struct cpu_info *. From a driver point of view the fdt_intr_establish_*
API now also exist same functions with a *_cpu suffix. Internally the
"old" functions now call their *_cpu counterparts, passing NULL as ci.
NULL will be interpreted as primary CPU in the interrupt controller code.
The internal framework for interrupt controllers has been changed so that
the establish methods provided by an interrupt controller function always
takes a struct cpu_info *.
Some drivers, like imxgpio(4) and rkgpio(4), only have a single interrupt
line for multiple pins. On those we simply disallow trying to establish
an interrupt on a non-primary CPU, returning NULL.
Since we do not have MP yet on armv7, all armv7 interrupt controllers do
return NULL if an attempt is made to establish an interrupt on a different
CPU. That said, so far there's no way this can happen. If we ever gain
MP support, this is a reminder that the interrupt controller drivers have
to be adjusted.
Prompted by dlg@
ok kettenis@
|
|
length of up to 31 characters. This limit is also present in the
flattened device tree specification/ Unfortunately this limit isn't enforced
by the tooling and there are systems in the wild that use longer strings.
This includes the device trees used on POWER9 systems and has been seen
on some ARM systems as well.
So bump the buffer size from 32 bytes (31 + terminating NUL) to 64 bytes.
Centrally define OFMAXPARAM to this value (in <dev/ofw/openfirm.h>)
replacing the various OPROMMAXPARAM definition scattered around the tree
to make sure the FDT implementation of OF_nextprop() uses the same
buffer size as its consumers.
Eliminate the static buffer in various openprom(4) implementations on
FDT systems.
Makes it possible to dump the full device tree on POWER9 systems using
eeprom -p.
ok deraadt@, visa@
|
|
"looks right" deraadt@
|
|
with a bit-reversed copy of itself. There is progressively less
entropy in the higher bits of a counter than in the lower bits, so
bit-reverse one half in order to extract maximal entropy.
style fixes and ok kettenis@
|
|
|
|
rnd.c uses nanotime to get access to some bits that change quickly
between events that it can mix into the entropy pool. it doesn't
use nanotime to get a monotonically increasing set or ordered and
accurate timestamps, it just wants something with bits that change.
there's been discussions for years about letting rnd use a clock
that's super fast to read, but not necessarily accurate, but it
wasn't until recently that i figured out it wasn't interested in
time at all, so things like keeping a fast clock coherent between
cpu cores or correct according to ntp is unecessary. this means we
can just let rnd read the cycle counters on cpus and things will
be fine. cpus with cycle counters that vary in their speed and
arent kept consistent between cores may even be desirable in this
context.
so this is the first step in converting rnd.c to reading cycle
counter. it copies the nanotime backend to each arch, and they can
replace it with something MD as a second step later on.
djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits.
thanks to visa for his eyes.
ok deraadt@ visa@
deraadt@ says he will help handle any MD fallout that occurs.
|
|
ok kettenis@, visa@
|
|
|
|
ok visa@
|
|
ok jsg@
|
|
ok deraadt@, mpi@, visa@
ok cheloha@ as well (would have preferred in new file for this code)
|
|
This ensure spec_kqfilter() won't return an error when spec_poll()
returns success for a given device.
ok visa@
|
|
the file system such that implementations can use it to guess the right
century.
ok mpi@
|
|
implementation.
ok mpi@
|
|
- move implementations next to eachother in the same file
- remove pointless call to resettodr() in inittodr()
- use OpenBSD define to get a minimum plausible time
- if RTC time is before minimum plausible time, reject it
- don't print "clock gained N days" on ramdisk
Hopefully this implementation can serve as a model for unification
into an MI implementation.
ok mpi@
|
|
present. Make sure bus_dmamap_alloc(9) allocates memory that meets that
constraint.
ok patrick@
|
|
Upgrade stacktrace_save() to stacktrace_save_at() on architectures where
the latter is missing. Define stacktrace_save() as an inline function
in header <sys/stacktrace.h> to reduce duplication of code.
OK mpi@
|
|
cache-coherent or not. To implement this, acpi(4) gets two bus_dma tags
and passes the appropriate one when attaching devices based on _CCA.
On i386/amd64, where for all practical purpose DMA is always cache-coherent,
the two tags are the same. But on arm64 they are distinct.
ok patrick@
|
|
EOPNOTSUPP is returned when there's no "filterops" for a given fd.
EINVAL when the requested filter isn't supported by the "filterops".
ENXIO means the underlying device is no longer valid/present.
ok visa@
|
|
arm64 and i386, the chain of call frames is continuous from kernel
to userspace. The unwinder has to stop at the latest when it reaches
the start of the kernel stack.
OK mpi@
|
|
OK kettenis@
|
|
in btreace(8) output.
ok deraadt@, patrick@
|
|
|
|
While the barrier isn't really needed here, it doesn't hurt and having
it there establishes a pattern for people to follow.
idiomatic deraadt@
|
|
to spin trying things.
ok kettenis
|
|
ok patrick@, jsg@
|
|
ok patrick@, jsg@
|
|
insert a barrier after each system call to address a speculative execution
issue discovered by Anthony Steinhauser.
A change to insert two nop instructions after each system call instruction
in crt0.o/libc/ld.so has been committed a few weeks ago, so the transition
should go smoothly. However, old static binaries and binaries that roll
their own syscalls (like go) will no longer work. Snapshot packages
that work with the new syscall ABI are available (including a fixed go).
Together with deraadt@ and guenther@
ok deraadt@
|
|
sigcoderet label must point directly after the svc instruction, because the
sigreturn() checks it as SROP mitigation, so place the sled after the label.
tested by naddy
|
|
for SYS_exit and SYS_sigreturn in the sigtramp"; init has trouble
spawning processes.
|
|
and SYS_sigreturn in the sigtramp. As these control-flow into a jump
or process termination, we never do the +8 dance over the
instructions, however the speculation prevention (once these nops are
replaced with a speculation barrier) is required.
oversight noticed by Anthony Steinhauser.
|
|
|
|
|
|
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@
|
|
require the debugger on most architectures, and the separation makes the
code easier to use from other subsystems.
The function definitions are still conditional to DDB. However, that
should not matter for now.
OK deraadt@, mpi@
|
|
from alex naumov
|
|
|
|
ok deraadt@
|
|
the kernel.
ok patrick@
|
|
processors not all microarchitectural side effects are abandoned,
leading to spectre-like effects. This was fixed quietly and without
responsible disclosure by ARM in linux mainline a year ago, but
rediscovered independently by Anthony Steinhauser. ok patrick
guenther kettenis
comment to ARM: "Responsible Disclosure" doesn't mean "downplay at
maximum to avoid damage to the bottom line", the responsibility aspect
entails ensuring "all customers are aware of the defect". What
happened here is indistinguishable from Intel's behaviour, and that's
not the look you want.
|
|
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
|
|
|
|
|
|
ok dlg@, jasper@
|
