| Age | Commit message (Collapse) | Author |
|
Use same calculation as getrusage, not some ad-hoc arithmetic of
internal scheduler parameters that are periodically rewound.
PR kern/57512
XXX pullup-8
XXX pullup-9
XXX pullup-10
|
|
|
|
No functional change intended.
|
|
|
|
kpreempt_disabled worked for my testing because I tested on aarch64,
which doesn't have kpreemption.
XXX Should move curcpu_stable() to somewhere that other things can
use it.
|
|
High-priority xcalls may reasonably assume that the spl is raised to
splsoftserial, so make sure to do that in xc_broadcast.
Low-priority xcalls may reasonably enter paths that assume the lwp is
bound to a CPU, so let's make it assertable even if it doesn't have
any other consequences when !mp_online.
XXX pullup-8
XXX pullup-9
XXX pullup-10
|
|
initializing ci->ci_xen_hardclock_systime_ns, to avoid a possible race with
xen_timer_handler()
|
|
|
|
|
|
This uses hard interrupts to check progress of low-priority soft
interrupts, and one CPU to check progress of another CPU.
If no progress has been made after a configurable number of seconds
(kern.heartbeat.max_period, default 15), then the system panics --
preferably on the CPU that is stuck so we get a stack trace in dmesg
of where it was stuck, but if the stuckness was detected by another
CPU and the stuck CPU doesn't acknowledge the request to panic within
one second, the detecting CPU panics instead.
This doesn't supplant hardware watchdog timers. It is possible for
hard interrupts to be stuck on all CPUs for some reason too; in that
case heartbeat(9) has no opportunity to complete.
Downside: heartbeat(9) relies on hardclock to run at a reasonably
consistent rate, which might cause trouble for the glorious tickless
future. However, it could be adapted to take a parameter for an
approximate number of units that have elapsed since the last call on
the current CPU, rather than treating that as a constant 1.
XXX kernel revbump -- changes struct cpu_info layout
|
|
|
|
multicast frames, pointed out by Lwazi Dube.
|
|
aarch64eb.
Fix comments to explain what is going on for {arm,aarch64}eb on QEMU.
This is not due to QEMU bugs; it correctly configures everything for
little-endian environment, and we forcibly change byte order only for
CPU cores during kernel bootstrap.
|
|
Update mk.conf(5) with the rump variables from
- lib/librumpuser/README.compileopts
- sys/rump/README.compileopts
Add cross-references back to mk.conf(5) in those files.
Ensure that the Default: is listed last in a description,
for consistency with the convention in this file.
|
|
XXX pullup-10
|
|
Nothing is interrupt-driven here, so no need for condvars to allow
more prompt wakeups.
|
|
Allows loading of ramdisk.fs via u-boot initrd (to run sysinst)
|
|
|
|
|
|
|
|
The system will (in a subsequent change) by default block for this
condition before almost all of userland is running (including
/etc/rc.d/sshd key generation). That way, a never-blocking
getentropy(3) API will never return any data without at least
best-effort entropy like netbsd<=9 did to applications except in
single-user mode (where you have to be careful about everything
anyway) or in the few processes that run before a seed can even be
loaded (where blocking indefinitely, e.g. when generating a stack
protector cookie in libc, could pose a severe availability problem
that can't be configured away, but where the security impact is low).
However, (in another subsequent change) we will continue to use
_only_ HWRNG driver estimates and seed estimates, and _not_
time-delta estimator, for _warning_ about security in motd, daily
security report, etc. And if HWRNG/seed provides enough entropy
before time-delta estimator does, that will unblock /dev/random too.
The result is:
- Machines with HWRNG or seed won't warn about entropy and will
essentially never block -- even on first boot without a seed, it
will take only as long as the fastest HWRNG to unblock.
- Machines with neither HWRNG nor seed:
. will warn about entropy, giving feedback about security;
and
. will avoid returning anything more predictable than netbsd<=9;
but
. won't block (much) longer than netbsd<=9 would (and won't block
again after blocking once, except with kern.entropy.depletion=1 for
testing).
(The threshold for unblocking is now somewhat higher than before:
512 samples that pass the time-delta estimator, rather than 80 as
it used to be.)
And, of course, adding a seed (or HWRNG) will prevent both warnings
and blocking.
The mechanism is:
1. /dev/random will block until _either_
(a) enough bits of entropy (256) from reliable sources have been
added to the pool, _or_
(b) enough samples have been added from any sources (512), passing
the old time-delta entropy estimator, that the possible
security benefit doesn't justify holding up availability any
longer (`best effort'), except on systems with higher security
requirements like securelevel=2 which can disable non-HWRNG,
non-seed sources with rndctl_flags in rc.conf(5).
2. dmesg will report `entropy: ready' when 1(a) is satisfied, but if
1(b) is satisfied first, it will report `entropy: best effort', so
the concise log messages will reflect the timing and whether in
any period of time any of the system might be relying on best
effort entropy.
3. The sysctl knob kern.entropy.needed (and the ioctl RNDGETPOOLSTAT
variable rndpoolstat_t::added) still reflects the number of bits
of entropy from reliable sources, so we can still use this to
suggest regenerating ssh keys.
This matters on platforms that can only be reached, after flashing
an installation image, by sshing in over a (private) network, like
small network appliances or remote virtual machines without
(interactive) serial consoles. If we blocked indefinitely at boot
when generating ssh keys, such platforms would be unusable. This
way, platforms are usable, but operators can still be advised at
login time to regenerate keys as soon as they can actually load
entropy onto the system, e.g. with rndctl(8) on a seed file copied
from a local machine over the (private) network.
4. On machines without HWRNG, using a seed file still suppresses
warnings for users who need more confident security. But it is no
longer necessary for availability.
This is a compromise between availability and security:
- The security mechanism of blocking indefinitely on machines without
HWRNG hurts availability too much, as painful experience over the
multiple years since I made the mistake of introducing it have
shown. (Sorry!)
- The other main alternative, not having a blocking path at all (as I
pushed for, and as OpenBSD has done for a long time) could
potentially reduce security vs netbsd<=9, and would run against the
expectations set by many popular operating systems to the severe
detriment of public perception of NetBSD security.
Even though we can't _confidently_ assess enough entropy from, e.g.,
sampling interrupt timings, this is the traditional behaviour that
most operating systems provide -- and the result here is a net
nondecrease in security over netbsd<=9, because all paths from the
entropy pool to userland now have at least as high a standard before
returning data as they did in netbsd<=9.
PR kern/55641
PR pkg/55847
PR kern/57185
https://mail-index.netbsd.org/current-users/2020/09/02/msg039470.html
https://mail-index.netbsd.org/current-users/2020/11/21/msg039931.html
https://mail-index.netbsd.org/current-users/2020/12/05/msg040019.html
XXX pullup-10
|
|
|
|
Previously, primary bootstrap was able to boot on RAID-1 RAIDframe set
with the limitation that the FFS filesystem had to start at bloc 0 in the
RAID. That allowed inner RAID partitionning with a disklabel, but not with
a GPT.
When booting on a RAID-1 RAIDframe, primary bootstrap now first try a
filesystem at bloc 0 of the RAID as before. On failure, it tries to
read a GPT and load secondary bootstrap from, by priority;
1) the first partition with the bootme attribute set
2) the first partition of type FFS, LFS, CCD or CGD
3) the first partition present in the GPT
|
|
- cache DEC and FG registers, only write them if the value actually changes
- wait for the engine to go idle before writing DEC
- wait for FIFO slots on everything else
with this we avoid waiting if possible and still avoid overlapping blit and
fill commands
|
|
we get occasional overlap with blit commands if we just wait for fifo slots
needs further investigation, it is possible that not all writes to drawing
engine registers are pipelined and of course we don't have docs
|
|
|
|
|
|
|
|
friendly condvar(9). No functional change intended.
|
|
I see no reason why it should be there, and believe its a leftover from
some old code.
|
|
No functional changes.
|
|
The culprit was callout_halt(). "(c->c_flags & CALLOUT_FIRED) != 0" wasn't
the correct way to check if a callout is running. It failed to wait for a
running callout to finish in the following scenario:
1. cpu0 initializes a callout and schedules it.
2. cpu0 invokes callout_softlock() and fires the callout, setting the flag
CALLOUT_FIRED.
3. The callout invokes callout_schedule() to re-schedule itself.
4. callout_schedule_locked() clears the flag CALLOUT_FIRED, and releases
the lock.
5. Before the lock is re-acquired by callout_softlock(), cpu1 decides to
destroy the callout. It first invokes callout_halt() to make sure the
callout finishes running.
6. But since CALLOUT_FIRED has been cleared, callout_halt() thinks it's not
running and therefore returns without invoking callout_wait().
7. cpu1 proceeds to invoke callout_destroy() while it's still running on
cpu0. callout_destroy() detects that and panics.
|
|
|
|
|
|
|
|
|
|
Fixes non-MP boot for me.
|
|
|
|
|
|
|
|
|
|
Breaks tpm(4) which breaks boot on a lot of systems. tpm(4)
shouldn't be using tsleep; it doesn't appear to even have an
interrupt handler for wakeups, so it could get by with kpause. If it
ever did sprout an interrupt handler it should use condvar(9) anyway.
But for now I don't have time to fix it tonight.
|
|
This is never safe to use without the kernel lock. It should only
appear in legacy subsystems that still run with the kernel lock.
|
|
Add some KASSERTMSG while here.
|
|
is created on the stack SP remains 16-byte aligned as per the ABI
requirements.
Patch from Rin with some updates from me.
|
|
|
|
Not sure if there's any padding here, but it's a pretty big
structure, fairly likely, so let's be rather safe than sorry.
XXX pullup-8
XXX pullup-9
XXX pullup-10
|
|
Unclear if there are any paths to the copyout without initialization,
but let's play it safe to keep the auditing effort low.
XXX pullup-8
XXX pullup-9
XXX pullup-10
|
|
Unclear if this can leak anything but let's be on the safe side.
XXX pullup-8
XXX pullup-9
XXX pullup-10
|
|
|