summaryrefslogtreecommitdiff
path: root/sys
AgeCommit message (Collapse)Author
2023-07-08clock_gettime(2): Fix CLOCK_PROCESS/THREAD_CPUTIME_ID.riastradh
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
2023-07-08curcpu_stable(9): New function for asserting curcpu() is stable.riastradh
2023-07-08kern_resource.c: Fix brace placement.riastradh
No functional change intended.
2023-07-07Revert unintentional changes to kern_lock.c in previous commit.riastradh
2023-07-07heartbeat(9): Test whether curcpu is stable, not kpreempt_disabled.riastradh
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.
2023-07-07xcall(9): If !mp_online, raise spl or set LP_BOUND to call func.riastradh
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
2023-07-07Unmask event after VCPUOP_stop_periodic_timer andbouyer
initializing ci->ci_xen_hardclock_systime_ns, to avoid a possible race with xen_timer_handler()
2023-07-07sys/param.h: Welcome to 10.99.5, courtesy of heartbeat(9).riastradh
2023-07-07amd64/ALL: Turn on heartbeat checks.riastradh
2023-07-07heartbeat(9): New mechanism to check progress of kernel.riastradh
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
2023-07-07crashme(9): New crash methods with raised ipl or kpreempt disabled.riastradh
2023-07-07Fix locking error when setting the multicast filter to accept allmartin
multicast frames, pointed out by Lwazi Dube.
2023-07-07virtio(4): Fix byte order of DMA data for armeb in the same manner asrin
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.
2023-07-05mk.conf(5): document rump variableslukem
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.
2023-07-04riscv: Fix (U)INT64_C suffix to match gcc's built-in idea of types.riastradh
XXX pullup-10
2023-07-04tpm(4): Switch tsleep to kpause.riastradh
Nothing is interrupt-driven here, so no need for condvars to allow more prompt wakeups.
2023-07-03Enable MEMORY_DISK_DYNAMIC & co. to match std.generic64jakllsch
Allows loading of ramdisk.fs via u-boot initrd (to run sysinst)
2023-07-01regennia
2023-07-01Add Realtek ALC671 to hdaudiodevs, seen on Fujitsu Futro S720 thin clientnia
2023-07-01Fix build when KERNHIST defined, but not UVMHISTskrll
2023-06-30entropy(9): Reintroduce netbsd<=9 time-delta estimator for unblocking.riastradh
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
2023-06-29s/determin /determine / in comment.andvar
2023-06-29Primary bootstrap is now able to read a GPT inside RAIDframe.manu
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
2023-06-28following a hunch...macallan
- 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
2023-06-28wait for the engine to go idle before issuing rectfill commandsmacallan
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
2023-06-28fix tpyo - now the glyph cache can actually work...macallan
2023-06-27correct register function annotation as it's for receive coalesce.nisimura
2023-06-27remove double/tripple o in comments, where it likely was not added on purpose.andvar
2023-06-27Convert UDF file system code from the depricated tsleep(9)/wakeup(9) to the MPreinoud
friendly condvar(9). No functional change intended.
2023-06-27callout(9): Delete the unused member cc_cancel from struct callout_cpupho
I see no reason why it should be there, and believe its a leftover from some old code.
2023-06-27callout(9): Tidy up the condition for "callout is running on another LWP"pho
No functional changes.
2023-06-27callout(9): Fix panic() in callout_destroy() (kern/57226)pho
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.
2023-06-26s/privious/previous/ in comment.andvar
2023-06-25s/responible/responsible/ in comment.andvar
2023-06-25G/C an unused struct cpu_info memberskrll
2023-06-24Add comments and remove nonexistent status registers.tsutsui
2023-06-24Always initialise ci_tlb_info in cpu_info_store[0].skrll
Fixes non-MP boot for me.
2023-06-24Fix a wrong cdb size of SCSI disk write command. From OpenBSD/luna88k.tsutsui
2023-06-24Fix typo in error message.msaitoh
2023-06-24Fix typo in comment.msaitoh
2023-06-24Fix typo in comment.msaitoh
2023-06-23tsleep: Comment out kernel lock assertion for now.riastradh
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.
2023-06-23tsleep(9): Assert kernel lock held.riastradh
This is never safe to use without the kernel lock. It should only appear in legacy subsystems that still run with the kernel lock.
2023-06-23rump: KASSERT(x && y) -> KASSERT(x); KASSERT(y)riastradh
Add some KASSERTMSG while here.
2023-06-23Pad the trapframe so it's a multiple of 16 bytes so that when a trapframeskrll
is created on the stack SP remains 16-byte aligned as per the ABI requirements. Patch from Rin with some updates from me.
2023-06-23Add missing read to count Circuit Breaker Rx Dropped Packet correctly.msaitoh
2023-06-20linux32_rt_sendsig: Memset zero before copyout.riastradh
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
2023-06-20compat_ossaudio: Zero-initialize idat before copyout.riastradh
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
2023-06-20compat_sunos32: Memset zero before copyout.riastradh
Unclear if this can leak anything but let's be on the safe side. XXX pullup-8 XXX pullup-9 XXX pullup-10
2023-06-20``int i'' is used only for SUPPORT_NFS || SUPPORT_TFTP.rin